Why does S5 lint dislike all casts to long?

[Geoff Kuenning]

If you lint the following program with the "-p" switch on System V (at least
UniSoft System V), you get "warning: conversion to long may sign-extend
incorrectly":

	main ()
		{
		int b = 0;
		long l;
		l = b;
		}

I have not found a way to suppress this message, short of putting the whole
statement inside "#ifndef lint", which I find somewhat excessive.

I have two questions:  first, what is the meaning of this message?  Are there
some machines out there that can't simply sign-extend a lousy int to a lousy
long?  If so, are they conforming to the C standard?

My second question is, how do people feel about the necessity of being able
to suppress individual lint messages?  When I am working on a large program,
I find that it is literally impossible to suppress all lint's messages.  This
is especially true with System V lint, because it ignores the VARARGS
declarations in llib-lport and complains about e_v_e_r_y_ printf in the whole
program.  If you specify -p and not -u, it also helpfully informs you of
literally e_v_e_r_y_ routine that was mentioned in the lint library that you forgot
to call.  (After all, if you haven't used 100% of the library in you program
you must have blown it, right?)

But even when lint is operating correctly, legal and portable C code will
produce large numbers of lint errors.  I appreciate them, and don't mind
checking them out once.  But after I have looked at a line of code and
decided that I know more about a situation than lint does (e.g., I know that
my assignment to long will sign-extend correctly because the number is always
positive), I would really like the ability to tell lint to shut up about that
line.  Preferably without cluttering the code up a bunch by making implied
type casts explicit or some such noise.  And certainly without cluttering it
up with "#ifdef lint" all over the place.

What do people think?  I find that I only use lint at major stopping points,
to make sure the code I think is ready really is.  The problem is that I have
to wade through so many meaningless messages that it takes an hour or so,
and I'm not willing to do that for every compile.
-- 

	Geoff Kuenning
	First Systems Corporation
	...!ihnp4!trwrb!desint!geoff