Re: invalid offsetof from non-POD type

[Fergus Henderson <fjh at cs dot mu dot OZ dot AU>]

The warning text appears to have been changed.
The new warning is

      warning ("invalid access to non-static data member `%D' of NULL object",
                   member);
      warning  ("(perhaps the `offsetof' macro was used incorrectly)");

I think the warning can be disabled using `-Wno-invalid-offsetof'.

On 12-Aug-2003, skaller <skaller@ozemail.com.au> wrote:
> My understanding is:
> 
> 1. g++ is entitled to issue a warning on non-standard use
> use of offsetof. However, g++ 3.2.2 also issues the same
> diagnostic for the calculation
> 
> 	(unsigned char*)(X*)0 - (unsigned char*)(void*)
> 		(&(((X*)0)->x))
> 
> which it is very misleading.

That is an unfortunate artifact of the implementation.
However, I don't agree that the new warning is misleading.

> If this calculation is invalid,
> the fault lies entirely in the subexpression
> 
> 	((X*)0)->x
> 
> which is probably undefined even if X is a POD.

That expression should IMHO not be undefined if X is a POD and the
expression occurs in an lvalue context (e.g. as the operand of unary &).
Even if the standard implies that `&(((X*)0)->x)' is undefined when X is a POD
(I'm not sure that it does), this is a very pedantic issue; all existing C++
implementations support that kind of thing, and GNU C++ should not warn
about unless `-pedantic' is specified, and maybe not even then.

If X is not a POD, then the design criteria that standard C++ should
support systems that use highly indirect implementations for non-POD
data types implies that that expression should be undefined.
Hence GCC should warn about it.

> 2. The recommendation to use 'pointers to members' instead
> should be removed.

That appears to have been done already.

> 3. At least in g++ 3.2.2 there seems to be no way
> to turn off this warning individually: I am forced
> to use -w to turn off all warnings, which makes me
> very uncomfortable. (Have I missed something?)

Did you try `-Wno-invalid-offsetof'?

> 4. The rule with offsetof was originally formulated as
> is to (a) ensure C compatibility and (b) otherwise
> provide implementors with the maximum freedom.
> 
> Unfortunately, the rule is grossly overzealous,
> and a change in the Standard must be considered necessary.
> 
> An ambitious change would involve fixing pointers to members
> so they might be adequate for tasks currently performed using
> integers, memory pointers and casts.

Sure... but that is an ambitious change.

> A less ambitious change
> would relax the requirements so that provided the member
> was accessible and the access path from the structure unambiguous
> and not crossing a virtual base boundary, the offsetof() macro
> should have a well defined result, being the number of bytes
> offset the member is from the start of the designated structure.

That would prohibit a class of C++ implementations that the C++
committee wanted to permit: those that implement ordinary inheritance
similar to multiple inheritence.   Such implementations avoid compile-time
dependencies on base class sizes, which can drastically reduce the amount
of recompilation required when a base class changes.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.