Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!gatech!hao!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.UUCP
Newsgroups: comp.lang.c
Subject: Re: condition expressions
Message-ID: <19047@sun.uucp>
Date: Sat, 16-May-87 14:33:38 EDT
Article-I.D.: sun.19047
Posted: Sat May 16 14:33:38 1987
Date-Received: Sat, 16-May-87 21:47:09 EDT
References: <1130@ius2.cs.cmu.edu> <148@nbisos.NBI.COM> <874@cc5.bbn.com.BBN.COM> <1694@ttrdc.UUCP>
Sender: news@sun.uucp
Lines: 43

> 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.

> (Otherwise, why not quote some other part of the spec that says what
> "usual arithmetic conversions" are with respect to members of tertiary
> expressions...

Because, I presume, they felt that it was obvious that the only
rational way to treat the second and third operands of ":" was to
treat them the same way you treated the two operands of "+".  The
situation is certainly similar in the two cases.  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.

> 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".

> 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.