This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Cast to a struct in expressions
- To: <Hilfinger at cs dot berkeley dot edu>
- Subject: Re: Cast to a struct in expressions
- From: Daniel Berlin <dan at www dot cgsoftware dot com>
- Date: Sat, 28 Apr 2001 14:29:59 -0400 (EDT)
- cc: Eli Zaretskii <eliz at is dot elta dot co dot il>, <gdb at sources dot redhat dot com>
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
>