Re: invalid offsetof from non-POD type

[skaller <skaller at ozemail dot com dot au>]

This email refers to an archived thread on this topic.
My question is whether some action has been taken with
respect to this issue.

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. 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.

2. The recommendation to use 'pointers to members' instead
should be removed. The pointer to member semantics in C++
are incomplete and inadequate for certain tasks where
an integral offset is required, for example by a lower
level memory management routine.

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?)

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. 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.

In the meantime however, I think g++ would best serve the
community by continuing to issue a warning by default,
a hard error if enough strictness options are enabled,
and neither an error nor diagnostic if a specific switch
is set: it seems likely g++ already generates the correct code
in cases it warns about.

My particular product generates a large number of data structures
which are intended to be collected by an exact garbage collector,
and in order for the collector to operate it must know the location
of all pointers in the system. My tool generates tables containing
this data, but it must use the offsetof() macro to do so.

The only alternative I have is to bypass C++ completely and
layout all data structures manually -- forgoing any real opportunity
for C/C++ interoperability, which is one of the products key features.

I *cannot* live with the warning. It is out of the question for
a compiler to systematically generate a large number of these
spurious warnings, which it is guarranteed to do for every
piece of code my tool generates.