🚀 go-pugleaf

>	I've passively watched the discussion of lint's problems with
>  exit(0) from main(), and find myself wondering why it matters.  I use
>  lint to check my code, but I've gotten into the habit of automatically
>  ignoring certain output, including 'warning:  main() returns a random
>  value to the invocation environment.'

Sometimes messages like this may *not* be inconsequential; it's probably
better to tweak your code to eliminate as many such messages as
possible, rather than to ignore them.

>  Being primarily a psychometrician, and not a professional C (or
>  any other language) programmer, I find myself wondering if some
>  of you out there are working under conditions in which some higher
>  authority requires you to produce a clean lint run as evidence
>  of good coding.

At Sun, the kernel is expected to pass "lint"; the "-h", "-b", "-x", and
"-n" flags are used, and the only messages removed (with "grep -v") are

	struct/union <XXX> never defined

and

	possible pointer alignment problem

Many times I have been *V*E*R*Y* grateful that "lint" caught coding
errors in my, and other people's, code before I tested a kernel.

>  Otherwise, it would seem to me that any concern with the message
>  would be evidence of your being a slave to lint; why else be
>  concerned when you _know_ that the warning is inconsequential?

Because, as noted, the message may *not* be inconsequential; a program
that

	1) falls off the end of "main"

and

	2) is used in a context where exit statuses are checked

may screw up.  Consider some program used in a Makefile, for instance;
if it randomly returns a non-zero exit status, and you haven't told
"make" to keep going if that command fails, your Makefile will fail. 
Yes, this really happens.

Since it's quite easy to make the complaint go away (e.g. by sticking
/*NOTREACHED*/ after the call to "exit"), it's better to do so than to
filter the complaints out.