Draft pre-DR: offsetof

["Joseph S. Myers" <jsm at polyomino dot org dot uk>]

This draft pre-DR, the third in a series, relates to the question of
what arguments offsetof must support, as discussed in
<http://gcc.gnu.org/ml/gcc-patches/2003-12/msg01508.html> and thread.
There was a clear conclusion that we should continue to support unions
and references to nested substructures and arrays in offsetof; the
question is the extent to which this is an extension to what the
standard requires support for (and so should be documented as such).
Comments and corrections welcome.

I have three more issues that have arisen somehow through GCC or glibc
development on which I will be preparing pre-DRs, but which haven't
come so directly from discussions on the GCC mailing lists.  When
those are done I'll send a URL rather than sending the pre-DRs
themselves to this list.

Pre-DR: offsetof
================

offsetof is defined in 7.17#3 as

               offsetof(type, member-designator)

       which  expands  to  an  integer constant expression that has
       type size_t, the value of which is the offset in  bytes,  to
       the structure member (designated by member-designator), from
       the beginning of its structure (designated  by  type).   The
       type and member designator shall be such that given

               static type t;

       then  the  expression &(t.member-designator) evaluates to an
       address constant.  (If the specified member is a  bit-field,
       the behavior is undefined.)

The question is: what arguments are implementations required to accept
as "type" and "member-designator"?  (It is clear that all cases here
_may_ be accepted by implementations as extensions without
diagnostics; all questions relate strictly to whether implementations
are _required_ to accept some particular usage.)

Must "type" be a structure type, or may it be a union type?  The
standard refers to a structure member, and unions might not be very
useful depending on the answer to the next question, but the C++
standard [lib.support.types] restricts offsetof from the C definition
by saying "type shall be a POD structure or a POD union", so it seems
that the authors of the C++ standard read the C standard as allowing
unions.  (There are no relevant changes here between C90, which the
C++ standard references, and C99.)

May "type" define a new type (then in scope for the rest of the
current scope if a tag is included)?  For example, is "struct s { int
a; }" a valid type argument?  It appears to meet the requirements of
the standard, and in C (but not C++) types may be defined in casts and
sizeof.

"member-designator" is referred to as a "structure member".  Must it
be a single identifier that names a member of the specified type, or
may it be something such as "a.b.c" or "a.c[2]" that names a member of
a subobject?  If the latter is permitted, what are the requirements on
array indices (bearing in mind that the result is an integer constant
expression)?

-- 
Joseph S. Myers
jsm@polyomino.org.uk