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

[Daniel Jacobowitz <drow@false.org>]

On Tue, Feb 27, 2007 at 07:51:53AM -0500, Robert Dewar wrote:
> Nick Roberts wrote:
> 
> >That answers the question that we are really asking and justifies the 
> >patch.
> 
> Not necessarily. First it is only a claim, without documentation,

Do you have any reasonable ideas on how to gather data?  I'm listening
:-)

I spent a little while poking at Google CodeSearch.  There were
definitely some matches of people assigning strings to "unsigned char
*" variables - most of the ones I looked at were in test code for
crypto libraries, or things like base64 / locale ctype tables.  There
were an order of magnitude (about 75x) more matches for plain "char
*".

signed\ char.*\ =\ .*\"		about   7000
unsigned\ char.*\ =\ .*\"	about  10600
char.*\ =\ .*\"			about 753000

I know that as a GDB developer, debugging GDB, I'd want explicitly
signed or unsigned characters to be printed as data; we made a
deliberate switch to using gdb_byte (which is unsigned char) for
unknown data read from target memory.  We cast it to char * when we
read strings.

> second, any incompatible change seems basically problematic.

I have some trouble understanding this.  Could someone explain it to
me?

It's an honest and serious question, I'm not asking for a lecture on
compatibility concepts here.  This is user interface, not core
functionality.  It's more like clarifying the text of one of GCC's
warning messages than changing the dialect of C it accepts.  I think
we have a lot of freedom to adapt our default output to be more useful
to our users, especially when we provide a way to get the old
behavior.  In this case that method is even completely backwards
compatible.

I think we have a lot of freedom to make this kind of change.  The
same reasoning applies to the print/x floating point discussion.

> > >                 We can document how to produce string output more
> > > clearly in the manual, perhaps?
> 
> I would instead document more clearly how to produce the integer
> output.

Without this patch there wasn't any way to produce the integer output
for single byte elements.  Which drove me batty working with vector
registers - I'm glad Jan posted the patch!

-- 
Daniel Jacobowitz
CodeSourcery