benson@phantom.ksr.com (Benson Margulies) (02/24/88)
Here are two bugs and a perhaps bug in 4.3 lint, both demonstrated by
the following trivial source file:
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.
Bug (2): why two copies of the error message?
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.
Benson I. Margulies Kendall Square Research Corp.
harvard!ksr!benson ksr!benson@harvard.harvard.edugwyn@brl-smoke.ARPA (Doug Gwyn ) (02/26/88)
In article <238@ksr.UUCP> benson@ksr.UUCP (Benson Margulies) writes: >Bug? (3): to me, it seems wrong that lint reports duplicate definitions >against the library. This is an important feature of lint. How do you know that some function you invoke in the C library won't end up calling your bcopy() instead of the one it was expecting?
ford@kenobi.UUCP (Mike Ditto) (02/28/88)
Posting-Front-End: GNU Emacs 18.41.10 of Fri Oct 2 1987 on kenobi (usg-unix-v) In article <238@ksr.UUCP> benson@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@crash.CTS.COM to see what they did, and scale it ...!sdcsvax!crash!kenobi!ford down and run his life that way." -- Laurie Anderson