jwf@vaxine.UUCP (Jim Franklin) (07/11/84)
Is lint supposed to understand lexical scope? I have two files "foo.c"
and "foo.h", where "foo.h" declares local variables for "foo.c":
----- file foo.h: ----------------------------------------------
static int abc;
----- file foo.c: ----------------------------------------------
#include "foo.h"
main ()
{
printf ("%d\n", abc);
}
----------------------------------------------------------------
If I run lint (BSD 4.2) on foo.c I get what I consider to be bogus
error messages:
> lint foo.c
foo.c:
abc defined( ./foo.h(1) ), but never used
abc used( foo.c(5) ), but not defined
If I make variable "abc" be external by removing the keyword static
then lint is happy. Is this a bug or a feature? I know that I can use
the -u switch to make this message go away, but why should I have to?gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (07/15/84)
This is a bug in 4.2BSD "lint". The UNIX System V "lint" is happy with your example (except for function returns value which is always ignored printf ).
art@ACC.ARPA (04/19/86)
> There is really no justification for not using lint.
Just remember that not all machines that have a C compiler also have lint.
A full lint (or equivalent) implementation in the public domain would
be very welcome.
------gwyn@brl-smoke.UUCP (04/19/86)
In article <119@brl-smoke.ARPA> art@ACC.ARPA writes: > >> There is really no justification for not using lint. > >Just remember that not all machines that have a C compiler also have lint. >A full lint (or equivalent) implementation in the public domain would >be very welcome. Perhaps he should have said "There is really no justification for doing C software development on a system other than UNIX"?
rbj@icst-cmr (root) (04/22/86)
Doug Gwyn writes: In article <119@brl-smoke.ARPA> art@ACC.ARPA writes: > >> There is really no justification for not using lint. > >Just remember that not all machines that have a C compiler also have lint. >A full lint (or equivalent) implementation in the public domain would >be very welcome. Perhaps he should have said "There is really no justification for doing C software development on a system other than UNIX"? Come on Doug, you don't *really* believe this, do you? (Root Boy) Jim Cottrell <rbj@cmr> "One man gathers what another man spills"
gwyn@BRL.ARPA (VLD/VMB) (04/23/86)
>> Perhaps he should have said "There is really no justification >> for doing C software development on a system other than UNIX"? > Come on Doug, you don't *really* believe this, do you? Sure I do. Just because you build Chevrolets for a living doesn't mean you can't drive to work in a Mercedes.
brooks@lll-crg.ARpA (Eugene D. Brooks III) (04/23/86)
> Perhaps he should have said "There is really no justification > for doing C software development on a system other than UNIX"? > >Come on Doug, you don't *really* believe this, do you? > > (Root Boy) Jim Cottrell <rbj@cmr> > "One man gathers what another man spills" I can't speak for Doug, but Not for money, love, drugs or sex would I do software development on a system other than UNIX. The rest of you guys can suffer if you want to but I have seen enough pain in my lifetime.
mwm@ucbopal.berkeley.edu (Mike (I'll be mellow when I'm dead) Meyer) (04/23/86)
In article <121@brl-smoke.ARPA> gwyn@brl.ARPA writes: >Perhaps he should have said "There is really no justification >for doing C software development on a system other than UNIX"? Except that Unix compilers (4BSD, anyway) don't have ANSI function prototyping, get confused when I want to twiddle menus and/or windows, and requires that I run a seperate program (with the obscure name of "lint") to catch type clashes, unitialized variables and other such errors. We won't even mention the cost of a Unix system versus the cost of a PC. <mike
oyster@uwmacc.UUCP (Vicarious Oyster) (04/23/86)
In article <1391@lll-crg.ARpA> brooks@lll-crg.UUCP (Eugene D Brooks III) writes: >> Perhaps he should have said "There is really no justification >> for doing C software development on a system other than UNIX"? [Doug Gwyn] >> >>Come on Doug, you don't *really* believe this, do you? >> >> (Root Boy) Jim Cottrell <rbj@cmr> >> "One man gathers what another man spills" > >I can't speak for Doug, but >Not for money, love, drugs or sex would I do software development >on a system other than UNIX. Yes, but do you believe others also have to abide by your preference? Probably not, eh? Gwyn's non-smileyed message may not have implied that, but that kind of attitude *is* noticable among certain groups of people... like neo-nazis, pseudo-fundamentalist Christians, etc. Intolerance knows no bounds. - Joel "The only good fanatic is a dead fanatic" P. {allegra,ihnp4,seismo}!uwvax!uwmacc!oyster
greg@utcsri.UUCP (Gregory Smith) (04/29/86)
Somebody was complaining that they couldn't get /* VARARGS */ to work in
lint. Well I ran into the same problem, and guess what, VARARGS does not do
what it says:
----------- part of man lint: ------------------
/*VARARGSn*/
suppresses the usual checking for variable numbers of
arguments in the following function declaration. The
data types of the first n arguments are checked; a
missing n is taken to be 0.
----------- part of /usr/lib/lint/llib-lc: --------
/* VARARGS */
printf( s ) char *s; {;}
------------- dammit.c --------------
main(){
int i;
i=0;
printf(i);
}
------------- lint dammit.c:---------
dammit.c:
printf, arg. 1 used inconsistently llib-lc(276) :: dammit.c(4)
---------------------------------------
/* VARARGS */ and /*VARARGS0*/ both cause the first arg to be type-checked.
Another 'bug' is that /* VARARGS */ is used for all varargs functions in
llib-lc, where VARARGS1 should be used for printf, VARARGS2 for sprintf and
fprintf, etc. grumble, grumble.
Neither problem is mentioned in the BUGS section of man LINT.
This is 4.2 BSD.
--
"For every action there is an equal and opposite malfunction"
----------------------------------------------------------------------
Greg Smith University of Toronto UUCP: ..utzoo!utcsri!gregrbutterworth@watmath.UUCP (Ray Butterworth) (04/30/86)
> /* VARARGS */ and /*VARARGS0*/ both cause the first arg to be type-checked. > Another 'bug' is that /* VARARGS */ is used for all varargs functions in > llib-lc, where VARARGS1 should be used for printf, VARARGS2 for sprintf and > fprintf, etc. grumble, grumble. /*VARARGS*/ causes all the parameters in the function definition to be type-checked. This is nearly always what you want. The dummy definition for printf and fprintf in the lintlibrary file is something like: /*VARARGS*/ printf(fmt) char*fmt; {return 0;} /*VARARGS*/ fprintf(stream,fmt) FILE*stream; char*fmt; {return 0;} This causes LINT to compare the types of ALL the parameters with the supplied arguments. i.e. printf's first argument must be char*, and it can take any type of arguments after that. That /*VARARGS0*/ is treated the same as /*VARARGS*/ is in fact a bug in LINT (if there is a number, it is stored as its negative value in the 4.2 implementation, so -0 looks just like 0 which means that there wasn't any number given). One would almost never define a function with three parameters and tell lint to check only the type of the first one or two. There seems to be little point to ever doing such a thing. Unfortunately that is what LINT takes the # in /*VARARGS#*/ to mean. A much more useful meaning to the # would be to define the minimum number of arguments that the caller must supply. e.g. /*VARARGS1*/ func(n,a,b,c){return 0;} would check the types of all four parameters (if arguments were passed for them) and would complain if there wasn't at least one argument in the call. But as I said, this is NOT what LINT does. In fact one can call fprintf() with no arguments and get not a peep from LINT, regardless of whether fprintf() is defined with /*VARARGS*/ or /*VARARGS2*/ Anyway, I believe that under X3J11's version, there won't be any need for such a lint directive.
woody@juliet.caltech.edu (William E. Woody) (05/01/86)
> > You people fail to realize that some of us out here don't like lint. > It complains too much about what I do.... > > (Root Boy) Jim Cottrell <rbj@cmr> Here here! Though (whenever possible) I try to run my code through lint, I think I only use about a fifth of what lint complains (screams, shouts, moans, groans) about. And running my code through lint is not a happy little chore that I do just before running my code and going to sleep at night; it's a horrible little task (akin to turning homework into the mean little ol' silver haired english teacher, knowing she's going to slash my entire paper apart). But that fifth of information lint does cough up is extremely nice; sometimes when you're tired and have about three million four byte structures bouncing about in your code and it's four in the morning and the program must be finished at nine; your girlfriend left you for your roommate and no companies on the west coast is willing to offer you a summer job between school years, it sure is nice to know that you accidently put an extra '*' before one of your pointers (a silly typo, I know) which will blow up and burn away the mainframe your working on. (And when your roommate is the sysman, WATCH OUT!) By the way, does anyone know if a public domain LINT exists? Or an inexpensive one for my little Macintosh here? Unprotected memory sure is a pain to find when you mess up the pointers. - William Woody NET Woody%Romeo@Hamlet.Caltech.Edu USNAIL 1-54 Lloyd, Caltech / Pasadena, CA 91126 - William Woody NET Woody%Romeo@Hamlet.Caltech.Edu USNAIL 1-54 Lloyd, Caltech / Pasadena, CA 91126
jsdy@hadron.UUCP (Joseph S. D. Yao) (05/03/86)
In article <121@brl-smoke.ARPA> gwyn@brl.ARPA writes: >In article <119@brl-smoke.ARPA> art@ACC.ARPA writes: >> [attribution omitted] >>> There is really no justification for not using lint. >>Just remember that not all machines that have a C compiler also have lint. >>A full lint (or equivalent) implementation in the public domain would >>be very welcome. >Perhaps he should have said "There is really no justification >for doing C software development on a system other than UNIX"? For those poor sufferers who have to develop under other systems, there are many implementations of lint and make under MS-DOS: some were listed here a short time ago. I believe DEC has them under its VNX tools for VMS, too -- although if you are an all-DEC shop ... get Ultrix instead! Much better. "Better? Stronger ... faster ..." cheaper ... ($6M??) -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
rbutterworth@watmath.UUCP (Ray Butterworth) (05/06/86)
> From rbj@icst-cmr (Root Boy Jim) Fri May 2 17:28:02 1986 > Yes, but it all depends on what you're willing to put up with. I find it > terribly ugly having to cast printf's or close's to void. Not only is it ugly, it's wrong. Didn't you read in the man page where it says that these functions return ERROR STATUSES? Do you believe that nothing will ever go wrong? What if programs such as cat(1) didn't check these error statuses, think what a mess the world would be in. I mean if one ran cat from a tape and an I/O error occured, it would probably just treat it as end-of-file and not tell you that the rest of the file couldn't be read, and if your file-quota was exhaused cat wouldn't notice that it couldn't flush its buffers properly and there you would be with an empty file and cat telling you that everything ran fine. > From: woody@juliet.caltech.edu (William E. Woody) > Here here! Though (whenever possible) I try to run my code through lint, > I think I only use about a fifth of what lint complains (screams, shouts, > moans, groans) about. I too used to think that most of what lint complained about was crap. I also noticed an awful lot of things that it didn't complain about but should have. So I took the source and turned on all the options that normally make it shut up about certain things, and then added even more checks than lint ever had before. Then I looked at all the crap in the output and gradually taught lint which one's really were crap and shouldn't be issued. Now I have a version of lint with which I use four fifths of what it complains about. For instance, int i; long l; short s; char *a,*b; i=l; s=i; /* these both generate warnings */ i=(int)l; s=(short)i; /* NO warnings */ l=i<<100; /* warning */ open("file",0); /* warning */ (void)open("file",0); /* (optional) warning */ strcpy(a,b); /* NO warning */ If you assign something that is larger to something that is smaller lint warns you, but if you explicitly cast it to indicate that you know it isn't a mistake you get no warning. There is also an /*OPTRESULT*/ directive which is used like the /*VARARGS*/ directive in the function definition. strcpy() is so defined, and so lint doesn't care whether you look at its result or not. But open() is not defined with this directive, so lint does expect you to look at its return value. With things set up this way, it is almost always an error to cast any function to (void), so lint warns about this too (only as an optional summary, once per function, not per call). Too many times I've seen people try to make code lint cleanly by simply casting all the ignored function returns to (void) and by using lots of options to tell lint not to complain about certain things. Lint really can be useful. I don't know why the people who support it don't try to improve it.
jrv@MITRE-BEDFORD.ARPA (James R. Van Zandt) (05/09/86)
>> I'm aware of four lint-type programs for checking C code on an MS-DOS machine: >> >> PC-LINT Tecware $ 99 >> PC-Lint Gimpel Software $139 >> Pre-C Phoenix Computer Products Corp. $395 >> Lint Wizard Systems Software, Inc. $450 (bundled with compiler) >> >> Can anyone report experience with these or others, or point to >> published reviews? All the responses but one were requests for information. Here's the one: > We are using the Wizard C compiler and BSD 4.3 to develop a large > (~150,000 lines) system that will run under UNIX and MS-DOS. The Wizard > compiler reports intra-module errors and warnings. The lint option > will create a lint library and do inter-module checking. Overall the > Wizard system catches the same errors that the BSD lint catches and > often reports more warnings. The whole package is well worth the price > (especially since you get library sources and can get an update service > from Wizard). > > -- > Brad Davis {ihnp4, decvax, seismo}!utah-cs!b-davis > b-davis@utah-cs.ARPA Now I'm trying to decide whether (1) nobody else has buggy C code, (2) nobody else wants to ADMIT to having buggy C code, or (3) lint is hazardous, and few users survive :-). - Jim Van Zandt
faustus@cad.UUCP (Wayne A. Christopher) (05/13/86)
In article <2452@watmath.UUCP>, rbutterworth@watmath.UUCP (Ray Butterworth) writes: > I too used to think that most of what lint complained about was crap. > I also noticed an awful lot of things that it didn't complain about but > should have. So I took the source and turned on all the options that > normally make it shut up about certain things, and then added even more > checks than lint ever had before. Then I looked at all the crap in the > output and gradually taught lint which one's really were crap and > shouldn't be issued. Now I have a version of lint with which I use > four fifths of what it complains about. Sounds great. Can we have it? (Post diffs to net.sources, maybe?) Wayne
leei@mcgill-vision.UUCP (Lee Iverson) (08/29/86)
In article <1391@lll-crg.ARpA> brooks@lll-crg.UUCP (Eugene D. Brooks III) writes: >Not for money, love, drugs or sex would I do software development >on a system other than UNIX. The rest of you guys can suffer if >you want to but I have seen enough pain in my lifetime. This is obviously a man who has either not heard of Lisp Machines, has never used one, or has no faith in the future. "After you had a man wi' no legs, they ain't no goin' back, baby!" -- Lee Iverson utcsri!mcgill-vision!leei Mcgill University, Montreal Computer Vision and Robotics Lab
thomas@utah-gr.UUCP (Spencer W. Thomas) (10/01/86)
I once looked at the innards of our (4.2) lint, and concluded that it
does type matching on structure data types by comparing
1. Length of the data item
2. A hash of the data item's type name.
Thus, we have:
================ x.c ================
struct s
{
char i[4];
};
struct s
func()
{
struct a;
a.i[0] = 'a';
return a;
}
================ y.c ================
struct s
{
long a;
};
main()
{
struct s b, func();
b = func();
return 0;
}
Running 'lint x.c y.c' gives (!)
x.c:
y.c:
--
=Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA)