lijewski@batcomputer.tn.cornell.edu (Mike Lijewski) (01/04/90)
Consider the following code:
main()
{
int a = 0, b = 1, c = 2;
c ? c = a : c = b;
exit(0);
}
According to the precedence rules of C, the conditional expression
should be evaluated as:
(c ? c = a : c) = b;
which should produce and error. Well, it happens that I have a
compiler which accepts this and produces results which suggest
to me that it is evaluating this expression as:
c ? c = a :(c = b);
The vendor seems unwilling to accept this as a bug. Am I just being
pedantic, or is this a serious bug? I haven't been able to come up
with an example of correct usage of the ternary operator, which
produces incorrect code. If anyone knows of some code which might
clearly prove that this is a bug, I would sure appreciate receiving it.
Thanks.
--
Mike Lijewski (H)607/277-7623 (W)607/255-0539 (desk)607/255-2960
Cornell National Supercomputer Facility
ARPA: mjlx@cornellf.tn.cornell.edu BITNET: mjlx@cornellf.bitnet
SMAIL: 1122 Ellis Hollow Rd. Ithaca, NY 14850dkim@wam.umd.edu (Daeshik Kim) (01/04/90)
In article <9493@batcomputer.tn.cornell.edu> lijewski@batcomputer.tn.cornell.edu (Mike Lijewski) writes: > > c ? c = a : c = b; The only way I can guess is follows: 1. having top-down parsing (LL) predictive grammar def. for fast parsing --> ERROR (c)[expr] (?) (c = a)[expr] (:) (c) ... ^^^ HERE, left-to-right scan may predict the last token 'c' an expression 2. having slow bottom-up (LR) right-most grammar --> off course, accept this -- Daeshik Kim H: (301) 445-0475/2147 O: (703) 689-7308 (M,W,F) SCHOOL: dkim@cscwam.umd.edu (uunet!haven!cscwam.umd.edu!dkim) dskim@eng.umd.edu (uunet!haven!eng.umd.edu!dskim) WORK: dkim@daffy.uu.net (uunet!daffy!dkim)
steve@groucho.ucar.edu (Steve Emmerson) (01/04/90)
[This is the third time, that I'm aware of, that this topic has come up.] In the referenced article, lijewski@batcomputer.tn.cornell.edu (Mike Lijewski) questions whether or not the following statement is legal since it seems to violate C's rules of precedence: c ? c = a : c = b; It is my understanding that precedence rules are for disambiguating ambigous sentences, i.e. for chosing one particular way of *generating* a sentence from amongst alternatives. Some sentences in classic C (i.e. K&R-1) can be generated in more than one way; consequently, classic C requires precedence rules in order to parse them. In pANS C, however, no precedence rules are required as each sentence can be generated in only one way (at least for the grammar listed in K&R-2). There is only one way to generate the suspect statement above in classic C; hence, no precedence rules are needed. The sequence is expr ; expr ? expr : expr ; c ? lval = expr : lval = expr ; c ? c = a : c = b ; In pANS C, the suspect statement *cannot be generated* (due to the grammar -- not precedence rules). In summary, precedence rules are a tool of the parser and are needed by it only to choose between alternative *generation* sequences. If there's only one sequence, they don't apply. Steve Emmerson steve@unidata.ucar.edu ...!ncar!unidata!steve
walter@hpclwjm.HP.COM (Walter Murray) (01/05/90)
Mike Lijewski writes: > Consider the following code: > main() > { > int a = 0, b = 1, c = 2; > c ? c = a : c = b; > exit(0); > } > According to the precedence rules of C, the conditional expression > should be evaluated as: > (c ? c = a : c) = b; > which should produce and error. Well, it happens that I have a > compiler which accepts this and produces results which suggest > to me that it is evaluating this expression as: > c ? c = a :(c = b); > The vendor seems unwilling to accept this as a bug. If your vendor claims conformance to the forthcoming ANSI standard, the answer is easy: the program is illegal. An ANSI-conforming compiler will produce a diagnostic. If it chooses to make the diagnostic a warning, it is free to proceed and generate whatever code it pleases. The only requirement is that a diagnostic be produced. If ANSI conformance is not claimed, the answer is a little harder. Does the vendor provide a programmer's reference manual that describes what the behavior should be? > Am I just being pedantic, or is this a serious bug? You gave the compiler an expression that you admit is illegal. The compiler interpreted the expression in a way that would make sense to a lot of programmers. I wouldn't call that a serious bug. Some people would call it a feature. It all boils down to a question of whether the expression is bad enough to evoke a diagnostic from the compiler, and that's a matter of opinion. (ANSI says Yes.) Does your compiler have an option to make it more verbose about questionable constructs? Try lint; it will probably catch the error. > I haven't been able to come up with an example of correct usage > of the ternary operator, which produces incorrect code. Keep trying. > If anyone knows of some code which might clearly prove that > this is a bug, I would sure appreciate receiving it. For what it's worth, Harbison & Steele (C: A Reference Manual) clearly state that the expression is illegal (2nd ed., p. 182). Walter Murray ----------