Re: [using gcc book] ch10.11 Certain Changes We Don't Want to Make

[Russ Allbery <rra at stanford dot edu>]

Chris Devers <cdevers@pobox.com> writes:

> I'll use that as the template, with a couple of revisions.

>  * (The book makes entirely too much use of (parens) (*&%*^%% lisp
>    hackers), so any parens should come out.)

I write too many parenthetical comments.  :)

>  * Sentences should tend towards brevity, and no comma splices or run-ons.

Er, I plead innocent to these charges.  There wasn't a comma splice or
run-on in my proposed text.  *grin*.  I don't have a strong opinion on the
wording, though, so please do feel free to massage however you want.

> Think Hemingway, not Faulkner.

> How's this:

>     Many of C's standard functions return a value that is ignored by
>     most programs, but is occasionally useful. One obvious example is
>     printf.  It is common to call these functions without using their
>     return value.  GCC ends up casting these unused values to void,
>     producing copious warnings as it does so.  Such casts become
>     visual noise, smothering the programmer's intent.

> Or something like that.

Well, that's not technically accurate.  GCC doesn't cast them to void.

Let me give you some more background on this that might help in crafting
the text.  This section is talking about a feature that was common in
various versions of lint, where all function return values either had to
be used by the program or had to be cast to void.  In other words, the
code:

    printf ("Hello world!\n");

would have to be written:

    (void) printf ("Hello world!\n");

or lint would warn.  Since the purpose of the -W GCC options is largely to
reproduce much of the functionality of lint, various people have asked for
this warning as well.

The point of the paragraph is that the errors found by these warnings
aren't useful enough to warrant all the (void) casts that you have to add
to the average program.  I've maintained code that's lint-clean under a
lint that warns about this, and the code gets incredibly cluttered with
them.

Zach has a valid point, though, in that adding this as a non-standard
warning just for people who want to use it isn't out of the realm of
possibility.  You may want to drop this paragraph entirely.  If you keep
it, though, the clutter is the reason why it was rejected as a feature.

> I guess what confuses me is the "Warning about... leads to" clause: does
> the generation of the warnings lead to the compiler producing too much
> noise (in which case this phrasing seems to muddle cause & effect), or
> does the production of the warnings lead the programmer to defensively
> find ways to write code that doesn't cause the compiler to be as noisy?

The latter.

Hopefully the above helps explain.  GCC does not issue these warnings, and
the paragraph was intended to explain why GCC would not introduce that
feature.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>