Re: [PATCH] [gdb/exp] Fix cast handling for indirection

[Kevin Buettner <kevinb@redhat.com>]

On Fri, 3 May 2024 17:04:41 +0100
Pedro Alves <pedro@palves.net> wrote:

> > I was wondering if this patch causes gdb to accept some weird things
> > that might have been rejected in the past, by introducing a hidden cast.
> > Maybe print (char) *85732 does something surprising now.  I'm not
> > entirely sure if that's bad.  
> 
> I am totally surprised that:
> 
>  +# Regression test for PR31693.
>  +gdb_test "p (char)*a_loc ()" " = 97 'a'"
> 
> this actually works, instead of telling the user:
> 
>   "'a_loc' has unknown return type; cast the call to its declared return type"
> 
> It seems like a misfeature to me to assume that "char *" is the right type.
> 
> Thus, I don't agree with the patch.

Using a GDB built with Tom de Vries's patch, I see:

(gdb) p *a_loc()
'a_loc' has unknown return type; cast the call to its declared return type

This is the same as the pre-patch behavior.

With Tom's patch, GDB now infers the function's return type, based
on the cast:

(gdb) p (char)*a_loc()
$1 = 97 'a'

I like this behavior and certainly find it preferable to the behavior
without his patch:

(gdb) p (char)*a_loc()
Cannot access memory at address 0x4

With regard to doing something like 'print (char) *85732', I
don't see anything surprising...

(gdb) p/d (char *)a_loc()
$1 = 4210692

(I'll use 4210692 in place of 85732.)

Pre-patch:

(gdb) p *4210692
$2 = 97
(gdb) p (char)*4210692
$3 = 97 'a'

With Tom de Vries's patch:

(gdb) p *4210692
$9 = 97
(gdb) p (char)*4210692
$10 = 97 'a'

Kevin