throopw@dg_rtp.UUCP (Wayne Throop) (08/06/86)
> From: aka@cbrma.UUCP (Andy Kashyap) > A function call is an expression and can, therefore, be used anywhere an > expression can be used. When you declare a function (void), you state that > you intend to use that function as a statement instead, that you do not > intend to use it in any operations. It can now only be used where a statement > can. Keep in mind that an expression is a statement, but NOT vice-versa. Not quite the case at all. When you declare a function void, you are saying that its evaluation yields a void expression. You are *NOT* saying that it is a statement. Again, let us consult Holy Writ on the subject. First, K&R have nothing to say about this, since void didn't exist then. Harbison and Steele say (on page 150): The type of the function expression must be "function returning T" for some type T, in which case the result of the function call is of type T. The result is not an lvalue. If T is void, however, then the function call produces no result and may not be used in a context that requires the call to yield a result. That is, function invocations are *ALWAYS* expressions. Sometimes, these expressions are void, that is, they have no value. Clear enough. Now let's see what the ANSI C draft standard has to say (in 2.2.2): The (nonexistent) value of a *void* *expression* (an expression that has type void) shall not be used in any way, and explicit or implicit conversions shall not be applied to such an expression. (and in 3) An *expression* is a sequence of operators and operands that specifies how to compute a value, or (in the case of a void expression) how to generate side effects. Again, fairly clear. Void "thingies" (how's that for a technical term, eh?) are expressions, and *NOT* statements. (That is, not statements except in the sense that all expressions are statements in C, right?) The only surprising thing here is that not all expressions return values when they are evaluated. But this "surprise" in implicit in the meaning of "voidness". (As a small nit, I'd druther that the draft standard would allow a void expression to be cast to void, but that's a fairly small quibble.) -- There are some forms of insanity which, driven to an ultimate expression, can become the new models of sanity. --- Bureau of Sabotage {Frank Herbert} -- Wayne Throop <the-known-world>!mcnc!rti-sel!dg_rtp!throopw
jack@mcvax.uucp (Jack Jansen) (08/11/86)
Something that has been bothering me since I read the C standard (well, read.... paged through it), and came up again after this discussion is the following: why haven't the C standardisers treated void like in algol-68? There, void is a fullfledged type, having only one value, also called void. This has a number of advantages: it makes the standard simpler, it makes compilers simpler (no more special-casing of void in variable definitions), and it would probably make life easier for programs that produce C as output. Are there any good reasons for not making void a normal type? -- Jack Jansen, jack@mcvax.UUCP The shell is my oyster.
gwyn@BRL.ARPA (VLD/VMB) (08/12/86)
I have often thought (void) should be a real type. I even think sizeof(void) should be 0, and ((void)[])s shouldn't take up much space, etc. I too wonder why (void) is a second-class citizen.
c8-rah@zircon.berkeley.edu (CS 8 Readers) (08/13/86)
I think that I agree that void should be a real data type, but
making sizeof(void) would create problems. Since sizeof(void) = 0,
sizeof(void[size) = 0 regardless of size. Since one could declare an
arbitrarily long array of void, sizeof(void *) would have to be infinite,
which does not seem possible. My proposed solution, which may not be any
good either, is making void a real type, and sizeof(void) equal to the
sizeof a union of char,int,etc. i.e. sizeof(double).
If anyone has a better idea, or a good reason not to make void a real data
type, I would be interested in hearing it.
-Max Schiresonthroopw@dg_rtp.UUCP (Wayne Throop) (08/15/86)
> jack@mcvax.uucp (Jack Jansen) > Something that has been bothering me since I read the C standard (well, > read.... paged through it), and came up again after this discussion > is the following: why haven't the C standardisers treated void like > in algol-68? There, void is a fullfledged type, having only one > value, also called void. I'm not so sure they didn't, in effect and intent, if not in so many words. The real differences from what you describe seem to be only two. C's void type has no legal values at all, rather than just one. And no objects may be of type void (though expressions can be). > Are there any good reasons for not making void a normal type? Well, in putting it the way they do, X3J11 avoid the problem of what happens if you try to take the address of a void object. Even in Algol, this is probably anomalous, since a void object (only one legal value) can be stored in zero bits, so where you allocate it is sort of, well, arbitrary, isn't it? -- The importance of information is directly proportional to its improbability. -- Wayne Throop <the-known-world>!mcnc!rti-sel!dg_rtp!throopw