Path: utzoo!utstat!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!usc!apple!sun-barr!newstop!east!jeska!gsteckel
From: gsteckel@jeska.East.Sun.COM (Geoff Steckel - Sun BOS Software)
Newsgroups: news.software.b
Subject: Re: Cnews on System V/AT: "expression causes compiler loop"
Summary: (int) ((type *)0->element) wins
Keywords: compiler structures
Message-ID: <1063@east.East.Sun.COM>
Date: 21 Nov 89 16:28:38 GMT
References: <3056@splut.conmicro.com> <1989Nov20.181839.1546@utzoo.uucp> <1676@crdos1.crd.ge.COM>
Sender: news@east.East.Sun.COM
Reply-To: gws%omnivor.uucp@wjh12.harvard.edu
Distribution: na
Organization: Omnivore Technology, Newton, Mass.
Lines: 22

In article <1676@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes:
>In article <1989Nov20.181839.1546@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>| The offsetof() macro has a tendency to stress-test compilers.  Try:
>| #define offsetof(type, mem) ((int)&((type *)NULL)->mem)
>| as an alternative.
>
>  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.
>bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)

Last time I looked, ANSI-fied C compilers were required to accept that
as the best way to determine offsets (inasmuch as an offset made sense
on the implementation/hardware).  The subtraction scheme was deprecated.
This may have changed in the intervening months - and we all know how
thoroughly compliant compilers can be...  Every PCC-based and Green Hills
compiler I've tried (ANSI and non-ANSI) has accepted it correctly.
	geoff steckel (gws%omnivor.uucp@wjh12.harvard.EDU)
			(...!husc6!wjh12!omnivor!gws)
Disclaimer: I am not affiliated with Sun Microsystems, despite the From: line.
This posting is entirely the author's responsibility.