Re: RFC: fix `gdb -write' case

[Jan Kratochvil <jan.kratochvil@redhat.com>]

>>>>> "Yao" == Yao Qi <yao@codesourcery.com> writes:

Tom> https://bugzilla.redhat.com/show_bug.cgi?id=696148

Yao> FYI, I can't access this bug.  I am told "You are not authorized to
Yao> access bug #696148."

In that Bug I made a comment
# evaluate_subexp_c->OP_STRING ignores expect_type, GDB then tries to convert
# the non-matching type using malloc.

which I advocate below.


On Mon, 09 May 2011 16:53:38 +0200, Tom Tromey wrote:
> Yao> Any difference on these two type variables (expect_type vs. stringtype)?
> 
> Yes.  You can wind up with a different "char" type following the logic
> in c-lang.c.  In this case some higher level will try to cast the string
> to the correct type, which will try to force it to memory, leading to
> the bad result.
> 
> The checks in the patch are intended to ensure that the expected type
> isn't "too weird" -- that we don't do something nonsensical.

The approach you took is not in the style of current GDB:

#include <wchar.h>
short a_short[2];
long a_long[2];
char a_char[3];
wchar_t a_wchar[3];
int main (void) { return 0; }

# With gcc only - without libstdc++ linked - GDB complains despite the code
# compiled and runs fine; but that is a different Bug.
# (gdb) p U"x"
# No type named char32_t.
g++ -g

(gdb) start
(gdb) set a_short={1L,2LL}
(gdb) p a_short
$1 = {1, 2}
(gdb) ptype a_short
type = short [2]
(gdb) set a_long={1L,2LL}
(gdb) p a_long
$2 = {1, 2}
(gdb) ptype a_long
type = long [2]
(gdb) set a_char=U"x"
expected type of string constant has wrong character width
(gdb) set a_wchar="x"
expected type of string constant has wrong character width
(gdb) 

I believe if GDB adjusts the short/long types shouldn't it adjust also
char/whar_t types?  That is now the user must know the type of string in
advance which wasn't the case for arrays before.

But it is not a real regression as GDB had not supported Unicode strings.

This is why I made the comment above.


Thanks,
Jan