Thus spake Ask Dr. Stupid
> D'Arcy J.M. Cain sez:
> /*
>  * Oh, just to add more fuel to the fire, I also have a problem with the
>  * use of (void) in front of every function call that discards it's return
>  * value.  Does anyone have a good arguemnt for keeping this?  It really
>  * bloats code for no reason IMO.
>  */
> 
> It's perfectly conforming to ANSI to cast something to (void) when ignoring

No one has suggested otherwise.

> a return value; in fact, gcc seems to demand it, and lint will certainly
> complain about it!

Gcc certainly does not demand it.  Lint is the tool that complains about
this.  There isn't even an option in gcc to force a warning.

Also, I know perfectly well that the reason for casting to void is to shut
lint up.  I just happen to feel that that is just begging the question.
The question is, why do we need to add something to the code to keep
another tool from complaining about the fact that we haven't added it
to the code.  I know that there is some marginal utility but mostly
the (void) is just peppered throughout code as required by the lint run.
To me the marginal utility is outweighed by the the marginal disutility
of having to scan into a line to find the action rather than seeing it
as the first item on the line.  Yes, it is personal opinion but so what?
It's all personal opinion.  That doesn't mean we can't discuss it.

> There are times when I want to use the return value from close(),
> and there are times when I don't.  It would be an inconsistency to
> re-declare close to be void close(), and it generates warnings to
> use
> 	close(fd);

It only generates warnings in lint, not the tool that actually compiles
the code.  There may be an option in some compilers to enable such a
warning but gcc doesn't have one.

> without assigning it to something.  Now, tell me, what's more code bloat?
> 
> 	A.	(void) close (fd);
> 
> 	B.	int rv;
> 		.
> 		.
> 		.
> 		rv = close(fd);
Or C.
     close(fd);

> I'd say B., personally; I don't think there's a rhyme or reason to
> force an allocation of a variable to hold a return value from a function
> whose return value I want to ignore anyway.  What's the point?  The

None that I can see and no one has suggested one.

> __P()/__STDC__ isn't going to go away, either, for two very big reasons:

Two issues here.  Of course __STDC__ isn't going away.  As for __P, unproto
is just as easy when necessary and makes the code cleaner.

> 2.  _NOT_ _EVERYBODY_ _HAS_ (_ACCESS_ _TO_) _AN_ _ANSI_ _C_ _COMPILER_!

No need to shout.  Everyone understands this and many people have dealt
with the issue.  Remember, the discussion is not about C code in general,
just the NetBSD system code.  Just because people haven't dealt with the
issue to your satisfaction, doesn't mean they haven't dealt with it.

> This has been listed by quite a few folks.  What is so unclear about this
> statement that the ANSI-only extremists (pardon the term; I don't know
> how else to put it) do _not_ understand?

The statement that not everyone has an ANSI compiler is perfectly understood
by everyone on both sides of the discussion as far as I can see.  And if
you are searching for an alternate term, I suggest "ANSI proponents"
unless your goal is to argue by emotionally charging your terms.

> This has gone beyond religious into overstepping the bounds of
> practicality.  You don't seriously expect every bit of useful code
> to be ANSIfied overnight, now, do you?

No I do not.  Have I suggested this?  Has anyone?  I have seen exactly
the opposite stand; just change files slowly.  Both styles can coexist
under C89 in the same source tree.

-- 
D'Arcy J.M. Cain                           |  Democracy is three wolves
darcy@{druid.net|vex.net}                  |  and a sheep voting on         
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.
                --  http://www.druid.net/darcy  --