[ On Thursday, September 20, 2001 at 01:10:22 (-0700), James Graham wrote: ]
> Subject: Re: ignoring return values from functions.
>
> BSD used to have a fairly decent "lint" program; if it's not the same
> now as it used to be, what happened?

Traditionally "lint" is mostly just a back-end to the compiler, not a
separate program (and thus it dealt explicitly with the language of the
compiler and was not intended to find syntactic lint, but rather
semantic lint).  I.e. the it went back to Bell Labs because it was part
of their proprietary codebase from Research Unix.

What we have now on NetBSD at least is a new program that includes its
own parser.  The advantage here is that it *might* be able to find some
more syntactic lint.  However since it almost certainly parses a
slightly different language than the compiler, it might not catch even
some true syntactic errors (though these would properly be bugs in it).

> # > 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 would actually agree with this:  Use what you need, and no more.

and not less either....

> # I'm saying that explict delcaration of the programmer's intent is much
> # better, even if it means using more words and syntactic glue.
> 
> If the words and glue don't *need* to be there, they shouldn't be there.

The explict casts to 'void' do _need_ to be there in order to convey the
programmer's intent.  Re-read commandment #3 _again_.  Many of us have
hard earned experience that results with the very same advice.  I've got
a stack of papers analysing programming errors and program faults and
they all say the same thing too.  You can obviously ignore this advice
if you wish, but at least those of us who have learned these lessons the
hard way will feel very uncomfortable when we go to work on your code
and we will probably take longer to understand it deeply enough to
discern your real intent from your expression of it.

> If you can't read C code, you probably shouldn't be modifying it.

That's a pointless distracting comment that avoids the very real issues
in software maintenance and engineering.

> # 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.
> 
> "Unwarranted chumminess with the compiler will invariably produce
> undefined results when least expected."

I think either you're confusing some fundamental issues here, or echoing
the very same sentiment.  Henry is warning you to be very careful to
make sure the compiler delivers the data type you want -- i.e. telling
you *NOT* to be too chummy with your compiler, or your header files, or
your libc.  Indeed the above commandment is intended to warn people to
make casts such as "foo = (char *) malloc(bar);" as well as to cast
functions to 'void' when you really do want to explicitly ignore their
value.

> # 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.
> 
> "Never check for an error condition you are not prepared to handle."

Hah.  Yeah, that kind of attitude and a quarter will get you a phone
call -- hope you've got someone to dial when your program blows chunks! ;-)

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