Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!linus!decvax!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.bugs.usg
Subject: "lint" lets very bad code pass
Message-ID: <2454@sun.uucp>
Date: Sat, 20-Jul-85 20:06:12 EDT
Article-I.D.: sun.2454
Posted: Sat Jul 20 20:06:12 1985
Date-Received: Sun, 21-Jul-85 23:11:13 EDT
Distribution: net
Organization: Sun Microsystems, Inc.
Lines: 56

The V7 "lint" (or, at least, the version of it that comes with 4.2BSD),
gives error messages for code that passes an "int" value to a routine that
expects a "long" or pointer value, even though such code is likely to work
on 4.2BSD systems which will have 32-bit "int"s.

However, the System V Release 2 "lint" had code added to it *specifically*
to prevent it from complaining about this on machines with sizeof(int) ==
sizeof(long) if the actual argument is a constant.  This is a bad idea for
several reasons:

	1) it means that you can't check for this kind of code - which
	   *will* fail on machines with 16-bit "ints" and 32-bit pointers,
	   and in the case of "int" actual parameters and "long" formal
	   parameters, will even fail if "int"s and pointers are the same
	   size - unless you run "lint" on the target machine

which further implies that

	2) if you're doing cross-development on a machine on which
	   sizeof(int) == sizeof(long) for a machine on which sizeof(int)
	   != sizeof(long), you have *no way* to "lint" your code unless
	   you either can run "lint" on the target machine (which may be
	   a small one-board dedicated system with *no* operating system)
	   or you keep a machine with sizeof(int) != sizeof(long) solely
	   for the purposes of doing cross-development.

I can sympathize - *very* slightly - with the people who get pages of
complaints from "lint" about

	mumble(NULL);	/* should be (struct frobozz *)NULL */

*ONLY* if this code wil *NEVER EVER* run on a machine other than the one
they're doing development on.  Some people may not run "lint" because it
insists they think more abstractly when coding than they'd like to, so
eliminating these diagnostics may induce them to run "lint".  However, the
correct solution to this problem is to get the ANSI C standard out the door
and get *everybody* to start declaring the return type and argument type to
*all* functions they use - you only have to declare it once and the compiler
will cast all 0s passed as arguments to the proper pointer type and all
"int" values (constant *or* variable) to "long" when necessary.  The correct
solution for the interim is to have managers require that their people
"lint" their code whether they want to or not.

For those of you who realize why the code that earlier "lint"s complained
about is bad, you can make the System V "lint" complain too by deleting the
two lines that read

		if( sizeof(int) == sizeof(long) && !pflag ) return( 0 );

from the routine "chktype" in "lpass2.c".  This line was *not* present in
earlier "lint"s, and is the culprit.  (One should *NOT* have to specify the
"-p" flag - which checks for portability to various non-UNIX implementations
of C - in order to get it to check for a bug which impairs portability to
perfectly good UNIX C implementations.)

	Guy Harris