home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / std / c / 3415 < prev    next >
Encoding:
Internet Message Format  |  1993-01-25  |  2.9 KB
  1. Path: sparky!uunet!psinntp!heimdall!thor!scjones
  2. From: scjones@thor.sdrc.com (Larry Jones)
  3. Newsgroups: comp.std.c
  4. Subject: Re: offsetof in case labels
  5. Message-ID: <554@heimdall.sdrc.com>
  6. Date: 25 Jan 93 17:35:19 GMT
  7. References: <1993Jan21.232337.6527@g2syd.genasys.com.au> <542@heimdall.sdrc.com> <1993Jan25.022444.23917@nntpd.lkg.dec.com>
  8. Sender: news@heimdall.sdrc.com
  9. Lines: 46
  10.  
  11. In article <1993Jan25.022444.23917@nntpd.lkg.dec.com>, diamond@jit345.bad.jit.dec.com (Norman Diamond) writes:
  12. > In article <542@heimdall.sdrc.com> scjones@thor.sdrc.com (Larry Jones) writes:
  13. > >[ about using an omniscient preprocessor to avoid needing a compiler
  14. > >  extension to support sizeof() ]
  15. > 
  16. > The reason why sizeof isn't an operator at preprocessing time, and the
  17. > reason why limits on integral expressions at preprocessing time do not
  18. > have to match limits at later phases (including execution on the target
  19. > machine) is that it is supposed to be possible to write non-omniscient,
  20. > non-integrated generic preprocessors, right?  I think that everyone who
  21. > can read (who can read the standard) will agree that implementations have
  22. > a burden to meet the definition of offsetof.  However, there no longer
  23. > appears to be any rationale for the decisions on sizeof and limits.
  24.  
  25. To the contrary, a non-omniscient, non-integrated generic preprocessor
  26. is still perfectly acceptable, it just requires that the compiler do
  27. whatever is necessary to support sizeof.  Had the committee decided
  28. otherwise on sizeof and limits, such a thing would be impossible.
  29.  
  30. Indeed, implementations do have a burden to meet the definition of
  31. offsetof, just like they have a burden to meet the rest of the
  32. requirements of the language.  offsetof does not appear to be a
  33. particularly difficult case, since every pre-ANSI compiler I know of had
  34. a broader definition of constant expressions than what the standard
  35. requires (and the standard does allow such a broader definition), such
  36. that one of the expressions listed in the Rationale can be used as the
  37. definition of offsetof.  An implementation that does not wish to provide
  38. such a broader definition must choose another method of implementing
  39. offsetof.  The standard provides sufficient latitude that an implementor
  40. is not forced to implement offsetof in a particular way, but rather has
  41. sufficient latitude to select an implementation method that fit in best
  42. with the rest of the implementation.
  43.  
  44. > >Those who care should obtain the collected Requests
  45. > >for Interpretation and Responses which ANSI should be publishing as a
  46. > >Technical Information Bulletin real soon now.)
  47. > 
  48. > Ah!  Please post ordering instructions when that becomes available.
  49.  
  50. I've already promised to do so (but that was so long ago, I'm not
  51. surprised you've forgotten -- either ANSI or X3 or both have been
  52. sitting on the TIB for quite a while).
  53. ----
  54. Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
  55. larry.jones@sdrc.com
  56. These things just seem to happen. -- Calvin
  57.