"lint" lets very bad code pass

[Guy Harris]

> > 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:
> > 	Guy Harris
> 
> A test like this should be under control of the -p or -c option of lint.
> Does it still allow int-long equality if you use the -p option?

1) "-c option"?  That option tells "lint" to compile a "lint" library.  Why
should that have anything to do with this?

2) It doesn't allow int-long equality with "-p"; unfortunately, "-p"
disallows a number of other things, and uses a different "lint" library.
"-p" means "check whether this will port to UNIX *or* GCOS *or* OS/360 C".
There needs to be a "check whether this will port to UNIX C with a
7-character identifier limit" and "check whether this will port to UNIX C
assuming no identifier length limit".  (There also needs to be a "check
whether this will port to ANSI C" once ANSI C becomes an official standard.)
I want to check whether code will port to any other UNIX implementation;
right now, I can't have that without the 6-character identifier limit and a
check against a different C library.

	Guy Harris