This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Mon, 25 Aug 2003, Russ Allbery wrote:

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

(We all do :)

> > How's this:
> >
> >     [another draft rewrite of mine]
> >
> > Or something like that.
>
> Well, that's not technically accurate.  GCC doesn't cast them to void.

Did I say that? i don't remember saying that. *ahem*

    C contains many standard functions that return a value that most
    programs choose to ignore.  One obvious example is printf.  It is
    common to call those functions without using their return value.
    Warning about this practice only leads the defensive programmer to
    clutter programs with dozens of casts to void.  Such casts are
    required so frequently that they become visual noise in the source
    code, and writing those casts becomes so automatic that they no
    longer convey useful information about the intentions of the
    programmer.

Except, the first & third paragraphs seem to emphasize each other; unless
the point being made is wildly important and can't be repeated enough, the
third sentence appears to be redundant.

    C contains many standard functions that return a value that most
    programs choose to ignore.  One obvious example is printf.  Warning
    about this practice only leads the defensive programmer to clutter
    programs with dozens of casts to void.  Such casts are required so
    frequently that they become visual noise.  Writing those casts
    becomes so automatic that they no longer convey useful information
    about the intentions of the programmer.

I think this latter version is the clearest yet. Thoughts? This seems
close enough to the mark that I'll paste it into the file, and can revise
it further if anyone points out an error or misphrasing of mine.



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

portable, adj.
(Of a program) able to CRASH any OS on any PLATFORM. Compare MACHINE-
INDEPENDENT; VENDOR-INDEPENDENT. See also C; UNIX.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]