🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c
Article #3298

Re: offsetof in case labels

#3298
From: Larry Jones
Date: Mon, 25 Jan 1993 17:35
46 lines
3047 bytes
In article <1993Jan25.022444.23917@nntpd.lkg.dec.com>, diamond@jit345.bad.jit.dec.com (Norman Diamond) writes:
> In article <542@heimdall.sdrc.com> scjones@thor.sdrc.com (Larry Jones) writes:
> >[ about using an omniscient preprocessor to avoid needing a compiler
> >  extension to support sizeof() ]
> 
> 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.

To the contrary, a non-omniscient, non-integrated generic preprocessor
is still perfectly acceptable, it just requires that the compiler do
whatever is necessary to support sizeof.  Had the committee decided
otherwise on sizeof and limits, such a thing would be impossible.

Indeed, implementations do have a burden to meet the definition of
offsetof, just like they have a burden to meet the rest of the
requirements of the language.  offsetof does not appear to be a
particularly difficult case, since every pre-ANSI compiler I know of had
a broader definition of constant expressions than what the standard
requires (and the standard does allow such a broader definition), such
that one of the expressions listed in the Rationale can be used as the
definition of offsetof.  An implementation that does not wish to provide
such a broader definition must choose another method of implementing
offsetof.  The standard provides sufficient latitude that an implementor
is not forced to implement offsetof in a particular way, but rather has
sufficient latitude to select an implementation method that fit in best
with the rest of the implementation.

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

I've already promised to do so (but that was so long ago, I'm not
surprised you've forgotten -- either ANSI or X3 or both have been
sitting on the TIB for quite a while).
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com
These things just seem to happen. -- Calvin
Technical Details
Message-ID: <554@heimdall.sdrc.com>
Path: arc1-ca.pugleaf.net!sparky!uunet!psinntp!heimdall!thor!scjones
References: <1993Jan21.232337.6527@g2syd.genasys.com.au> <542@heimdall.sdrc.com> <1993Jan25.022444.23917@nntpd.lkg.dec.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!psinntp!heimdall!thor!scjones
From: scjones@thor.sdrc.com (Larry Jones)
Newsgroups: comp.std.c
Subject: Re: offsetof in case labels
Message-ID: <554@heimdall.sdrc.com>
Date: 25 Jan 93 17:35:19 GMT
References: <1993Jan21.232337.6527@g2syd.genasys.com.au> <542@heimdall.sdrc.com> <1993Jan25.022444.23917@nntpd.lkg.dec.com>
Sender: news@heimdall.sdrc.com
Lines: 46