On Sat, 24 Feb 2007 21:11:02 +0100, Nick Roberts wrote:
>  > Does adding an appropriate (char *) cast fix the problem, and do you
>  > think it's reasonable?
> 
> If you mean in .gdbinit, changing
...
>   output ($arg0->size > 1000) ? 0 : ($data[0])@($arg0->size_byte < 0 ? $arg0->size & ~gdb_array_mark_flag : $arg0->size_byte)
...
> to:
...
>   output (char *) ($arg0->size > 1000) ? 0 : ($data[0])@($arg0->size_byte < 0 ? $arg0->size & ~gdb_array_mark_flag : $arg0->size_byte)
...
> makes no difference.

You have an association bug there.  In fact such workaround works [attached].
	(gdb) xbacktrace 
	0x92e75aa "recursive-edit" (0xa420a23)
	0x92e685c "byte-code" (0x825e7db)
	...

> I don't understand why unsigned chars should be printed as arrays except to
> solve Jan's particular problem.  Maybe Emacs uses unsigned char for 8 bit
> character sets like iso_8859-1:
> 
> 2000-01-04  Gerd Moellmann  <gerd@gnu.org>
> 
> 	* lisp.h (struct Lisp_String): Make DATA member `unsigned char *'.

Either you consider the type still as a normal C string and in this case it
should be `{,const} char *'.  Or you consider it as some arbitrary data (due to
its character set not matching the system default one) and in this case it is
is best to display the numerical value of each of its array element.  Printing
it just as a string just outputs invalid characters to the debugger's screen.

I believe Emacs should revert to using `char *' but I do not know the reasons
for the Gerd Moellmann's change above.


> Like another change that Ulrich Drepper is proposing (%a) this patch changes
> existing behaviour.  Why not just add a new output format, or boolean variable?

As in such case one can drop the patch completely as no-one would ever figure
such new output format exists.  Sure such decision would also make a sense.



Regards,
Jan