This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C++ PATCH: Fix PR 13275
On Wed, 17 Dec 2003, Richard Henderson wrote:
> The following patch appears to work for C. I would recind my
> earlier claim that it made the grammar too nasty.
>
> Given this, does this seem the approach we want to take?
This is the approach I prefer (though I'm not aware of any actual bugs it
fixes for C at present that would make it appropriate for this development
stage).
> ! | OFFSETOF '(' typespec_nonattr ',' offsetof_member_designator ')'
Why typespec_nonattr here? I don't see any problem with "struct foo { ...
} __attribute__((__packed__))" (for example) as the type in offsetof.
> + /* This is the second argument to __builtin_offsetof. We must have one
> + identifier, and beyond that we want to accept sub structure and sub
> + array references. We return tree list where each element has
I don't see anything in the C standard to say that offsetof needs to work
for anything other than a simple member of the specified structure type.
Maybe code expects this because macro implementations naturally allow it,
but if it is to be a supported extension then it should be documented as
such, and we should specify when it is meant to be what sort of constant
expression depending on the expressions in array indices (and on the other
GNU extension of variable-length structures).
> + /* Build the result of __builtin_offsetof. TYPE is the first argument to
> + offsetof, i.e. a type. LIST is a tree_list that encodes component and
> + array references; PURPOSE is set for the former and VALUE is set for
> + the later. */
There is a clear opportunity here for better diagnostics than for the
macro implementation, e.g. "`offsetof' applied to an incomplete type",
"`offsetof' applied to a non-structure type", "`offsetof' applied to a
bit-field".
--
Joseph S. Myers
jsm@polyomino.org.uk