e1?(void_e2):(void_e3) so, is it legal or what?

[Wayne Throop]

> jsdy at hadron.UUCP (Joseph S. D. Yao)
>> throopw at dg_rtp.UUCP (Wayne Throop)

>>K&R don't say anything, since no (void) back then.
>>Harbison and Steele say: [it's legal]
>>ANSI C draft standard, C.3.15. [says it's legal]

> *sigh*  OK, let's get this straight.  PROPOSED ANSI standard
> X3J11 describes a language [which has] not yet been implemented [...]

Agreed.  However, additions and differences from current C
implementations are intentionally minimized, as it is a standardization
effort.  (OK OK, const, signed, prototypes, screwing around with the
preprocessor, so they got carried away.  Doesn't change the fact that
they *intend* to standardize *existing* practice where possible.)

> H&S, while a very good book, does take some
> liberties at interpretation.  They are on the ANSI X3J11
> committee, and could have been influenced in their interpre-
> tations by the committees deliberations.

I doubt that, given the time of publication of the H&S book and so
on.  The reverse might be the case however, so this is a valid point.
(I take the point to be that H&S and the ANSI draft standard might
 actually be the "same source" on this point, so quoting both doesn't
 necessarily mean that there are two entities in agreement here.)

> Most compilers
> today follow K&R, which by declaring that the conditional
> expression has (1) a result (2) with a data type predicated
> on the types of the operands, seems to be prohibiting use
> of void-type objects.

This is the main point I disagree on.  Because the conditional
expression could (1) have a void result, and this would still count as
"having a result", and (2) its datatype would be predicated on the
types (but not the values) of the operands.  So, using the K&R
definition of (?:), and a resonable definition of what it means for an
expression to "have a result" given that some expressions are void, it
seems perfectly straightforward.

And it "ought to be" legal.  Really.  I just re-read the K&R exposition
of the (?:) operator, and (interpolating the existance of (void)) it
seems quite reasonable for it to allow it.  See what you think:

    The first expression is evaluated, and if it is non-zero, the result
    is the value of the second expression, otherwise that of the third
    expression. [details what happens for arithmetic and pointer
    expressions, omitted]  Only one of the second and third expressions
    is evaluated.

I think it is reasonable to say that (for the purposes of this K&R
verse) a value is whatever you get from evaluating an expression.
Remember, expressions *always* returned values in those days.  But
nowdays, sometimes that "value" is void.  Saying that "void expressions
have no value" is simply a rather naive (and, to my way of thinking,
inaccurate, but then) way of saying that they can't be used as an
argument to any operator that needs to interpret or transform it's
operands.  (,) and (?:) don't need to, so I see no reason to prohibit
void expressions on the right of these operators.

> Bottom line:  it's a mite early to be pointing to Proposed
> X3J11 and saying something is "right" or "not right" based
> on that.

Agreed.  My tongue was in my cheek in asserting that my invocation of
the draft standard legislated the debate out of existance, as might be
guessed by my calling it "Holy Writ".  Maybe I need to employ more
smileys?  Ah well, so it goes.

> As H&S points out, the C language is what the C compiler accepts.

I agree here also.  And the compiler I use (and presumably at least some
of the compilers that H&S had access to, given what they say on the
subject) accepts the construct without complaint.  So it is currently
legal, for some values of "the C compiler", right?   :-)

--
In programming, everything we do is a special case of something more
general -- and often we know it too quickly.
                                        --- Alan J. Perlis
-- 
Wayne Throop      <the-known-world>!mcnc!rti-sel!dg_rtp!throopw