[net.lang.c] Why does S5 lint dislike all casts to long?

geoff@desint.UUCP (Geoff Kuenning) (11/18/84)

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

"Gary@internet.UUCP (AMXBR-VLD-V)" <moss@Brl-Vld.ARPA> (11/20/84)

How about declaring ints that are always positive as unsigned...

main()
	{
	unsigned	b = 0;
	long		l;

	l = b;
	}

Agreed, sometimes lint is dead wrong.  Sometimes I just comment the code
with something to the effect that lint will give the following bogus
message here.
__Moss__

gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (11/20/84)

I think Geoff's "lint" has several more bugs than the current version.
The ONLY spurious "lint" messages I get are due to its lack of
understanding of semantics:

	-  exit( retval );	does not return;
		/*NOTREACHED*/	helps but the main() routine is still
				expected to return an int value even
				though all termination is via exit().

	-  the (char *) returned by malloc() is guaranteed to be
		properly aligned so that coercion to any other pointer
		type will work properly.  Since "lint" doesn't know
		about this property, it warns about incompatible
		pointer types when it sees the coercion.  A similar
		problem occurs when casting back to a (char *) for
		free().

I maintain thousands of lines of source code that pass through "lint"
(SVR2) with absolutely no warning or error messages other than those
noted above.  I find "lint" to be very valuable in reducing bugs and
detecting module design flaws (unused parameters, etc.).

I note that much of the AT&T UNIX user-mode source code has had bugs
that have shown up under "lint".