dapermezel@watmath.UUCP (Damon Permezel) (10/08/83)
the construct (coid) f() is not meaningless at all. I didn't say it was meaningless. I said it was as devoid of meaning as (void) ++i. .... The complex statement given in the initial flame means something entirely different - that being the call of a (void)-declared function f() that was not declared locally. Au contrair. It does not say that 'f' was declared to be type void elsewhere. It casts 'f' to be a pointer to a function that returns nothing. 'f' could indeed return char *. I have never seen any rules for type cast with void types. I suspect that the present behaviour just 'came out in the wash' with many compilers. Sure, they allow (void) f(); but they also allow (void) ++i; and (void) 1; /* PCC does, at least */ This is not very useful. =damon
mjs@rabbit.UUCP (10/09/83)
Yes, but the construct
(void) expression;
makes for regularity in a language that I all too often see folks flame
about missing regularity. As they (whoever THEY are) say, `You can't
have your cake & eat it, too.' Which slice of cake would you rather
have?
--
Marty Shannon
UUCP: {alice,rabbit,research}!mjs
Phone: 201-582-3199kendall@wjh12.UUCP (Sam Kendall) (10/09/83)
Damon, what is your objection to void casts? If your objection is that
int f();
...
(void) f();
is redundant, since the void cast specifies something ("throw away
the result") which would be apparent anyway, you are right, in that
void casts are no help to compilers. They are useful for lint. A
void cast says to lint, "I'm not using the value of this expression,
and I'm well aware of it, so shut up."
As for `(void) ++i', there is nothing wrong with it, but lint chooses
not to complain about throwing away the value of an assignment operator
(including ++ and --) anyway, so the void cast serves no purpose.
There are rules about void specified in later versions of the C Reference
Manual; unfortunately Prentice-Hall still publishes the original. (I
think there are some bad decisions in those rules, but that is another
story.)
Sam Kendall {allegra,ihnp4}!wjh12!kendall
Delft Consulting Corp. decvax!genrad!wjh12!kendallguy@rlgvax.UUCP (Guy Harris) (10/11/83)
oid) 1
but why should the compiler bother to detect a cast of a constant to a void
and allow other expressions? One might as well be general, as there is no
penalty...
2)
(void) ++i;
*CAN* be useful. Assume there is a macro like "putc" which is intended to
look like a subroutine with side-effects and which also returns a value.
Say you want to invoke the macro for its side effects and ignore its value.
You can do that just by invoking it and not assigning the result to anything
but "lint" will yell at you. The only way to shut it up is to cast its
result to void. (This is not a hypothetical example; I have seen reasonable
code which has run across this problem.)
What harm does this facility do? I can't speak for Algol 68, which does
have some sort of notion of void types, but it is very useful in C to throw
away the result of a procedure called only for its side-effects.
*I* suspect these rules were invented for just these purposes (there is
explicit code in PCC/lint which understands casts to voids, so the ability
to cast an expression to void did not "just 'come out in the wash'" there).
Guy Harris
{seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guyok@edai.UUCP (Richard O'Keefe) (10/17/83)
As far as I know, the point of writing #define Ignore (void) Ignore sprintf(....); is to stop lint squawking about a function returning a value which is sometimes ignored. By the way, I've run into a problem with 'void'. The Berkeley compiler seems to get confused with compound types based on void. typedef void (*fnptr)(); doesn't always work properly, mainly in initialisations.