On Thu, 20 Sep 2001, Greg A. Woods wrote:

# > 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 in the world...?  Lint, in all the years I've used it, has
been its own separate program!  If you wanted to compile something,
you ran it through the compiler!  If you wanted to do really stringent
syntax/semantic lint (depending on the options), you ran it through
lint!  I have never known lint to be a "back-end" to the compiler.

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

It's not possible to use less than what you need; need, by definition,
implies a minimum standard.

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

No, they don't.  It's patently absurd to go through and cast, e.g.,  every
call to printf, fprintf, write & co. to (void).  I would go so far to
say that it qualifies as pedantry.

# Re-read commandment #3 _again_.

Casting stuff to (int), (double), (char *), even (void *) makes perfect
sense.  For the compiler to bitch mightily about "ignored return values"
is pedantic.  It's also a pain in the ass, but I repeat myself.

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

What, you're thinking that

	printf("yadda yadda yadda\n");

carries less intent than

	(void) printf("yadda yadda yadda\n");
?

That's totally absurd.

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

What, you're going to send in people that can't read code to maintain it?
I think it's less than pointless.

# > "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.

I'm echoing the same sentiment more succinctly.

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

I will agree with everything except the (void) thing.  I think
it's just silly.  Has the compiler explicitly been redesigned to
handle (void) casts differently than if there is no cast at all?

What's going to happen, is the compiler going to decide that an unused
variable is a prime candidate for a return value?  That's a bit wonky,
don't you think?

# > # 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, what are you on?  I was restating it more succinctly!  That is
exactly what #6 is saying!  It's also one of the axioms of coding.

i.e. if you're going to check the error return code, for heaven's sake,
DO something with it.

				--*greywolf;
--
NetBSD: We Stay Up.