invalid offsetof from non-POD type

Joe Buck
Tue Apr 22 18:19:00 GMT 2003

On Tue, Apr 22, 2003 at 05:08:07AM +0200, Gabriel Dos Reis wrote:
> Zack Weinberg <> writes:
> | Gabriel Dos Reis <> writes:
> | 
> | > John Quigley <> writes:
> | >
> | > | While it is not standards compliant code, gcc still provides the correct 
> | > | result. 
> | >
> | > The key issue is what do you define to be the "correct" result when you
> | > apply offsetof() to a non-POD?  
> | 
> | I have never really understood why the C++ standard imposes this
> | restriction.  There would seem to be a well-defined answer to the
> | question posed by offsetof(non-POD, data-member), since the data
> | member does exist in memory at a well-defined offset from the
> | beginning of the object.  If that weren't true the compiler wouldn't
> | be able to generate accesses to it.
> That statement is confused.  
> The issue isn't that the compiler couldn't return some random number. 
> And no, the data do not always exist in memory, for example, a
> subobject of "empty" class type" does not always occupy memory. Let
> alone, subobject of morally virtual base classes.  Which begs my
> question.

There are cases where offsetof() could not possibly return a meaningful
value; in particular, for virtual base classes, the compiler must in
general dereference one or more pointers to get to the field, so there
is no fixed offset between the class object address and the field address
(in GCC's implementation of a virtual base class, the derived class object
must follow a pointer to get to the base class fields).

For empty fields, as Gaby mentions, there is also an issue, because the
object is not in fact stored in the struct/class at all (it has no fields,
and all its presence does is provide operations for the class as a whole),
however, the user is unlikely to care about this (there isn't a reason why
the user would want to use offsetof for an empty field).

However, I believe that the specification in the ISO standard is too
strict, and sometimes leads to inconveniences for the developer.
Frequently in mixed C/C++ systems, it is convenient to have data types
that are POD in every way except for the presence of a constructor, for
easier initialization.  Clearly for such types, offsetof can be
well-defined.  This means that the restrictions on offsetof() could be

Unfortunately, to do this right, some thought would have to go into a
specification of the extension.  And then there's the interaction of
offsetof issues with type-based aliasing, which is a whole new can of

More information about the Gcc-bugs mailing list