Path: utzoo!attcan!uunet!husc6!bloom-beacon!spdcc!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.std.c
Subject: Re: The offsetof macro
Message-ID: <7135@haddock.ima.isc.com>
Date: 7 Sep 88 19:28:59 GMT
References: <16490006@hpcllca.HP.COM> <8402@smoke.ARPA>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 26

In article <8402@smoke.ARPA> gwyn@smoke.ARPA (Doug Gwyn) writes:
>In article <16490006@hpcllca.HP.COM> walter@hpcllca.HP.COM (Walter Murray) writes:
>>So what is a valid way to define offsetof?
>
>There is no portable way to #define an offsetof() macro in C.
>The usual method you already know will nonetheless work on a
>large number of implementations.

I don't think the question was about a *portable* way to define it.  The
original poster was noting that the "usual method" involves a macro that
involves some trickery with a null pointer constant, and claimed that since
this violates a constraint, a conforming compiler is required to diagnose an
error.  This would seem to imply that offsetof() *must* be defined as a
compiler builtin, even on well-behaved architectures.

But I don't believe this to be the case.  The relevant portion of 3.4 is under
"Semantics", not "Constraints", and says "Cast operators in an integral
constant expression shall only convert arithmetic types to integral types".  A
violation of a "shall" clause outside a constraint is undefined behavior,
which does not require diagnosis.  Thus, a conforming compiler can do the
right thing with the null pointer hack, and use it in offsetof().

If there really is a violated constraint involved, could someone post the
reference?

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint