Re: [RFC] Signed/unsigned character arrays are not strings

[Paul Koning <pkoning at equallogic dot com>]

>>>>> "Mark" == Mark Kettenis <mark.kettenis@xs4all.nl> writes:

 >> Date: Tue, 27 Feb 2007 16:53:16 -0500 From: Daniel Jacobowitz
 >> <drow@false.org>
 >> 
 >> On Tue, Feb 27, 2007 at 11:06:17PM +0200, Eli Zaretskii wrote: >
 >> Doesn't a similar situation exist with "unsigned int" and "int",
 >> or > with "unsigned long" and "long"?  And yet we don't treat them
 >> > differently.
 >> > 
 >> > IOW, I think it's quite expected that explicit signedness is >
 >> relatively rare, since in the vast majority of cases it is simply
 >> not > needed.  Interpreting this phenomenon as saying something
 >> about what > kind of data is stored is not necessarily a good
 >> idea.
 >> 
 >> I feel that this is different for two reasons.  One is that the
 >> situation for int and long is not the same, because "int" and
 >> "signed int" are the same type in C - but "char" and "signed char"
 >> are not.  Char is explicitly of indeterminate sign.  The other is
 >> that there is a widespread use of "char" for string data and
 >> "signed char" or "unsigned char" for non-string data.

 Mark> Well, "char" really is "signed char" on most machines and
 Mark> "unsigned char" on others.  One way to prevent the
 Mark> sign-extension problems this sometimes causes, is to explicitly
 Mark> use "unsigned char *" for strings.

Right.  For example, if you do string manipulation by table lookup on
the characters, then this is a good thing to do.  (It avoids the
painful 384 entry table hacks you otherwise need.)

 Mark> Anyway, I'm in favour of restore the traditional gdb behaviour
 Mark> of printing all three as strings.

Same here.

     paul