Newsgroups: news.software.b
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: Cnews on System V/AT: "expression causes compiler loop"
Message-ID: <1989Nov21.175136.3418@utzoo.uucp>
Organization: U of Toronto Zoology
References: <3056@splut.conmicro.com> <1989Nov20.181839.1546@utzoo.uucp> <1676@crdos1.crd.ge.COM> <1063@east.East.Sun.COM>
Date: Tue, 21 Nov 89 17:51:36 GMT

>>| #define offsetof(type, mem) ((int)&((type *)NULL)->mem)
>>
>>  I would be very careful using this. Althoug I feel that the use of a
>>zero cast to a non-void type is legal in sizeof, because of qualifying
>>statements promising that it is not evaluated, I would not be surprized
>>to see a compiler reject this one.

Most any way of computing the offset into a struct is inherently somewhat
unportable.  Both this and the original will work on most orthodox systems;
neither is guaranteed.

>Last time I looked, ANSI-fied C compilers were required to accept that
>as the best way to determine offsets...

Not so.  ANSI C implementations are required to provide an offsetof() macro
that works... somehow.  No specific technique is promised to work; the
implementation of that macro uses whatever black magic is appropriate, up
to and including the possibility of invoking special compiler primitives.

If we could have assumed an ANSI implementation, the whole issue would go
away, because we wouldn't have to supply our own offsetof().
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
