Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!decwrl!bacchus.pa.dec.com!rust.zso.dec.com!shlump.nac.dec.com!tkou02.enet.dec.com!diamond From: diamond@tkou02.enet.dec.com (diamond@tkovoa) Newsgroups: comp.std.c Subject: Re: Another sizeof question Message-ID: <1990Nov2.034300.3065@tkou02.enet.dec.com> Date: 2 Nov 90 03:43:00 GMT References: <13171@crdgw1.crd.ge.com> <492@taumet.com> Reply-To: diamond@tkou02.enet.dec.com (diamond@tkovoa) Organization: Digital Equipment Corporation Japan , Tokyo Lines: 21 In article meissner@osf.org (Michael Meissner) writes: >When I worked at Data General on the MV C compiler, I added sizeof >support to the preprocessor (which is called as a coroutine from >within the lexer). Because the preprocessor was built into the >compiler, it involved no hand wringing. In fact, it would have been >more work to disable sizeof, since the same parser was used to parse >#if/#elif expressions as the normal expressions. "WOULD HAVE BEEN more work"? Do you mean that this work was not done? As I understand the standard, a conforming processor is not allowed to support this extension, even with a warning, even with a #pragma, etc. A conforming processor is REQUIRED to substitute 0 for the identifier sizeof (in an #if expression) if sizeof doesn't have a #defined value. (#define sizeof __what_we_really_want_from_sizeof, maybe. But you still can't parse an un#defined sizeof that way.) -- Norman Diamond, Nihon DEC diamond@tkov50.enet.dec.com (tkou02 is scheduled for demolition) We steer like a sports car: I use opinions; the company uses the rack.