Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!nike!sri-spam!parcvax!hplabs!hp-sdd!ncr-sd!ncrcae!ncsu!mcnc!rti-sel!dg_rtp!throopw From: throopw@dg_rtp.UUCP (Wayne Throop) Newsgroups: net.lang.c Subject: Re: e1?(void_e2):(void_e3) so, is it legal or what? Message-ID: <517@dg_rtp.UUCP> Date: Thu, 14-Aug-86 18:50:11 EDT Article-I.D.: dg_rtp.517 Posted: Thu Aug 14 18:50:11 1986 Date-Received: Sun, 17-Aug-86 05:25:00 EDT References: <273@watmath.UUCP> <5858@alice.uUCp> <134@sas.UUCP> <155@cbnap.UUCP> <499@dg_rtp.UUCP> <518@hadron.UUCP> Lines: 83 Summary: Well, Joe's right (sort of), but let me say this about that... > jsdy@hadron.UUCP (Joseph S. D. Yao) >> throopw@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 !mcnc!rti-sel!dg_rtp!throopw