[ On Thursday, September 20, 2001 at 11:42:40 (-0400), Andrew Brown wrote: ]
> Subject: Re: ignoring return values from functions.
>
> i've never used lint before now, although i'm willing to give it a go,
> and i've just tried it on a small program.  complaints like this:
> 
>     sleep used( ioctl.c(98) ), but not defined
>     wait used( ioctl.c(68) ), but not defined
>     tcsetattr used( ioctl.c(138) ), but not defined
>     err used( ioctl.c(69) ), but not defined
>     tcgetattr used( ioctl.c(85) ), but not defined

For these particular errors you'll almost certainly get similar warnings
from GCC with:

    -Werror -Wall -Wshadow -Wswitch -Wreturn-type -Wpointer-arith -Wconversion -Wimplicit -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes

If your code can pass through GCC with the above options enabled then
it'll generally pass through 'lint' cleanly too (though not always --
lint does catch things GCC doesn't or cannot).

> i can do without.

your decision, obviously -- but don't ever ask me to work on your code
until after you de-lint it!  ;-)

Before 'void' the "Indian Hill C Style An Coding Standards a ammended
for U of T Zoology" (that's the Bell Labs guide, as ammended by Henry
Spencer) states:

    It is difficult to eliminate complaints about functions whose return
    value is not used (in the current version of C, at least), but most
    other messages from 'lint' really do indicate something wrong.

however in the modern land of 'void' (i.e. ANSI/ISO C), even that first
excuse is gone.  All messages from 'lint' really do indicate something
is wrong, even if only conceptually and not in practice.

>  the fact that lint complains than then exits with 0
> also seems a little suspect to me.

Why?  There's no fault in its finding nits in your code.  It would
hopefully exit non-zero if it couldn't read the source file or some such
real error.

You'd be surprised what bugs you might find, or even unintentionally
fix, unrelated to the lint warnings, in a de-linting excercise.

> >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.
> 
> this is one of those things that was written as humor.

you wish....  I know Henry personally (and in fact knew him before that
was written).  I know for certain that it was written entirely for VERY
serious purposes and only after he and his colleagues learned all the
lessons therein the hard way.  I too learned all the same lessons, the
same hard way, at somewhat the same time too.  That there is humour in
the way it is written is only to get people who would otherwise ignore
it to read it and hopefully learn something from it regardless.  You may
ignore it at your peril, or you may use it to learn those lessons the
"easy" way.

> having to say ARGSUSED for a function like:
> 
>     static void
>     sigchld(int nsig)
>     {
>         if (wait(NULL) == -1)
>             err(1, "wait");
>     }
> 
> strikes me as practically useless.  having to say NOTREACHED after
> exit() also seems silly.

obviously you've yet to learn some of the lessons of how to write robust
code that can be more easily maintained by someone else.

>  if lint was worth anything, if would be able
> to tell that program flow stopped at that point and that the code
> after it would not be reached.

I'm sure the those maintaining the version of lint we have now would
more than welcome your insight into how this could be done.  Until such
time that it's possible though I suggest we all just use /* NOTREACHED */

>  putting in a comment to that effect
> only disables the warning.

Yes, but that comment is like "code" to lint -- it declares the
programmer's intent.  It's most certainly not an ordinary "comment".

(Unfortunately it wasn't done as a pre-processor tag....  "#lint FOO")

> the use of (void) adds visual clutter.

Actually, no, it doesn't -- at least not to those who've learned its
meaning and understand its importance.

Maybe you'll learn to read carefully crafted code, maybe not....  I grew
up reading code that is pedantically careful and I never had any trouble
understanding it, and today I find it takes a lot more time to learn the
programmer's intent when I go to modify code that doesn't pedantically
cast away error return 

People who don't like casts to 'void' generally grew up reading C in the
times before 'void', or learned from those who did.  Some of us though
have made the transition and are ever the happier for it.

>  visual clutter detracts from
> future maintainability.

In general yes, but there are many many ways to deal with the visual
aspects of necessary syntactic and semantic elements of ones code....

>  it's more stuff someone has to wade through
> to find the actual code.

In this case, no, it's not.  It is the actual code and it declares the
programmer's intent very clearly without leaving any impression that
there's something lost or omitted.

> >I'm saying that explict delcaration of the programmer's intent is much
> >better, even if it means using more words and syntactic glue.
> 
> then use blocks of comments.  don't clutter up the code.

Blocks of comments do not declare one's intent as clearly, succinctly,
and immutably as real code does.  I.e. there is no win there!  Did you
not read what I wrote, or did I not write it clearly enough?

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