volpe@camelback.crd.ge.com (Christopher R Volpe) (10/28/90)
Can someone tell me whether "sizeof" expressions are allowed as operands of "#if"? I'm trying to do some conditional compilation based on the size of some data structure, and I get parse errors before sizeof. The Bible says "sizeof" yields a constant integer, and that #if requires an integral constant expression, so I can't tell what's wrong. Can someone clue me in? Thanks. BTW, I'm using gcc to compile. ================== Chris Volpe G.E. Corporate R&D volpecr@crd.ge.com
steve@taumet.com (Stephen Clamage) (10/29/90)
volpe@camelback.crd.ge.com (Christopher R Volpe) writes: >Can someone tell me whether "sizeof" expressions are allowed as >operands of "#if"? I'm trying to do some conditional compilation >based on the size of some data structure, and I get parse errors >before sizeof. The Bible says "sizeof" yields a constant integer, >and that #if requires an integral constant expression, so I can't >tell what's wrong. Can someone clue me in? Thanks. In ANSI C, sizeof may not usefully appear in an #if because it is part of a different phase of translation. The preprocessor knows nothing about types or variables, and sizeof is not a preprocessor keyword. The preprocessor must treat "sizeof" as it does any undefined macro name. Some C compilers support sizeof in the preprocessor. The results are then kind of weird. Such preprocessors sometimes recognize the size of the built-in types (int, long, etc), but not user types. Recognizing the size of user types is part of the C compilation process, not just preprocessing, so a stand-alone preprocessor must either act as a complete C parser, or act differently than when it is part of the complete compilation. -- Steve Clamage, TauMetric Corp, steve@taumet.com
yiannis@ccad.uiowa.edu (Yiannis Papelis) (10/29/90)
In article <13171@crdgw1.crd.ge.com> volpe@camelback.crd.ge.com (Christopher R Volpe) writes: >Can someone tell me whether "sizeof" expressions are allowed as >operands of "#if"? I'm trying to do some conditional compilation >based on the size of some data structure, and I get parse errors >before sizeof. The Bible says "sizeof" yields a constant integer, >and that #if requires an integral constant expression, so I can't >tell what's wrong. Can someone clue me in? Thanks. > >BTW, I'm using gcc to compile. > sizeof expressions 'become' a constant integer at compile time. In other words only the compiler knows what sizeof(whatever) is. Since the preproccessor runs before the compiler it has no way of knowing the value of sizeof. Yiannis E. Papelis Department of Electrical and Computer Engineering, University of Iowa. yiannis@eng.uiowa.edu
henry@zoo.toronto.edu (Henry Spencer) (10/29/90)
In article <13171@crdgw1.crd.ge.com> volpe@camelback.crd.ge.com (Christopher R Volpe) writes: >Can someone tell me whether "sizeof" expressions are allowed as >operands of "#if"? ... In ANSI C, no, they are not. Preprocessing is done before there is any notion of declarations, types, storage layout, or sizes. In a #if, `sizeof' is just another identifier. >...The Bible says "sizeof" yields a constant integer, >and that #if requires an integral constant expression, so I can't >tell what's wrong... It's not clear which Bible you are reading. :-) Is it the Old Testament (K&R1), the New Testament (K&R2), or the New American Edition (ANSI)? In a sufficiently modern and complete edition, you will find the rule against this down in the fine print. >BTW, I'm using gcc to compile. Note that GNU C and standard C are only somewhat related. -- "I don't *want* to be normal!" | Henry Spencer at U of Toronto Zoology "Not to worry." | henry@zoo.toronto.edu utzoo!henry
gwyn@smoke.brl.mil (Doug Gwyn) (10/29/90)
In article <13171@crdgw1.crd.ge.com> volpe@camelback.crd.ge.com (Christopher R Volpe) writes: >Can someone tell me whether "sizeof" expressions are allowed as >operands of "#if"? I'm trying to do some conditional compilation >based on the size of some data structure, and I get parse errors >before sizeof. The Bible says "sizeof" yields a constant integer, >and that #if requires an integral constant expression, so I can't >tell what's wrong. Can someone clue me in? Thanks. While the identifier "sizeof" may be used in the integral constant expression controlling conditional inclusion (i.e. operand of #if), you need to be aware that this stuff occurs during translation phase 4, involving preprocessing tokens, not "pure C language" tokens. Thus, language keywords (such as "sizeof") have no special meaning; identifiers are macro-substituted and any that had no substitutions are then replaced with "0". It is the result of that substitution that is evaluated for the constant expression. Thus, there can be no enumeration constants, types, and so forth involved in the condition.
volpe@camelback.crd.ge.com (Christopher R Volpe) (10/29/90)
Thank you, everyone who responded, for the information on "sizeof". Alan Rosenthal, Bill Wells, Ray Chen, Birger Wathne, and Anders Thulin responded through email. Thank you very much. The general consensus was that sizeof is not available to the preprocessor. If I had spent 30 seconds thinking about *why* it might not be, I would have realized this. Sorry for wasting the bandwidth. ================== Chris Volpe G.E. Corporate R&D volpecr@crd.ge.com
meissner@osf.org (Michael Meissner) (10/31/90)
In article <492@taumet.com> steve@taumet.com (Stephen Clamage) writes: | Some C compilers support sizeof in the preprocessor. The results are | then kind of weird. Such preprocessors sometimes recognize the size of | the built-in types (int, long, etc), but not user types. Recognizing | the size of user types is part of the C compilation process, not just | preprocessing, so a stand-alone preprocessor must either act as a | complete C parser, or act differently than when it is part of the | complete compilation. 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. This turned out to be useful in non-portable system codes to make sure a structure was the precise size needed by the external specification. Many of the internal DG types complained when the GNU and Greenhills compilers on the 88k did not support this feature.... -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Do apple growers tell their kids money doesn't grow on bushes?
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (10/31/90)
In <13171@crdgw1.crd.ge.com> volpe@camelback.crd.ge.com (Christopher R Volpe) writes: >Can someone tell me whether "sizeof" expressions are allowed as >operands of "#if"? There do exist compilers that allow sizeof in expressions that are operands of #if. A careful reading of K&R between the lines suggests that sizeof in #if should be legal, but they don't outright say so. ANSI C disallows sizeof in #if so that the preprocessor may be implemented independently of the compiler. I was a little surprised to discover that ANSI C tries to allow the preprocessor to be separately implementable, but it does not require it to be separately available. -- Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi A pointer is not an address. It is a way of finding an address. -- me
volpe@camelback.crd.ge.com (Christopher R Volpe) (11/01/90)
In article <1990Oct28.223702.27918@zoo.toronto.edu>, henry@zoo.toronto.edu (Henry Spencer) writes: |>In article <13171@crdgw1.crd.ge.com> volpe@camelback.crd.ge.com (Christopher R Volpe) writes: |>>...The Bible says "sizeof" yields a constant integer, |>>and that #if requires an integral constant expression, so I can't |>>tell what's wrong... |> |>It's not clear which Bible you are reading. :-) Is it the Old Testament |>(K&R1), the New Testament (K&R2), or the New American Edition (ANSI)? |>In a sufficiently modern and complete edition, you will find the rule |>against this down in the fine print. The "Bible" I was referring to is the American National Standard X3.159-1989. I understand now what the rule is regarding sizeof, and why it is. But, could you or someone else point me to a reference in the Standard that says that a constant expression in a preprocessor context cannot contain sizeof? I'm sure it's in there but I can't find it. thanks, Chris ================== Chris Volpe G.E. Corporate R&D volpecr@crd.ge.com
gwyn@smoke.brl.mil (Doug Gwyn) (11/01/90)
In article <13294@crdgw1.crd.ge.com> volpe@camelback.crd.ge.com (Christopher R Volpe) writes: >But, could you or someone else point me to a reference in the Standard >that says that a constant expression in a preprocessor context cannot >contain sizeof? It doesn't say that. The following is strictly conforming: #define sizeof 42+ #define a (-40) #if sizeof a > 2 #include <banana.h> #endif #undef sizeof
henry@zoo.toronto.edu (Henry Spencer) (11/02/90)
In article <2638@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: >I was a little surprised to discover that ANSI C tries to allow the >preprocessor to be separately implementable, but it does not require it >to be separately available. Why the surprise? There is a big difference between "allows" and "requires" when we are talking about a language that is already in widespread use with many divergent implementations. -- "I don't *want* to be normal!" | Henry Spencer at U of Toronto Zoology "Not to worry." | henry@zoo.toronto.edu utzoo!henry
henry@zoo.toronto.edu (Henry Spencer) (11/02/90)
In article <13294@crdgw1.crd.ge.com> volpe@camelback.crd.ge.com (Christopher R Volpe) writes: >But, could you or someone else point me to a reference in the Standard >that says that a constant expression in a preprocessor context cannot >contain sizeof? I'm sure it's in there but I can't find it. Note, in 3.1, that the definition of preprocessing-token does not include `keyword' as a possibility. Until pp-tokens get converted to tokens in phase 7 (see 2.1.1.2), `sizeof' is an identifier, not a keyword. And in 3.8.1, we see that in #if, after macro substitution and etc, "all remaining identifiers are replaced with the pp-number 0, and then each preprocessing token is converted into a token". So `sizeof' can appear in #if, but it is an ordinary identifier, not the keyword that denotes the operator described in 3.3.3.4. No facility of C expressions that is invoked via a keyword can be used in #if expressions. -- "I don't *want* to be normal!" | Henry Spencer at U of Toronto Zoology "Not to worry." | henry@zoo.toronto.edu utzoo!henry
steve@taumet.com (Stephen Clamage) (11/02/90)
Chris Volpe writes: >I understand now what the rule is regarding sizeof, and why it is. >But, could you or someone else point me to a reference in the Standard >that says that a constant expression in a preprocessor context cannot >contain sizeof? I'm sure it's in there but I can't find it. To the preprocessor, sizeof is just an identifier, not a keyword. You will note that the Standard section 3.8 describes what the preprocessor recognizes, and sizeof is not mentioned. Neither are "for", "while", "switch", or other C keywords. Consider this: int x; #if goto(x) == 2 or this: int x; extern int foo(int); #if foo(x) == 2 Writing int x; #if sizeof(x) == 2 has precisely the same effect. "Goto", "foo", and "sizeof" are treated by the preprocessor as ordinary identifiers: if they are not #defined to the proprocessor, they are treated as constant integers with value 0. -- Steve Clamage, TauMetric Corp, steve@taumet.com
browns@iccgcc.decnet.ab.com (Stan Brown) (11/02/90)
In article <13294@crdgw1.crd.ge.com>, volpe@camelback.crd.ge.com (Christopher R Volpe) writes: > The "Bible" I was referring to is the American National Standard X3.159-1989. > I understand now what the rule is regarding sizeof, and why it is. > But, could you or someone else point me to a reference in the Standard > that says that a constant expression in a preprocessor context cannot > contain sizeof? I'm sure it's in there but I can't find it. Chris, I haven't got a copy of the standard with me at this location, but I think the index will help you. Hint: ask the question in a different way. Don't look under sizeof, but under #if. If memory serves, you'll find references to a "restricted constant expression" and if you'll follow that down you'll find that things involving program variables and types are _not_ part of it. So it's not sizeof per se, but any possible "argument" to sizeof that is the problem. Sorry I don't have a section reference for you, but nobody else has posted one and the above at least should get you started. Please do not attribute these remarks to any other person or company. email: browns@iccgcc.decnet.ab.com Stan Brown, Oak Road Systems, Cleveland, Ohio, USA +1 216 371 0043
diamond@tkou02.enet.dec.com (diamond@tkovoa) (11/02/90)
In article <MEISSNER.90Oct30121525@osf.osf.org> 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.
volpe@camelback.crd.ge.com (Christopher R Volpe) (11/03/90)
Henry- Thank you for the thorough and informative explanation and references. -Chris ================== Chris Volpe G.E. Corporate R&D volpecr@crd.ge.com
meissner@osf.org (Michael Meissner) (11/03/90)
In article <1990Nov2.034300.3065@tkou02.enet.dec.com> diamond@tkou02.enet.dec.com (diamond@tkovoa) writes: | In article <MEISSNER.90Oct30121525@osf.osf.org> 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. Given that the feature in question was written BEFORE the first ANSI standards meeting took place (I know I wrote the feature, and was at the first meeting), I don't see how I should have been clarvoient to predict the twisty little turns that a future standard would take. Yes, to meet the standard nowadays the work would have to be done, to recognize and flag the use of sizeof. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Do apple growers tell their kids money doesn't grow on bushes?
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (11/06/90)
>>I was a little surprised to discover that ANSI C tries to allow the >>preprocessor to be separately implementable, but it does not require it >>to be separately available. >Why the surprise? Because at the time that ANSI was in the middle of developing the standard, so far as I could tell, all existing substantially complete implementations of K&R's C provided a way of doing preprocessing only. (Actually, VAX/VMS was a near-exception, but then again, VAX/VMS is *always* a near-exception to *everything*.) -- Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi A pointer is not an address. It is a way of finding an address. -- me
gwyn@smoke.brl.mil (Doug Gwyn) (11/06/90)
In article <2654@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: >Because at the time that ANSI was in the middle of developing the >standard, so far as I could tell, all existing substantially complete >implementations of K&R's C provided a way of doing preprocessing only. There were at least a couple of commercial C compilers with "tokenizing" preprocessors; they may have allowed the result of preprocessing to be converted back into some form of source code for people who requested such a facility or they may not (I don't recall). In any case, we have been telling people for years that if they want a macro processor they should use something like "m4" rather than rely on cpp.
rns@se-sd.SanDiego.NCR.COM (Rick Schubert) (11/07/90)
In <2638@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: >I was a little surprised to discover that ANSI C tries to allow the >preprocessor to be separately implementable, but it does not require it >to be separately available. Remember that the task of X3J11 was to define the C language. It tried not to dictate how to implement the language (other than to specify what the language was that was to be implemented; I know that's a simplification). Requiring such things listings, cross-references, assembly language output, and preprocessor output was beyond the charter of the Committee. -- Rick Schubert (rns@se-sd.sandiego.NCR.COM)
rns@se-sd.SanDiego.NCR.COM (Rick Schubert) (11/07/90)
In <1990Nov2.034300.3065@tkou02.enet.dec.com> diamond@tkou02.enet.dec.com (diamond@tkovoa) writes: >In article <MEISSNER.90Oct30121525@osf.osf.org> meissner@osf.org (Michael Meissner) writes: >>When I worked at Data General on the MV C compiler, I added sizeof >>support to the preprocessor >As I understand the standard, a conforming processor is not allowed to >support this extension, even with a warning, even with a #pragma, etc. Others have replied to other aspects of this issue. I just wanted to add that everything is allowed via a #pragma. X3J11 reaffirmed at some point that the behavior of any program with a #pragma is implementation defined, so a #pragma can do anything. -- Rick Schubert (rns@se-sd.sandiego.NCR.COM)
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (11/09/90)
In <14343@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
In any case, we have been telling people for years that if they
want a macro processor they should use something like "m4" rather
than rely on cpp.
Were UNIX the only environment to be considered, m4 could be considered
a tolerable macro processor. But include non-UNIX systems, and the
*only* macro processor that comes close to being ubiquitous and a de
facto standard is the one described by K&R. This is why it's a loss
that the standardization of C wasn't accompanied by the standardization
of C's preprocessor as a stand-alone program.
--
Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com>
UUCP: oliveb!cirrusl!dhesigwyn@smoke.brl.mil (Doug Gwyn) (11/11/90)
In article <2670@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: >In <14343@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: > In any case, we have been telling people for years that if they > want a macro processor they should use something like "m4" rather > than rely on cpp. >Were UNIX the only environment to be considered, m4 could be considered >a tolerable macro processor. I said, "something like "m4"". For example, use the one in "Software Tools". >The *only* macro processor that comes close to being ubiquitous and a de >facto standard is the one described by K&R. This is why it's a loss >that the standardization of C wasn't accompanied by the standardization >of C's preprocessor as a stand-alone program. The C preprocessor has never been a general-purpose macro processor, as should be well known to anyone who has tried to use it as one. Further, it was never required to be implemented separately from the C compiler, and indeed it was integrated into the compiler in a number of implementations. I get rather tired of people saying that the C standard should have mandated exactly the parochial little enviropnment that they happened to grow up in.
news@male.EBay.Sun.COM (news) (11/16/90)
>In <1990Nov2.034300.3065@tkou02.enet.dec.com> diamond@tkou02.enet.dec.com (diamond@tkovoa) writes: >>In article <MEISSNER.90Oct30121525@osf.osf.org> meissner@osf.org (Michael Meissner) writes: mm>>>When I worked at Data General on the MV C compiler, I added sizeof mm>>>support to the preprocessor nd>>As I understand the standard, a conforming processor is not allowed to nd>>support this extension, even with a warning, even with a #pragma, etc. rs>Others have replied to other aspects of this issue. I just wanted to add rs>that everything is allowed via a #pragma. X3J11 reaffirmed at some point rs>that the behavior of any program with a #pragma is implementation defined, rs>so a #pragma can do anything. If this is really true, it defeats the purpose of #pragma. My understanding was that #pragma may have any implementation-defined effect WHICH does not change the meaning of a conforming program (though it may change the effect of a nonconforming program). That definition would have been far more useful. For example, a conforming program, optimized for processor ABC: struct some_tag { #pragma align 2 unsigned x; #pragma align 1 float y; }; [the rest of a conforming program, using a struct some_tag] On processor XYZ, which does not recognize #pragma align or which gives a different meaning than processor ABC did, this conforming program would still be guaranteed correct results, just not optimally, if my understanding was correct. But it may be given garbage results of Mr. Schubert's understanding is correct. I hope (truly) to hear that Mr. Schubert is mistaken. -- 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. From: root@cho.uucp (Operator) Path: cho!root
henry@zoo.toronto.edu (Henry Spencer) (11/17/90)
In article <3928@male.EBay.Sun.COM> diamond@tkou02.enet.dec.com (diamond@tkovoa) writes: >rs>... everything is allowed via a #pragma. X3J11 reaffirmed at some point >rs>that the behavior of any program with a #pragma is implementation defined, >rs>so a #pragma can do anything. > >If this is really true, it defeats the purpose of #pragma. My understanding >was that #pragma may have any implementation-defined effect WHICH does not >change the meaning of a conforming program ... Sorry, not so. 3.8.6 states simply that #pragma has an implementation-defined effect. Period. No restrictions are explicit, and it does not appear to be possible to infer them. (The standard attempt to infer them states that one must read the standard as a whole, so 3.8.6 is subject to constraints imposed elsewhere. The standard counterargument is that the rest of the standard is subject to the constraint imposed in 3.8.6, i.e. that the presence of a #pragma has implementation-defined effects, and so nothing can be said about how the rest of the standard applies in such a situation.) -- "I don't *want* to be normal!" | Henry Spencer at U of Toronto Zoology "Not to worry." | henry@zoo.toronto.edu utzoo!henry
gwyn@smoke.brl.mil (Doug Gwyn) (11/17/90)
In article <3928@male.EBay.Sun.COM> diamond@tkou02.enet.dec.com (diamond@tkovoa) writes: >If this is really true, it defeats the purpose of #pragma. My understanding >was that #pragma may have any implementation-defined effect WHICH does not >change the meaning of a conforming program (though it may change the effect >of a nonconforming program). That definition would have been far more useful. That was my argument, but when Walter Murray requested a formal ruling on this, even I had to agree that the wording in the C standard leads to the conclusion that a strictly conforming program cannot use #pragma.
shankar@hpclscu.HP.COM (Shankar Unni) (11/20/90)
Doug Gwyn writes in response to a note from Norman Diamond: > In article <3928@male.EBay.Sun.COM> diamond@tkou02.enet.dec.com (diamond@tkovoa) writes: > >If this is really true, it defeats the purpose of #pragma. My understanding > >was that #pragma may have any implementation-defined effect WHICH does not > >change the meaning of a conforming program (though it may change the effect > >of a nonconforming program). That definition would have been far more useful. > > That was my argument, but when Walter Murray requested a formal ruling on > this, even I had to agree that the wording in the C standard leads to the > conclusion that a strictly conforming program cannot use #pragma. And that is as it should be. Consider for a moment if the ANSI committee had adopted something like Norman's interpretation: a program must behave the "same" way (whatever that is - leave it for the moment) with or without the #pragma. Where would that leave, just to take an example, "#pragma ALIGN <something>"? Often, such alignment pragmas are required to help programs read binary struct images from other machines. Programs which depend on such pragmas are, of course, totally non-conforming. But if you forbid a pragma from ever having a non-behavior-modifying effect, you cannot even implement such a pragma for non-conforming programs (because that would make the compiler non-conforming, even though it is hard to test for such a situation with any kind of a verification suite). If you choose some other method of specifying it (say, "#align <xx>"), that also must be diagnosed by a conforming compiler implementation. Result: you cannot implement such a mechanism in a conforming compiler *at all*. Thus the only reasonable approach is to say that a "#pragma" can change the behavior of a program in really unspecified ways (unless you want to get into the business of standardizing specific pragmas, like Ada does). ----- Shankar Unni E-Mail: Hewlett-Packard California Language Lab. Internet: shankar@hpda.hp.com Phone : (408) 447-5797 UUCP: ...!hplabs!hpda!shankar
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (11/21/90)
In <1990Nov16.171541.19468@zoo.toronto.edu> henry@zoo.toronto.edu
(Henry Spencer) writes:
(The standard attempt to infer them states that one must read the
standard as a whole, so 3.8.6 is subject to constraints imposed
elsewhere. The standard counterargument is that the rest of the
standard is subject to the constraint imposed in 3.8.6....
The real question, of course, is whether or not all Cretans are really
liars. Were there any Cretans among the ANSI C committee, and if so,
would any of them care to comment?
--
Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com>
UUCP: oliveb!cirrusl!dhesiscjones@thor.UUCP (Larry Jones) (11/27/90)
In article <2729@cirrusl.UUCP>, dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: > The real question, of course, is whether or not all Cretans are really > liars. Were there any Cretans among the ANSI C committee, and if so, > would any of them care to comment? Yes, the ANSI committee contained a number of Cretans -- I happen to be one myself. And I always lie. ---- Larry Jones UUCP: uunet!sdrc!thor!scjones SDRC scjones@thor.UUCP 2000 Eastman Dr. BIX: ltl Milford, OH 45150-2789 AT&T: (513) 576-2070 Wheeee. -- Calvin