home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / std / c / 3409 < prev    next >
Encoding:
Text File  |  1993-01-24  |  2.7 KB  |  57 lines
  1. Newsgroups: comp.std.c
  2. Path: sparky!uunet!decwrl!pa.dec.com!engage.pko.dec.com!nntpd.lkg.dec.com!jit345.bad.jit.dec.com!diamond
  3. From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
  4. Subject: Re: offsetof in case labels
  5. Message-ID: <1993Jan25.022444.23917@nntpd.lkg.dec.com>
  6. Sender: usenet@nntpd.lkg.dec.com (USENET News System)
  7. Reply-To: diamond@jit.dec.com (Norman Diamond)
  8. Organization: Digital Equipment Corporation Japan , Tokyo
  9. References: <1993Jan21.232337.6527@g2syd.genasys.com.au> <542@heimdall.sdrc.com>
  10. Date: Mon, 25 Jan 1993 02:24:44 GMT
  11. Lines: 44
  12.  
  13. In article <542@heimdall.sdrc.com> scjones@thor.sdrc.com (Larry Jones) writes:
  14. >[...] an otherwise strictly conforming program that uses
  15. >offsetof in a strictly conforming fashion is still strictly conforming
  16. >reguardless of the expansion of the macro.  The RFI, suspecting this to
  17. >be the committee's response, goes on to point out that this *requires*
  18. >an implementation to implement an extension of some sort in order to
  19. >implement offsetof and argues that this is inappropriate.  While this is
  20. >the most common method of implementing offsetof (generally by extending
  21. >the implementation's definition of constant expression, which the
  22. >standard allows, or by adding a new keyword), it is not, strictly
  23. >speaking, necessary.  All that is required is an omniscient preprocessor
  24. >that can expand offsetof to the correct integer constant -- not a
  25. >difficult task if the preprocessor is an integral part of the compiler
  26. >with access to the symbol table.
  27.  
  28. !
  29.  
  30. That is true, but suggests a previously unexposed bit of hypocrisy.
  31. The reason why sizeof isn't an operator at preprocessing time, and the
  32. reason why limits on integral expressions at preprocessing time do not
  33. have to match limits at later phases (including execution on the target
  34. machine) is that it is supposed to be possible to write non-omniscient,
  35. non-integrated generic preprocessors, right?  I think that everyone who
  36. can read (who can read the standard) will agree that implementations have
  37. a burden to meet the definition of offsetof.  However, there no longer
  38. appears to be any rationale for the decisions on sizeof and limits.
  39.  
  40. >Those who care should obtain the collected Requests
  41. >for Interpretation and Responses which ANSI should be publishing as a
  42. >Technical Information Bulletin real soon now.)
  43.  
  44. Ah!  Please post ordering instructions when that becomes available.
  45.  
  46. >[...] it's actually quite readable for a language standard;
  47.  
  48. True, but...
  49.  
  50. >a bit more difficult than K&R Appendix A, perhaps, but not significantly so.
  51.  
  52. A bit less ambiguous than K&R Appendix A, perhaps, but not significantly so.
  53. --
  54. Norman Diamond                diamond@jit.dec.com
  55. If this were the company's opinion, I wouldn't be allowed to post it.
  56. Pardon me?  Or do I have to commit a crime first?
  57.