Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!ptsfa!ihnp4!cuae2!ltuxa!ttrdc!levy From: levy@ttrdc.UUCP (Daniel R. Levy) Newsgroups: comp.lang.c Subject: Re: condition expressions Message-ID: <1700@ttrdc.UUCP> Date: Sun, 17-May-87 04:22:52 EDT Article-I.D.: ttrdc.1700 Posted: Sun May 17 04:22:52 1987 Date-Received: Sun, 17-May-87 19:43:28 EDT References: <1130@ius2.cs.cmu.edu> <148@nbisos.NBI.COM> <874@cc5.bbn.com.BBN.COM> <19047@sun.uucp> Organization: AT&T, Skokie, IL Lines: 56 In article <19047@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: < < Well, this quotation says that the "usual arithmetic conversions" are < < performed to bring the expressions to the same type, but it still doesn't < < say WHAT type prevails if the two differ; "usual arithmetic conversions" < < is begging the question! < < No. "Usual arithmetic conversions" is merely acting as shorthand for < section 3.2.1.5. Does section 3.2.1.5 or some other section actually come out and declare this "shorthand"? I'm sorry, but if not, my point stands valid with respect to the semantics of "English as she is spoken." < I guess this is < another place where the spec needs to be tightened up. The phrase in < 3.2.1.5: < < Many binary operators that expect operands of arithmetic < type cause conversions and yield result types in a similar < way. < < should, perhaps, be replaced by something like: < < Many non-unary operators that expect operands of arithmetic < type cause conversions and yield result types in a similar < way. Binary operators fall into this category. The < conditional operator also falls into this category with < respect to its second and third operands. Yes, this is better, but why not be clearer even to the compleat idiot, and just provide a list of the operators which treat their operands in this fashion, and indicate which of the operands are affected. < < < Why "double" in the example given: is it supposed to be because double < < is the type of the first subexpression, or is it supposed to be because < < double can accommodate a char but not vice versa, or what? < < The second of the two, obviously. This is the same reason why < "double" would be the type of "d + c", where "d" is "double" and "c" < is "char". N.B.: I know this. My question (and the next) was posed rhetorically, as if I were the Compleat Idiot reading the portion of The Spec which was quoted. < < This is a valid issue in the case where there is no lvalue involved: < < No, the presence or absence of an "lvalue" has nothing whatsoever to < do with this. (I know this too. See above.) -- |------------dan levy------------| Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, | an engihacker @ | vax135}!ttrdc!ttrda!levy | at&t computer systems division | Disclaimer: try datclaimer. |--------skokie, illinois--------|