[ On Thursday, September 20, 2001 at 09:36:13 (-0700), James Graham wrote: ]
> Subject: Re: ignoring return values from functions.
>
> What in the world...?  Lint, in all the years I've used it, has
> been its own separate program!

I'm almost certain it hasn't, though of course I don't know for certain
which version(s) you've used.

Why write and maintain two parsers for the same language?

To quote Ian Darwin from his O'Rielly book on 'lint'.  Note particularly
the last sentence:

    Two programs from AT&T Bell Laboratories Computer Science Research
    have been useful allies to thos trying to write portable code:
    'pcc' and 'lint'.  'pcc' is the protable C compiler; it was written
    for the early porting efforts, started the trend of adding
    portability checking into the compier, and has decendants in the
    majority of UNIX systems in the field today [[ 'rcc', the SysV
    compiler, was a direct decendant of 'pcc'.  But of course that was
    written as early as 1988. -GAW ]]  'pcc' and 'lint' are like twins,
    concieved in the same mind and born of the same source code.

Here is the content from the file READ_ME in the directory
/usr/src/cmd/lint from V7 and 32V:

	Most of lint's source files are shared with the portable
	compiler: they are found in /usr/src/cmd/mip.
	The files here are only those which are unique to lint.

The makefile in the same directory cements this relationship.

(the machine dependent files for the pdp-11 are in /usr/src/cmd/pcc, of
course)

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

Well, actually, when it comes to programming the "not less" part is
critical.  The common stuff often left out is, of course, the error
checking....  which is what this whole thread is really all about.

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

You'd be surprised at the types of people who are asked to maintain
other people's code, and the levels of their experience.  But that's
besides the point.

There's a lot more to code maintenance than being able to read the
language it's written in.  Just as with human languages, there are
idioms and other constructs whose intent will not be clear to a casual
reader.  Even metaphor can creep into computer code....

However also as in human languages idioms and other similar kinds of
constructs in programming languages can be used to carry even deeper
meaning to the experienced reader, i.e. the reader who has come to
understand them.

You can write very functional C code without learning the common idioms
that the experienced C programming community have come to use.  However
you'll have a harder time gaining a deep understanding of code that uses
these idioms if you don't understand them.  More importantly though
you'll also have a harder time gaining a deep understanding of the code
if it was written without use of common idioms, whether you know them or
not.  These common idioms are used because they carry a deeper meaning
to the reader, even though they are mostly irrelevant to the compiler.

Indeed even the overall "style" of the code, and especially the
consistency of that style throughout a larger body of code, is also
critical (as has been shown by many studies) to its readability and thus
its maintainability, regardless of how "expert" the reader is.

And therein lies a central issue of code maintenance.  In order to write
maintainable code it is important to use the common idioms of the target
language (and of course to use them correctly), and to follow a
consistent style (and of course one that's hopefully identical to a
widely published sytle guide such as the Indian Hill guide, or nearly so).

Computer programs are written in high level languages (i.e. as opposed
to assembler or binary machine code) so that they can be read by humans,
not just so they can be compiled and run.

Note too that much of the work done on NetBSD, and indeed on any program
or system, is maintenance.  The initial design and authorship of a
program often accounts for ony a miniscule amount of the time spent
working on it over its useful lifetime.

> I will agree with everything except the (void) thing.  I think
> it's just silly.

You're fighting against the advice of many a software engineer besides
just myself.....  That alone should cause you to question your thinking.

>  Has the compiler explicitly been redesigned to
> handle (void) casts differently than if there is no cast at all?

No, of course not.  (though NetBSD's 'lint' seems to have been)

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

I think you're missing the point.  This is *ALL* about error handling.

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

No, your words actually contradict Henry's advice.  Your advice is
actually bad advice, especially for a C systems programmer.  Only when
interpreted as sarcasm do your words have any benefit.

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

No, Henry's advice is to "always check the return code" (if available),
and to *always* do something about it, regardless.

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