C Compiler bug (and fix for a different one)

Guy Harris guy at sun.uucp
Fri Aug 22 04:54:38 AEST 1986

> 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 "?"/":"

> 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 <boolean_expression>, the value yielded by
the expression will be the same, since <void_value_1> == <void_value_2> ==
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 at sun.com (or guy at sun.arpa)

More information about the Comp.lang.c mailing list