Cast to a struct in expressions

Cast to a struct in expressions

[Eli Zaretskii]

Should the following work?

  (gdb) p/x *(struct {long foo; unsigned bar;} *)foobar

It doesn't seem to work for me; GDB complains thusly:

  A parse error in expression, near `long foo; unsigned bar} *)foobar

Seems like the parser chokes on the struct declaration?  Am I missing
something?

Re: Cast to a struct in expressions

[Daniel Berlin]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> Should the following work?
> 
>   (gdb) p/x *(struct {long foo; unsigned bar;} *)foobar
> 
> It doesn't seem to work for me; GDB complains thusly:
Correct.

> 
>   A parse error in expression, near `long foo; unsigned bar} *)foobar
> 
> Seems like the parser chokes on the struct declaration?
Yes.
>   Am I missing something?
Yes, I think. The parser only handles expressions, nothing more.
This is why it's c-exp.y, and not c.y.
:)

If you have a real struct already defined, of course, and di

p/x *(sturct foostruct *)foobar

then *that* should work.
--dan

-- 
"I couldn't find the remote control to the remote control.
"-Steven Wright

Re: Cast to a struct in expressions

[Eli Zaretskii]

> From: Daniel Berlin <dan@cgsoftware.com>
> Date: 27 Apr 2001 11:23:55 -0400
> 
> >   A parse error in expression, near `long foo; unsigned bar} *)foobar
> > 
> > Seems like the parser chokes on the struct declaration?
> Yes.
> >   Am I missing something?
> Yes, I think. The parser only handles expressions, nothing more.
> This is why it's c-exp.y, and not c.y.
> :)
> 
> If you have a real struct already defined, of course, and di
> 
> p/x *(sturct foostruct *)foobar
> 
> then *that* should work.

No, there's no such struct, otherwise I wouldn't be opting for this
complication ;-)

I'm still missing something, because I don't see how "*(struct foo *)x"
differs from "*(struct {long foo; unsigned bar;} *)x".  Both are valid
C expression syntax, so the parser should be able to parse them both.

I guess someone just stopped short of making this part of the parser,
because it looks like "struct <name>" is the only syntax it accepts.
Right?

Anyway, thanks for the feedback.

Re: Cast to a struct in expressions

[Daniel Berlin]

--On Friday, April 27, 2001 8:42 PM +0300 Eli Zaretskii 
<eliz@is.elta.co.il> wrote:

>> From: Daniel Berlin <dan@cgsoftware.com>
>> Date: 27 Apr 2001 11:23:55 -0400
>>
>> >   A parse error in expression, near `long foo; unsigned bar} *)foobar
>> >
>> > Seems like the parser chokes on the struct declaration?
>> Yes.
>> >   Am I missing something?
>> Yes, I think. The parser only handles expressions, nothing more.
>> This is why it's c-exp.y, and not c.y.
>> :)
>>
>> If you have a real struct already defined, of course, and di
>>
>> p/x *(sturct foostruct *)foobar
>>
>> then *that* should work.
>
> No, there's no such struct, otherwise I wouldn't be opting for this
> complication ;-)
>
> I'm still missing something, because I don't see how "*(struct foo *)x"
> differs from "*(struct {long foo; unsigned bar;} *)x".  Both are valid
> C expression syntax, so the parser should be able to parse them both.

No, they aren't both *expressions*, only one is.
One is a statement/declaration, and the other is an expression.


>
> I guess someone just stopped short of making this part of the parser,
> because it looks like "struct <name>" is the only syntax it accepts.
> Right?
No. It's done on purpose.  We aren't supposed to be handling statements and 
declarations, only expressions.

Doing more would require making the C parser into a mini-C compiler.
You'd have to start injecting types into the symbol table and whatnot.

>
> Anyway, thanks for the feedback.
NP.

Re: Cast to a struct in expressions

[Eli Zaretskii]

> Date: Fri, 27 Apr 2001 15:30:22 -0400
> From: Daniel Berlin <dan@cgsoftware.com>
> >
> > I'm still missing something, because I don't see how "*(struct foo *)x"
> > differs from "*(struct {long foo; unsigned bar;} *)x".  Both are valid
> > C expression syntax, so the parser should be able to parse them both.
> 
> No, they aren't both *expressions*, only one is.
> One is a statement/declaration, and the other is an expression.

I'm not a C language expert, but my references seem to disagree with
you.  The "cast-expression" is defined as having the form

   cast-expression:
     unary-expression
     ( type-name ) cast-expression

and "type-name" is syntactically a declaration for a function or an
object of that type with the object identifier omitted.

> No. It's done on purpose.  We aren't supposed to be handling statements and 
> declarations, only expressions.
> 
> Doing more would require making the C parser into a mini-C compiler.
> You'd have to start injecting types into the symbol table and whatnot.

I think I understand the trade-offs and appreciate the problems.  I'm
not saying GDB must support such expressions, but the language
definition seems to say it's an expression, so users might expect them
to be supported.  Perhaps something should be said in the docs.

Re: Cast to a struct in expressions

[Paul Hilfinger]

 > > > I'm still missing something, because I don't see how "*(struct foo *)x"
 > > > differs from "*(struct {long foo; unsigned bar;} *)x".  Both are valid
 > > > C expression syntax, so the parser should be able to parse them both.
 > > 
 > > No, they aren't both *expressions*, only one is.
 > > One is a statement/declaration, and the other is an expression.
 > 
 > I'm not a C language expert, but my references seem to disagree with
 > you.

Correct; both are expressions, or you couldn't write

  long z = (*(struct {long foo; unsigned bar;} *)x).foo;

whereas, in fact, you can.

Of course, the semantics of 
    
  *(struct {long foo; unsigned bar;} *)x 

is officially undefined, since, contrary to the fond beliefs of many C
programmers, the Standard only occasionally gives meaning to
dereferences of a cast of a pointer value to a different pointer type
(the anonymous type in the expression above necessarily differs from
that of x).  Therefore, GDB is not completely out of line in refusing
to recognize this, even if the reason it gives is maybe a little off.

Paul Hilfinger

Re: Cast to a struct in expressions

[Daniel Berlin]

On Sat, 28 Apr 2001, Paul Hilfinger wrote:

>
>  > > > I'm still missing something, because I don't see how "*(struct foo *)x"
>  > > > differs from "*(struct {long foo; unsigned bar;} *)x".  Both are valid
>  > > > C expression syntax, so the parser should be able to parse them both.
>  > >
>  > > No, they aren't both *expressions*, only one is.
>  > > One is a statement/declaration, and the other is an expression.
>  >
>  > I'm not a C language expert, but my references seem to disagree with
>  > you.
>
> Correct; both are expressions, or you couldn't write
>
>   long z = (*(struct {long foo; unsigned bar;} *)x).foo;

Except, I tried to compile this with a few c compilers, and it didn't
work.
Only gcc seems to accept it.

>
> whereas, in fact, you can.
>
> Of course, the semantics of
>
>   *(struct {long foo; unsigned bar;} *)x
>
> is officially undefined, since, contrary to the fond beliefs of many C
> programmers, the Standard only occasionally gives meaning to
> dereferences of a cast of a pointer value to a different pointer type
> (the anonymous type in the expression above necessarily differs from
> that of x).


> Therefore, GDB is not completely out of line in refusing
> to recognize this, even if the reason it gives is maybe a little off.

not "completely" out of line?
It's not a c compiler.
It doesn't pretend to be.
I can't even get a lot of c compilers to recognize the expression.
how could gdb be in any way out of line in refusing it, considering it's
just a debugger?

C also says that

given
int a[5];

4[a] == a[4]

We don't allow you to type "print 4[a] = 3", but we do allow "print a[4] =
3".

Is this out of line?

> Paul Hilfinger
>

Re: Cast to a struct in expressions

[Daniel Berlin]

On Sat, 28 Apr 2001, Eli Zaretskii wrote:

> > Date: Fri, 27 Apr 2001 15:30:22 -0400
> > From: Daniel Berlin <dan@cgsoftware.com>
> > >
> > > I'm still missing something, because I don't see how "*(struct foo *)x"
> > > differs from "*(struct {long foo; unsigned bar;} *)x".  Both are valid
> > > C expression syntax, so the parser should be able to parse them both.
> >
> > No, they aren't both *expressions*, only one is.
> > One is a statement/declaration, and the other is an expression.
>
> I'm not a C language expert, but my references seem to disagree with
> you.  The "cast-expression" is defined as having the form
>
>    cast-expression:
>      unary-expression
>      ( type-name ) cast-expression
>
> and "type-name" is syntactically a declaration for a function or an
> object of that type with the object identifier omitted.

Errr, not possible.
You must be reading it wrong.
Try compiling
int main(void)
{
	int x;
	*((struct { long foo; unsigned bar;} *)x)->foo=5;
}

It won't work.
You can't define types in cast expressions, AFAIK.
What would their scope be?


>
> > No. It's done on purpose.  We aren't supposed to be handling statements and
> > declarations, only expressions.
> >
> > Doing more would require making the C parser into a mini-C compiler.
> > You'd have to start injecting types into the symbol table and whatnot.
>
> I think I understand the trade-offs and appreciate the problems.  I'm
> not saying GDB must support such expressions, but the language
> definition seems to say it's an expression, so users might expect them
> to be supported.  Perhaps something should be said in the docs.
>
Errr, i'm pretty sure you are the first user ever to try this, no offense
or anything.

The docs go over what is allowed to be used, and nowhere does it say
anything about being able to create types out of thin air in cast
expressions. Of cours,e it doesn't say you can't, either.
I have to modify that part of the docs since it says stabs is good for C++
(which hasn't been true for about 4 years now) anyway, so if you want me
to add smething about allowable cast expressions, i'll be happy to.

Re: Cast to a struct in expressions

[Eli Zaretskii]

On Sat, 28 Apr 2001, Daniel Berlin wrote:

> I have to modify that part of the docs since it says stabs is good for C++
> (which hasn't been true for about 4 years now) anyway

Well, it only says ``for best results [...] use -gstabs'', so it's not
an absolute.  Stabs are certainly better than, say, COFF debug info
for debugging C++.  And if GCC is used, stabs are available on more
platforms than dwarf2.  So I think the manual language isn't totally
wrong.

Btw, if stabs aren't the best type of debug info available in GDB 5.0 for
debugging C++ code, what is?

Re: Cast to a struct in expressions

[Daniel Berlin]

On Sun, 29 Apr 2001, Eli Zaretskii wrote:

>
> On Sat, 28 Apr 2001, Daniel Berlin wrote:
>
> > I have to modify that part of the docs since it says stabs is good for C++
> > (which hasn't been true for about 4 years now) anyway
>
> Well, it only says ``for best results [...] use -gstabs'', so it's not
> an absolute.
Best results will happen with dwarf2, not stabs.

> Stabs are certainly better than, say, COFF debug info
> for debugging C++.  And if GCC is used, stabs are available on more
> platforms than dwarf2.  So I think the manual language isn't totally
> wrong.
Well, it's also only the default on older platforms. I haven't seen a new
port in well over a year that uses STABS as a default.

>
> Btw, if stabs aren't the best type of debug info available in GDB 5.0 for
> debugging C++ code, what is?
>
dwarf2.
By a large margin.

Especially if you call functions.
Overload resolution, for instance, on STABS, is basically a complete hack.
Okay, not basically, it flat out is.
--Dan

Re: Cast to a struct in expressions

[Eli Zaretskii]

On Sun, 29 Apr 2001, Daniel Berlin wrote:

> > Stabs are certainly better than, say, COFF debug info
> > for debugging C++.  And if GCC is used, stabs are available on more
> > platforms than dwarf2.  So I think the manual language isn't totally
> > wrong.
> Well, it's also only the default on older platforms. I haven't seen a new
> port in well over a year that uses STABS as a default.

Well, GDB 5.0 was released only about a year ago, and the part you 
referred to was written for v5.0 ;-)

Thanks for the other info.  I think we need indeed to change the wording 
in that part of the manual, but perhaps we should wait until closer to 
the release of 5.1, in order to know what exactly to say--I understand 
that you are still working on improving the C++ support.