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

[Chris Devers <cdevers at pobox dot com>]

On Mon, 25 Aug 2003, Russ Allbery wrote:

> Chris Devers <cdevers@pobox.com> writes:
>
> > In section 10.11, "Certain Changes We Don't Want to Make" we have the
> > following paragraph:
>
> >   * Warning when a non-void function value is ignored.
>
> >     Coming as I do from a Lisp background, I balk at the idea that
> >     there is something dangerous about discarding a value. There
> >     are functions that return values which some callers may find
> >     useful; it makes no sense to clutter the program with a cast
> >     to void whenever the value isn't useful.
>
> > There's just a bit more axe-grinding from the MIT alum that wrote this
> > than is strictly necessary, I think :)
>
> How about this, which I think gets at the heart of the matter more
> directly:
>

>     C contains many standard functions that return a value that is
>     occasionally useful but usually ignored by most programs.  (printf
>     is an obvious example.)  It is commonplace to call those functions
>     without using their return value.  Warning about this practice only
>     leads to cluttering the program with dozens of casts to void.  Such
>     casts are required so frequently that they become visual noise, and
>     writing those casts becomes so automatic that they no longer convey
>     useful information about the intentions of the programmer.

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.)

 * Important and common cases first, exceptions second.

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

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.


I'm a little confused -- doesn't GCC end up producing warnings as output
when a program is being compiled, rather than injecting them somehow into
the compiled code itself? Are you saying that the typical programmer ends
up putting in superfluous code just to silence the warnings?

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?

If the latter is closer, and the "fix" is to get GCC to be silent about
this class of warning [?-- I'm looking at a different part of the text at
the moment] then GCC's behavior needs to be more prominent, and less
emphasis needs to be placed on coding techniques.

I think. Does that make sense to you, Russ?


-- 
Chris Devers      cdevers@pobox.com
http://devers.homeip.net:8080/blog/

Nintendinitis, n.
Any disease blamed on excessive exposure to electronic games. See also
VIDEO GAME.

    -- from _The Computer Contradictionary_, Stan Kelly-Bootle, 1995