* [ECOS] diag_printf refuses to print ANSI escape sequences? @ 2007-05-26 16:38 Grant Edwards 2007-05-26 20:19 ` Sergei Gavrikov 0 siblings, 1 reply; 12+ messages in thread From: Grant Edwards @ 2007-05-26 16:38 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [ECOS] diag_printf refuses to print ANSI escape sequences? 2007-05-26 16:38 [ECOS] diag_printf refuses to print ANSI escape sequences? Grant Edwards @ 2007-05-26 20:19 ` Sergei Gavrikov 2007-05-26 22:56 ` [ECOS] " Grant Edwards 0 siblings, 1 reply; 12+ messages in thread From: Sergei Gavrikov @ 2007-05-26 20:19 UTC (permalink / raw) To: Grant Edwards; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [ECOS] Re: diag_printf refuses to print ANSI escape sequences? 2007-05-26 20:19 ` Sergei Gavrikov @ 2007-05-26 22:56 ` Grant Edwards 2007-05-27 10:12 ` Gary Thomas 2007-05-27 14:42 ` Sergei Gavrikov 0 siblings, 2 replies; 12+ messages in thread From: Grant Edwards @ 2007-05-26 22:56 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [ECOS] Re: diag_printf refuses to print ANSI escape sequences? 2007-05-26 22:56 ` [ECOS] " Grant Edwards @ 2007-05-27 10:12 ` Gary Thomas 2007-05-27 14:42 ` Sergei Gavrikov 1 sibling, 0 replies; 12+ messages in thread From: Gary Thomas @ 2007-05-27 10:12 UTC (permalink / raw) To: Grant Edwards; +Cc: ecos-discuss -----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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [ECOS] Re: diag_printf refuses to print ANSI escape sequences? 2007-05-26 22:56 ` [ECOS] " Grant Edwards 2007-05-27 10:12 ` Gary Thomas @ 2007-05-27 14:42 ` Sergei Gavrikov 2007-05-28 5:33 ` Grant Edwards 1 sibling, 1 reply; 12+ messages in thread From: Sergei Gavrikov @ 2007-05-27 14:42 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [ECOS] Re: diag_printf refuses to print ANSI escape sequences? 2007-05-27 14:42 ` Sergei Gavrikov @ 2007-05-28 5:33 ` Grant Edwards 2007-05-28 15:28 ` Sergei Gavrikov 2007-05-29 9:57 ` Nick Garnett 0 siblings, 2 replies; 12+ messages in thread From: Grant Edwards @ 2007-05-28 5:33 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [ECOS] Re: diag_printf refuses to print ANSI escape sequences? 2007-05-28 5:33 ` Grant Edwards @ 2007-05-28 15:28 ` Sergei Gavrikov 2007-05-28 20:22 ` Paul D. DeRocco 2007-05-29 9:57 ` Nick Garnett 1 sibling, 1 reply; 12+ messages in thread From: Sergei Gavrikov @ 2007-05-28 15:28 UTC (permalink / raw) To: Grant Edwards; +Cc: ecos-discuss Ð ÐÑк, 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [ECOS] Re: diag_printf refuses to print ANSI escape sequences? 2007-05-28 15:28 ` Sergei Gavrikov @ 2007-05-28 20:22 ` Paul D. DeRocco 2007-05-28 20:33 ` Sergei Gavrikov 0 siblings, 1 reply; 12+ messages in thread From: Paul D. DeRocco @ 2007-05-28 20:22 UTC (permalink / raw) To: 'Sergei Gavrikov'; +Cc: ecos-discuss > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [ECOS] Re: diag_printf refuses to print ANSI escape sequences? 2007-05-28 20:22 ` Paul D. DeRocco @ 2007-05-28 20:33 ` Sergei Gavrikov 2007-05-29 4:50 ` Paul D. DeRocco 0 siblings, 1 reply; 12+ messages in thread From: Sergei Gavrikov @ 2007-05-28 20:33 UTC (permalink / raw) To: Paul D. DeRocco; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [ECOS] Re: diag_printf refuses to print ANSI escape sequences? 2007-05-28 20:33 ` Sergei Gavrikov @ 2007-05-29 4:50 ` Paul D. DeRocco 0 siblings, 0 replies; 12+ messages in thread From: Paul D. DeRocco @ 2007-05-29 4:50 UTC (permalink / raw) To: ecos-discuss > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [ECOS] Re: diag_printf refuses to print ANSI escape sequences? 2007-05-28 5:33 ` Grant Edwards 2007-05-28 15:28 ` Sergei Gavrikov @ 2007-05-29 9:57 ` Nick Garnett 2007-05-29 17:05 ` Grant Edwards 1 sibling, 1 reply; 12+ messages in thread From: Nick Garnett @ 2007-05-29 9:57 UTC (permalink / raw) To: Grant Edwards; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [ECOS] Re: diag_printf refuses to print ANSI escape sequences? 2007-05-29 9:57 ` Nick Garnett @ 2007-05-29 17:05 ` Grant Edwards 0 siblings, 0 replies; 12+ messages in thread From: Grant Edwards @ 2007-05-29 17:05 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2007-05-29 14:45 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-05-26 16:38 [ECOS] diag_printf refuses to print ANSI escape sequences? Grant Edwards 2007-05-26 20:19 ` Sergei Gavrikov 2007-05-26 22:56 ` [ECOS] " Grant Edwards 2007-05-27 10:12 ` Gary Thomas 2007-05-27 14:42 ` Sergei Gavrikov 2007-05-28 5:33 ` Grant Edwards 2007-05-28 15:28 ` Sergei Gavrikov 2007-05-28 20:22 ` Paul D. DeRocco 2007-05-28 20:33 ` Sergei Gavrikov 2007-05-29 4:50 ` Paul D. DeRocco 2007-05-29 9:57 ` Nick Garnett 2007-05-29 17:05 ` Grant Edwards
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).