Some bugs in lint

[Mike Ditto]

Posting-Front-End: GNU Emacs 18.41.10 of Fri Oct  2 1987 on kenobi (usg-unix-v)


In article <238 at ksr.UUCP> benson at phantom.ksr.com (Benson Margulies) writes:

> t.c:
>
> bcopy(b1, b2)
> register char	*b1, *b2;
> {
> *(((long *)b2)++) = *((long *)b1)++;
> }
>
>
> lint t.c 
>
> gives:
>
> t.c:
> t.c(4): illegal lhs of assignment operator
> t.c(4): illegal lhs of assignment operator
> bcopy: variable # of args.      t.c(3)  ::  llib-lc(189)
> bcopy multiply declared t.c(3)  ::  llib-lc(189)
> bcopy defined( t.c(3) ), but never used
>
> Bug (1): that lhs is quite valid.

No, it's not.  the first lhs in question is "((long *)b2)" (it is the
"left- hand-side" of the ++ operator.)  Since the result of the cast
operator is (technically) not an lvalue, it is (technically) illegal
to apply the ++ operator to it.  I have never seen a compiler that
didn't support this type of construct, but it is not strictly correct.


> Bug (2): why two copies of the error message?

The second message applies to the second illegal lhs, "((long *)b1)".


> Bug? (3): to me, it seems wrong that lint reports duplicate definitions
> against the library. At very least, there should be a /* SOMETHING */
> to suppress this.

Redefining library functions is dangerous, and should generate a message.
Maybe a /* SOMETHING */ would be good, although it is probably best to
make the function static so there is no danger of library routines calling
the non-standard (user-supplied) version of the function.  For example,
in the "t.c" example above, if strcpy() used bcopy() internally (it
doesn't, of course) it would no longer work because strings are not
always aligned on long integer boundaries.

					-=] Ford [=-

"Well, he didn't know what to do, so	(In Real Life:  Mike Ditto)
he decided to look at the government,	ford%kenobi at crash.CTS.COM
to see what they did, and scale it	...!sdcsvax!crash!kenobi!ford
down and run his life that way." -- Laurie Anderson