[ECOS] diag_printf refuses to print ANSI escape sequences?

[ECOS] diag_printf refuses to print ANSI escape sequences?

[Grant Edwards]

In the "not a big deal" department...

I'm trying to send ANSI escape sequences using diag_printf, and
diag_printf refuses.  If I put the escape character in the
format string it says 

 <Bad format string: 8055F18 : 0 0 2 807F0D8 DDD9BFFD FB93FFDC 8055758 FB93FFDC>

If there's an escape character in a string that is to be
printed using the "%s" format, it says: 

 <Not a string: 0x8055F20>

I understand that it's useful to attempt to avoid printing
random binary garbage, but I would think that ASCII ESC might
be allowed in strings.
 
I've found that insterting the escape characters using %c
works, but that's a bit awkward.

-- 
Grant Edwards                   grante             Yow!  My LESLIE GORE record
                                  at               is BROKEN...
                               visi.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] diag_printf refuses to print ANSI escape sequences?

[Sergei Gavrikov]

On Sat, May 26, 2007 at 03:19:42PM +0000, Grant Edwards wrote:
> In the "not a big deal" department...
> 
> I'm trying to send ANSI escape sequences using diag_printf, and
> diag_printf refuses.  If I put the escape character in the format
> string it says 
> 
>  <Bad format string: 8055F18 : 0 0 2 807F0D8 DDD9BFFD FB93FFDC 8055758
>  FB93FFDC>
> 
> If there's an escape character in a string that is to be printed using
> the "%s" format, it says: 
> 
>  <Not a string: 0x8055F20>
> 
> I understand that it's useful to attempt to avoid printing random
> binary garbage, but I would think that ASCII ESC might be allowed in
> strings.
>  
> I've found that insterting the escape characters using %c works, but
> that's a bit awkward.
 
There are nice diag_dump_buf* functions in the eCos infra layer
(cyg/infra/diag.h).  I do use that.

-- Sergei

> -- 
> Grant Edwards                   grante             Yow!  My LESLIE GORE record
>                                   at               is BROKEN...
>                                visi.com            
> 
> 
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: diag_printf refuses to print ANSI escape sequences?

[Grant Edwards]

On 2007-05-26, Sergei Gavrikov <w3sg@SoftHome.net> wrote:
> On Sat, May 26, 2007 at 03:19:42PM +0000, Grant Edwards wrote:
>> In the "not a big deal" department...
>> 
>> I'm trying to send ANSI escape sequences using diag_printf, and
>> diag_printf refuses.  If I put the escape character in the format
>> string it says 
>> 
>>  <Bad format string: 8055F18 : 0 0 2 807F0D8 DDD9BFFD FB93FFDC 8055758
>>  FB93FFDC>
>> 
>> If there's an escape character in a string that is to be printed using
>> the "%s" format, it says: 
>> 
>>  <Not a string: 0x8055F20>
>> 
>> I understand that it's useful to attempt to avoid printing random
>> binary garbage, but I would think that ASCII ESC might be allowed in
>> strings.
>>  
>> I've found that insterting the escape characters using %c works, but
>> that's a bit awkward.
>  
> There are nice diag_dump_buf* functions in the eCos infra layer
> (cyg/infra/diag.h).  I do use that.

I'm aware of the daig_dump_buf fuctions, but I don't see how
they solve my problem.  AFAIR, they dump out buffer contents in
hex.  What I'm trying to do is:

 diag_printf("\033[34mBlue Text \033[31mRed Text \033[mNormal Text\n");

diag_printf refuses to do that, so I have to do something like
this instead:

 diag_printf("%c[34mBlue Text %c[31mRed Text %c[mNormal Text\n",033,033,033);

and that seems awkward to me.

One could argue that embedding escape seqences in strings is a
bit hackish...

-- 
Grant Edwards                   grante             Yow! NEWARK has been
                                  at               REZONED!!  DES MOINES has
                               visi.com            been REZONED!!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: diag_printf refuses to print ANSI escape sequences?

[Gary Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Grant Edwards wrote:
> On 2007-05-26, Sergei Gavrikov <w3sg@SoftHome.net> wrote:
>> On Sat, May 26, 2007 at 03:19:42PM +0000, Grant Edwards wrote:
>>> In the "not a big deal" department...
>>>
>>> I'm trying to send ANSI escape sequences using diag_printf, and
>>> diag_printf refuses.  If I put the escape character in the format
>>> string it says 
>>>
>>>  <Bad format string: 8055F18 : 0 0 2 807F0D8 DDD9BFFD FB93FFDC 8055758
>>>  FB93FFDC>
>>>
>>> If there's an escape character in a string that is to be printed using
>>> the "%s" format, it says: 
>>>
>>>  <Not a string: 0x8055F20>
>>>
>>> I understand that it's useful to attempt to avoid printing random
>>> binary garbage, but I would think that ASCII ESC might be allowed in
>>> strings.
>>>  
>>> I've found that insterting the escape characters using %c works, but
>>> that's a bit awkward.
>>  
>> There are nice diag_dump_buf* functions in the eCos infra layer
>> (cyg/infra/diag.h).  I do use that.
> 
> I'm aware of the daig_dump_buf fuctions, but I don't see how
> they solve my problem.  AFAIR, they dump out buffer contents in
> hex.  What I'm trying to do is:
> 
>  diag_printf("\033[34mBlue Text \033[31mRed Text \033[mNormal Text\n");
> 
> diag_printf refuses to do that, so I have to do something like
> this instead:
> 
>  diag_printf("%c[34mBlue Text %c[31mRed Text %c[mNormal Text\n",033,033,033);
> 
> and that seems awkward to me.
> 
> One could argue that embedding escape seqences in strings is a
> bit hackish...
> 

Why not just make a patch that allows for such escape sequences?

There's nothing to say that we didn't think of everything some 10 years
ago and that today's world could accept some improvements :-)  If you're
coy about such changes, make it conditional with some CDL, e.g. spelling
out what non "printable" characters are allowed, etc.



- --
- ------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
- ------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGWO3jmaKbSsQGV8ARAoLkAJ4hxSqYVCLvGv1gST78UKD86dTS1ACfUW+u
EmdmXl2naFYXaGXYOKPGHB8=
=ZFnw
-----END PGP SIGNATURE-----

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: diag_printf refuses to print ANSI escape sequences?

[Sergei Gavrikov]

On Sat, May 26, 2007 at 08:19:40PM +0000, Grant Edwards wrote:
> On 2007-05-26, Sergei Gavrikov <w3sg@SoftHome.net> wrote:
> > On Sat, May 26, 2007 at 03:19:42PM +0000, Grant Edwards wrote:
> >> In the "not a big deal" department...
> >> 
> >> I'm trying to send ANSI escape sequences using diag_printf, and
> >> diag_printf refuses.  If I put the escape character in the format
> >> string it says 
> >> 
> >>  <Bad format string: 8055F18 : 0 0 2 807F0D8 DDD9BFFD FB93FFDC 8055758
> >>  FB93FFDC>
> >> 
> >> If there's an escape character in a string that is to be printed using
> >> the "%s" format, it says: 
> >> 
> >>  <Not a string: 0x8055F20>
> >> 
> >> I understand that it's useful to attempt to avoid printing random
> >> binary garbage, but I would think that ASCII ESC might be allowed in
> >> strings.
> >>  
> >> I've found that insterting the escape characters using %c works, but
> >> that's a bit awkward.
> >  
> > There are nice diag_dump_buf* functions in the eCos infra layer
> > (cyg/infra/diag.h).  I do use that.
> 
> I'm aware of the daig_dump_buf fuctions, but I don't see how
> they solve my problem.  AFAIR, they dump out buffer contents in
> hex.  What I'm trying to do is:
> 
>  diag_printf("\033[34mBlue Text \033[31mRed Text \033[mNormal Text\n");
> 
> diag_printf refuses to do that, so I have to do something like
> this instead:
> 
>  diag_printf("%c[34mBlue Text %c[31mRed Text %c[mNormal Text\n",033,033,033);
> 
> and that seems awkward to me.
> 
> One could argue that embedding escape seqences in strings is a
> bit hackish...
> 

Ah, the diag_printf() for me always did mean the diagnostic (read debug)
output function, but it didn't mean for me any type of the printf+send.
IMHO, those diag_*() functions should be the light weight things. I
wouldn't see the complex parsing in the diag_printf(), diag_sprintf()
functions. What's about falk which use the eCos minimal template in
the first?

It seems, it's easy to use either macros, for example, COLOR_PRINTF,
COLOR_PUTS, etc. something like this

#define COLOR_PRINTF( fgcolor, bgcolor, fmt, ...) \
	...

and to use the diag_write_char() in the body of the macro to output those
special characters, or just own whiptail functions, i.e. something like
the cprintf(), cputchar(), cputs().

But the question is staying for me, Is the colorized output deal for
diag_printf?  I know that there are dumb terminals, GDB, etc. there.
Those things are deal for diag_printf(), aren't they?  IMHO, diag_led
can produce the colorized output, but diag_printf shouldn't do such
things :-)

-- Sergei


> -- 
> Grant Edwards                   grante             Yow! NEWARK has been
>                                   at               REZONED!!  DES MOINES has
>                                visi.com            been REZONED!!
> 
> 
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: diag_printf refuses to print ANSI escape sequences?

[Grant Edwards]

On 2007-05-27, Sergei Gavrikov <w3sg@SoftHome.net> wrote:

>> I'm aware of the daig_dump_buf fuctions, but I don't see how
>> they solve my problem.  AFAIR, they dump out buffer contents in
>> hex.  What I'm trying to do is:
>> 
>>  diag_printf("\033[34mBlue Text \033[31mRed Text \033[mNormal Text\n");
>> 
>> diag_printf refuses to do that, so I have to do something like
>> this instead:
>> 
>>  diag_printf("%c[34mBlue Text %c[31mRed Text %c[mNormal Text\n",033,033,033);
>> 
>> and that seems awkward to me.
>> 
>> One could argue that embedding escape seqences in strings is a
>> bit hackish...
>
> Ah, the diag_printf() for me always did mean the diagnostic (read debug)
> output function, but it didn't mean for me any type of the printf+send.
> IMHO, those diag_*() functions should be the light weight things.

Then adding extra code to reject strings with escape character
in them seems to be the wrong way to go them.

> I wouldn't see the complex parsing in the diag_printf(),
> diag_sprintf() functions.

I don't understand.  Are you don't think there shouldn't be
formatted diagnostic output?

> What's about falk which use the eCos minimal template in the
> first?

I've no idea.

> It seems, it's easy to use either macros, for example,
> COLOR_PRINTF, COLOR_PUTS, etc. something like this
>
> #define COLOR_PRINTF( fgcolor, bgcolor, fmt, ...) \
> 	...
>
> and to use the diag_write_char() in the body of the macro to
> output those special characters, or just own whiptail
> functions, i.e. something like the cprintf(), cputchar(),
> cputs().

I know there are other ways to accomplish what I want. I was
just surprised because even full-blown "regular" printf
functions (e.g. under Windows or Linux) don't include code to
reject strings with escape characters in them.  So I was
surprised that a lightweight printf function to have that added
feature. It's not a big deal as I'm done with the program in
which I wanted color output -- I was just surprised that it
worked the way it does.

> But the question is staying for me, Is the colorized output
> deal for diag_printf?

I almost never have a diagnostic port connected to anything
that's not a (mostly) ANSI terminal.  99% of the time I don't
really have much use for color output.

> I know that there are dumb terminals,

I couldn't find a dumb terminal if I wanted to (unless you want
to count minicom, which is broken in enough ways that I'd
probably classify it as dumb).

> GDB, etc. there. Those things are deal for diag_printf(),
> aren't they?

I don't have any dumb terminals, all I've got are ANSI ones. It
was just some output from a test program I was using to
troubleshoot some hardware.  It doesn't have to be portable.

> IMHO, diag_led can produce the colorized output,

No it can't.  Not on my platform.

> but diag_printf shouldn't do such things :-)

Since most of the people on Earth don't read English and don't
use a Latin alphabet, it probably shouldn't produce English or
be using a Latin alphabet either.

-- 
Grant Edwards                   grante             Yow! I want another
                                  at               RE-WRITE on my CEASAR
                               visi.com            SALAD!!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: diag_printf refuses to print ANSI escape sequences?

[Sergei Gavrikov]

В Вск, 27/05/2007 в 23:51 +0000, Grant Edwards пишет:
> On 2007-05-27, Sergei Gavrikov <w3sg@SoftHome.net> wrote:
> 
> >> I'm aware of the daig_dump_buf fuctions, but I don't see how
> >> they solve my problem.  AFAIR, they dump out buffer contents in
> >> hex.  What I'm trying to do is:
> >> 
> >>  diag_printf("\033[34mBlue Text \033[31mRed Text \033[mNormal Text\n");
> >> 
> >> diag_printf refuses to do that, so I have to do something like
> >> this instead:
> >> 
> >>  diag_printf("%c[34mBlue Text %c[31mRed Text %c[mNormal Text\n",033,033,033);
> >> 
> >> and that seems awkward to me.
> >> 
> >> One could argue that embedding escape seqences in strings is a
> >> bit hackish...
> >
> > Ah, the diag_printf() for me always did mean the diagnostic (read debug)
> > output function, but it didn't mean for me any type of the printf+send.
> > IMHO, those diag_*() functions should be the light weight things.
> 
> Then adding extra code to reject strings with escape character
> in them seems to be the wrong way to go them.
> 
> > I wouldn't see the complex parsing in the diag_printf(),
> > diag_sprintf() functions.
> 
> I don't understand.  Are you don't think there shouldn't be
> formatted diagnostic output?
> 
> > What's about falk which use the eCos minimal template in the
> > first?
> 
> I've no idea.
> 
> > It seems, it's easy to use either macros, for example,
> > COLOR_PRINTF, COLOR_PUTS, etc. something like this
> >
> > #define COLOR_PRINTF( fgcolor, bgcolor, fmt, ...) \
> > 	...
> >
> > and to use the diag_write_char() in the body of the macro to
> > output those special characters, or just own whiptail
> > functions, i.e. something like the cprintf(), cputchar(),
> > cputs().
> 
> I know there are other ways to accomplish what I want. I was
> just surprised because even full-blown "regular" printf
> functions (e.g. under Windows or Linux) don't include code to
> reject strings with escape characters in them.  So I was
> surprised that a lightweight printf function to have that added
> feature. It's not a big deal as I'm done with the program in
> which I wanted color output -- I was just surprised that it
> worked the way it does.
> 
> > But the question is staying for me, Is the colorized output
> > deal for diag_printf?
> 
> I almost never have a diagnostic port connected to anything
> that's not a (mostly) ANSI terminal.  99% of the time I don't
> really have much use for color output.
> 
> > I know that there are dumb terminals,
> 
> I couldn't find a dumb terminal if I wanted to (unless you want
> to count minicom, which is broken in enough ways that I'd
> probably classify it as dumb).
> 
> > GDB, etc. there. Those things are deal for diag_printf(),
> > aren't they?
> 
> I don't have any dumb terminals, all I've got are ANSI ones. It
> was just some output from a test program I was using to
> troubleshoot some hardware.  It doesn't have to be portable.
> 
> > IMHO, diag_led can produce the colorized output,
> 
> No it can't.  Not on my platform.
> 
> > but diag_printf shouldn't do such things :-)
> 
> Since most of the people on Earth don't read English and don't
> use a Latin alphabet, it probably shouldn't produce English or
> be using a Latin alphabet either.

I didn't speak about at all. I tried to say that diag_printf() hasn't to
become printf(). ABC is, If anyone need in full support for ANSI terms,
let he/she uses termcap/terminfo layer (for compatibility). eCos
printf() just quite prints such things:

printf ("Hello, \E[1meCos\E[m World!\n");

Why is here this flame? If you need to expand the diag_printf() add own
CDL rule to expand that diag_check_string ():

if( c == '\n' || c == '\r' || c == '\b' || c == '\t' || c == '\E' )
    continue;

Gary already did point on that.

regards,

--Sergei

> 
> -- 
> Grant Edwards                   grante             Yow! I want another
>                                   at               RE-WRITE on my CEASAR
>                                visi.com            SALAD!!
> 
> 


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Re: diag_printf refuses to print ANSI escape sequences?

[Paul D. DeRocco]

> From: Sergei Gavrikov
> 
> Why is here this flame? If you need to expand the 
> diag_printf() add own CDL rule to expand that diag_check_string ():
> 
> if( c == '\n' || c == '\r' || c == '\b' || c == '\t' || c == '\E' )
>     continue;
> 
> Gary already did point on that.

Or perhaps a CDL rule to turn off the string checking entirely. I'll bet
most people had no idea it was in there at all, until this thread came up.
It's certainly unexpected behavior to me. I would have expected diagnostic
output to be lightweight, with minimum built-in cleverness. So would the OP,
apparently.

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com 


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: diag_printf refuses to print ANSI escape sequences?

[Sergei Gavrikov]

On Mon, May 28, 2007 at 10:29:02AM -0700, Paul D. DeRocco wrote:
> > From: Sergei Gavrikov
> > 
> > Why is here this flame? If you need to expand the 
> > diag_printf() add own CDL rule to expand that diag_check_string ():
> > 
> > if( c == '\n' || c == '\r' || c == '\b' || c == '\t' || c == '\E' )
> >     continue;
> > 
> > Gary already did point on that.
> 
> Or perhaps a CDL rule to turn off the string checking entirely. I'll bet

It seems, that isn't good idea to turn off string checking at all in the
diagnostic function. LF, CR, BS and TAB are the essentials of the text
formating. So, those chars are there. The '\b' quite could produce a
bold printing, in past, for example :-) Sometimes, it needs to expand
TAB to spaces and etc. Other non-printed characters are optional things.
This is just _my_ opinion.  I think that minimalist set ('\n', '\r',
'\b', '\t') was the enough set for the diag_print() application.

-- Sergei

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Re: diag_printf refuses to print ANSI escape sequences?

[Paul D. DeRocco]

> From: Sergei Gavrikov [mailto:w3sg@SoftHome.net] 
> 
> It seems, that isn't good idea to turn off string checking at 
> all in the diagnostic function. LF, CR, BS and TAB are the 
> essentials of the text formating. So, those chars are there. 
> The '\b' quite could produce a bold printing, in past, for 
> example :-) Sometimes, it needs to expand TAB to spaces and 
> etc. Other non-printed characters are optional things. This 
> is just _my_ opinion.  I think that minimalist set ('\n', 
> '\r', '\b', '\t') was the enough set for the diag_print() application.

Fine, that's what CDL items are for. It seems odd, though, that diag_printf
would make such checks, while printf doesn't. Furthermore, it seems less odd
that it would make such a check on an argument string substituted for %s,
than on the format string itself, the latter almost always being a literal
string passed directly to the function by the caller.

Anyway, I don't have a dog in this fight. I was just musing that a CDL
option to take out the checking seemed more sensible than a CDL option to
add yet another check to it.

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com 


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: diag_printf refuses to print ANSI escape sequences?

[Nick Garnett]

 Grant Edwards <grante@visi.com> writes:

> > Ah, the diag_printf() for me always did mean the diagnostic (read debug)
> > output function, but it didn't mean for me any type of the printf+send.
> > IMHO, those diag_*() functions should be the light weight things.
> 
> Then adding extra code to reject strings with escape character
> in them seems to be the wrong way to go them.

diag_printf() is expressly designed to generate diagnostic
output. This often happens after memory has been corrupted, or during
development, when it would be easy to try and print a string that has
been overwritten, or has not yet been initialized. This has the
potential of making a total mess of the diagnostic output,
particularly if minicom/Hyperterm interprets escape sequences.

After suffering this one too many times, we added code to check all
strings for printable characters and reject those that don't. This
greatly improved the quality of diagnostics during development and the
dying moments of a system.


-- 
Nick Garnett                                     eCos Kernel Architect
eCosCentric Limited     http://www.eCosCentric.com/   The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.    Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: diag_printf refuses to print ANSI escape sequences?

[Grant Edwards]

On 2007-05-29, Nick Garnett <nickg@ecoscentric.com> wrote:
>  Grant Edwards <grante@visi.com> writes:
>
>>> Ah, the diag_printf() for me always did mean the diagnostic (read debug)
>>> output function, but it didn't mean for me any type of the printf+send.
>>> IMHO, those diag_*() functions should be the light weight things.
>> 
>> Then adding extra code to reject strings with escape character
>> in them seems to be the wrong way to go then.
>
> diag_printf() is expressly designed to generate diagnostic
> output. This often happens after memory has been corrupted, or during
> development, when it would be easy to try and print a string that has
> been overwritten, or has not yet been initialized. This has the
> potential of making a total mess of the diagnostic output,
> particularly if minicom/Hyperterm interprets escape sequences.
>
> After suffering this one too many times, we added code to check all
> strings for printable characters and reject those that don't. This
> greatly improved the quality of diagnostics during development and the
> dying moments of a system.

I completely agree.  I don't think the check should be removed,
though I think perhaps ESC should be allowed as a "printable"
character.  I don't currently have a need for it, so this is
all just moot court as far as I'm concerned.

I was pointing out that not "supporting" escape sequences has
nothing to do with keeping diag_printf light weight, because
checking for non-printable characters is actually negligiably
counter-productive when viewed with that goal in mind.

-- 
Grant Edwards                   grante             Yow! My CODE of ETHICS
                                  at               is vacationing at famed
                               visi.com            SCHROON LAKE in upstate
                                                   New York!!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss