This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: [RFC] Signed/unsigned character arrays are not strings
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