Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!pyramid!decwrl!sun!guy From: guy@sun.uucp (Guy Harris) Newsgroups: net.lang.c,net.bugs Subject: Re: C Compiler bug (and fix for a different one) Message-ID: <6416@sun.uucp> Date: Thu, 21-Aug-86 14:54:38 EDT Article-I.D.: sun.6416 Posted: Thu Aug 21 14:54:38 1986 Date-Received: Thu, 21-Aug-86 22:24:33 EDT References: <273@watmath.UUCP> <5858@alice.uUCp> <134@sas.UUCP> <187@cblpe.UUCP> Organization: Sun Microsystems, Inc. Lines: 51 Xref: mnetor net.lang.c:5708 net.bugs:330 > No, the value of the statement is being thrown away, not the value > of the void(s). True, but one can imagine the ":" half-operator selecting between one of the two "void" values. One then throws away the value returned by the "?"/":" operator. > > Would you let me say: > . > . > . > f1() + f2(); > . > . > > Since I am throwing both away? No, you're not. You're adding them and then throwing the *sum* away. "void" "value"s can't be added. If you consider "void" to be a sort-of type, the set of whose values is a singleton set, then you can consider boolean_expression ? void_value_1 : void_value_2 to select one of the two "void" values and yield it as a result, so the ":" half-operator, unlike the "+" operator, can act on two "void" values. (Regardless of the value of the , the value yielded by the expression will be the same, since == == any other void value you can think of.) Think of it this way: "void" values require 0 bits to represent them, since the set of all such values has only one element. As such, "sizeof(void)" should be 0. As such, if you say void x; "x" takes up no memory. Given that, declaring objects of type "void" isn't very useful. An attempt to do so is probably an error, so it is rejected. Also, if objects of type "void" were implemented, most implementations would run the risk of giving it the same address as the next datum declared. So taking the address of a "void" is kind of useless, and so "void *" isn't useful as a true "pointer to void", so it can be overloaded. Also, since all "void" values are the same, an attempt to compare them is probably an error, so "==", etc. aren't defined over the set of "void" values either. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)