Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site bbnccv.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!bbnccv!keesan From: keesan@bbnccv.UUCP (Morris M. Keesan) Newsgroups: net.lang.c Subject: Re: 2nd Annual Obfuscated Contest Winners Message-ID: <104@bbnccv.UUCP> Date: Mon, 1-Jul-85 14:56:51 EDT Article-I.D.: bbnccv.104 Posted: Mon Jul 1 14:56:51 1985 Date-Received: Wed, 3-Jul-85 07:51:35 EDT References: <2902@nsc.UUCP> <36@bbnccv.UUCP> <217@uthub.UUCP> Reply-To: keesan@bbnccv.UUCP (Morris M. Keesan) Organization: Bolt Beranek and Newman, Cambridge, MA Lines: 60 Keywords: operator_precendence Summary: Precedence means more than disambiguity In article <217@uthub.UUCP> thomson@uthub.UUCP (Brian Thomson) writes: >From Morris Keesan (keesan@bbnccv): . . >>A little examination reveals that the error reduces to >> >> expr ? expr , expr : expr >> >>which is illegal because the comma operator has lower precedence than the >>conditional operator. > >No, I think you're wrong. The relative precedence of operators exists only >to disambiguate possible parses. In the example you cite there is only >one valid parse, so precedence doesn't come into it. The "bug", if you >want to call it that, exists in your compiler rather than in PCC. ----------------------------------------------------------------------------- Well, if we were discussing this from the viewpoint of language philosophy and language design, I would probably agree with you that operator precedence SHOULD only exist to disambiguate possible parses. However, this is not the case in C. I quote from the C Reference Manual, section 7 (p. 185 of K&R) [ I am using the symbol '#' here as a replacement for the 'section' symbol, which is not in the ASCII character set]: The precedence of expression operators is the same as the order of the major subsections of this section, highest precedence first. Thus, for example, the expressions referred to as the operands of + (#7.4) are those expressions defined in ##7.1-7.3. The conditional operator (?:) is defined in section 7.13, and thus the expressions which may be its operands are those defined in subsections 7.1 through 7.12. By the above paragraph, the expressions defined in subsections 7.14 (assignment expressions) and 7.15 (comma expressions) are explicitly NOT allowed as operands of the conditional operator, and so the expressions a ? b , c : d a ? b = c : d a ? b : d = c although perfectly plausible and unambiguous, are not valid expressions in any formally-defined version of C (K&R, V7 UNIX, System V, 4.2BSD, Ultrix, and the various ANSI Draft Proposed Standards all agree on this in their documents defining C -- the ANSI draft is clearest). Just because there is only one possible or plausible parse that doesn't make it a valid parse. >PCC-based compilers use a more powerful technique [LALR(1)] for >expression parsing than does the Ritchie compiler [simple precedence, if >I remember rightly], and the simpler technique can't quite hack >the language. The simpler technique "hacks the language" exactly, and is probably the rationale for the language being defined the way it was. The "more powerful technique" being used by PCC is power misapplied, and is accepting expressions which are not allowed by the language definition (unless you define the language as "what the compiler accepts"). -- Morris M. Keesan keesan@bbn-unix.ARPA {decvax,ihnp4,etc.}!bbncca!keesan