[ On Wednesday, September 19, 2001 at 23:24:16 (-0400), Andrew Brown wrote: ]
> Subject: Re: ignoring return values from functions.
>
> lint and the c compiler sometimes disagree.  some things, like the use
> of NOTREACHED to aid lint in determining that a block of code is
> ending seem bogus.  the c compiler knows, and the use of __dead can be
> good thing.

traditionally I've ignored the C compiler and only paid attention to
lint because it was the only one which could be given hints like this in
the past.

not to preach to the converted or anything, but perhaps this is an
appropriate time to repeat some sage advice:

           The Ten Commandments for C Programmers

                       Henry Spencer

1    Thou shalt run lint frequently and study its pronounce-
     ments with care, for verily its perception  and  judge-
     ment oft exceed thine.


Of course with GCC/EGCS/whatever there is no real "lint" program, which
is the root of the disagreements between the compiler and NetBSD's lint
(what NetBSD has as "lint" is in many ways a poor hack, not a real
"lint"; though in other ways it can be better since it has a different
outlook on things...).  "gcc -Wall -WBLAH" for any number of BLAHs is
not really a replacement for lint, even when you have full prototypes.

Also, for portable code I still find the lint-style hint comments to be
infinitely more useful than any GCC-specific syntax (and even where ISO
C approves, such stuff is still not portable and I won't use it).  GCC
would do well to heed the lint-style hint comments if it's going to make
lint-like complaints.

(On a slightly related topic, I am very glad devel/lcc has been finally
added to pkgsrc, if only for i386 -- it may prove interesting to try to
compile NetBSD with it, though since I didn't have the time to port it
myself, I'm unlikely to find the time to use it significantly!)

> > It is ALWAYS best to explicitly cast function return values to (void) if
> > they are expliicltly to be ignored.  We're not talking about the basic
> > correctness of the code here, but rather the readability and future
> > maintainability of the code.
> 
> i really don't think it helps the readability of the code.  then
> again, if i wish to, i can make things much unreadable anyway by using
> !! and -~ or ~-.

It obviously depends on what you mean by "readability", and note more
specifically that I also included "future maintainability" in there too!

You seem to be implying that fewer words and syntactic glue is better.

I'm saying that explict delcaration of the programmer's intent is much
better, even if it means using more words and syntactic glue.

You could declare your intent in a comment, but obviously there's no
"win" there.

Again, the relevant quotes from Henry's advice column:

3    Thou shalt cast all function arguments to the  expected
     type  if  they  are not of that type already, even when
     thou art convinced that this is unnecessary, lest  they
     take  cruel  vengeance upon thee when thou least expect
     it.

6    If a function be advertised to return an error code  in
     the  event  of  difficulties, thou shalt check for that
     code, yea, even though the checks triple  the  size  of
     thy  code  and produce aches in thy typing fingers, for
     if thou thinkest ``it cannot happen to me'',  the  gods
     shall surely punish thee for thy arrogance.


Oh, and just as a reminder w.r.t. the use of K&R or K&P as a style
guide, from more or less the horse's mouth:

                     Notes on Programming in C

                              Rob Pike

    Introduction

         Kernighan  and  Plauger's  The  Elements of Programming
    Style was an important and rightly  influential  book.   But
    sometimes  I feel its concise rules were taken as a cookbook
    approach to good style instead of the succinct expression of
    a philosophy they were meant to be.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>