Article View: comp.std.c
Article #3292Re: offsetof in case labels
From: Norman Diamond
Date: Mon, 25 Jan 1993 02:24
Date: Mon, 25 Jan 1993 02:24
44 lines
2860 bytes
2860 bytes
In article <542@heimdall.sdrc.com> scjones@thor.sdrc.com (Larry Jones) writes: >[...] an otherwise strictly conforming program that uses >offsetof in a strictly conforming fashion is still strictly conforming >reguardless of the expansion of the macro. The RFI, suspecting this to >be the committee's response, goes on to point out that this *requires* >an implementation to implement an extension of some sort in order to >implement offsetof and argues that this is inappropriate. While this is >the most common method of implementing offsetof (generally by extending >the implementation's definition of constant expression, which the >standard allows, or by adding a new keyword), it is not, strictly >speaking, necessary. All that is required is an omniscient preprocessor >that can expand offsetof to the correct integer constant -- not a >difficult task if the preprocessor is an integral part of the compiler >with access to the symbol table. ! That is true, but suggests a previously unexposed bit of hypocrisy. The reason why sizeof isn't an operator at preprocessing time, and the reason why limits on integral expressions at preprocessing time do not have to match limits at later phases (including execution on the target machine) is that it is supposed to be possible to write non-omniscient, non-integrated generic preprocessors, right? I think that everyone who can read (who can read the standard) will agree that implementations have a burden to meet the definition of offsetof. However, there no longer appears to be any rationale for the decisions on sizeof and limits. >Those who care should obtain the collected Requests >for Interpretation and Responses which ANSI should be publishing as a >Technical Information Bulletin real soon now.) Ah! Please post ordering instructions when that becomes available. >[...] it's actually quite readable for a language standard; True, but... >a bit more difficult than K&R Appendix A, perhaps, but not significantly so. A bit less ambiguous than K&R Appendix A, perhaps, but not significantly so. -- Norman Diamond diamond@jit.dec.com If this were the company's opinion, I wouldn't be allowed to post it. Pardon me? Or do I have to commit a crime first?
Technical Details
Message-ID:
<1993Jan25.022444.23917@nntpd.lkg.dec.com>Path:
arc1-ca.pugleaf.net!sparky!uunet!decwrl!pa.dec.com!engage.pko.dec.com!nntpd.lkg.dec.com!jit345.bad.jit.dec.com!diamondReferences:
<1993Jan21.232337.6527@g2syd.genasys.com.au> <542@heimdall.sdrc.com>Show Full Headers
Complete Article Headers
Newsgroups: comp.std.c Path: arc1-ca.pugleaf.net!sparky!uunet!decwrl!pa.dec.com!engage.pko.dec.com!nntpd.lkg.dec.com!jit345.bad.jit.dec.com!diamond From: diamond@jit345.bad.jit.dec.com (Norman Diamond) Subject: Re: offsetof in case labels Message-ID: <1993Jan25.022444.23917@nntpd.lkg.dec.com> Sender: usenet@nntpd.lkg.dec.com (USENET News System) Reply-To: diamond@jit.dec.com (Norman Diamond) Organization: Digital Equipment Corporation Japan , Tokyo References: <1993Jan21.232337.6527@g2syd.genasys.com.au> <542@heimdall.sdrc.com> Date: Mon, 25 Jan 1993 02:24:44 GMT Lines: 44