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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 27 Feb 2007 08:14:42 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Nick Roberts <nickrob@snap.net.nz>, 	Jan Kratochvil <jan.kratochvil@redhat.com>, 	mathieu lacage <Mathieu.Lacage@sophia.inria.fr>, gdb@sourceware.org
> 
> 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
> *".

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 know that as a GDB developer, debugging GDB, I'd want explicitly
> signed or unsigned characters to be printed as data

That is indeed one reason to use unsigned char.  But there is another,
as demonstrated by Emacs's Lisp_String type: to store non-ASCII
characters whose upper bit might be set.  And in those latter cases,
we do want the data displayed as text, not as numeric codes.

> > 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.

If you are not asking about general principles, then I really don't
understand what kind of explanations you would like to hear.

> 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.

The issue is precisely that it is controversial whether the proposed
output is necessarily more useful to the user.  It is clearly more
useful in some cases, but not in the others.

> In this case that method is even completely backwards compatible.

??? Now _I_ would like to ask for explanations.  Do you mean the cast
to "char *" trick? if so, that's not backward compatibility, because
existing scripts in .gdbinit files need to be modified to get back
past behavior.