cspw.quagga@p0.f4.n494.z5.fidonet.org (cspw quagga) (05/26/90)
I'm after some advice on lint: I don't use it, and want to know whether I should. 1. Is it ANSI C compatible? (Or are there many dialects of lint? Would a Xenix lint be the same as most others?) 2. I program C the 'new' way - full prototypes, casts, standard ANSI. I enable all compiler warnings and port the sources to a couple of system, including VAX C, Turbo C, Helios (transputer) C and TopSpeed C. Is lint likely to discover anything new or give useful advice after this gauntlet? Are there still things that lint can discover (by looking at all modules simultaneously) that a C compiler cannot discover when modules are compiled independantly? 3. Was the intention that ANSI C with prototypes/casts etc. would remove the need for external checkers like lint? Can we expect to see the demise of lint in the next few years? Thanks Pete Wentworth -- uucp: uunet!m2xenix!puddle!5!494!4.0!cspw.quagga Internet: cspw.quagga@p0.f4.n494.z5.fidonet.org
diamond@tkou02.enet.dec.com (diamond@tkovoa) (05/30/90)
In article <6328.265D8157@puddle.fidonet.org> cspw.quagga@p0.f4.n494.z5.fidonet.org (cspw quagga) writes: >I'm after some advice on lint: I don't use it, and want to know whether >I should. You should. The question, as you point out below, is whether you CAN. >1. Is it ANSI C compatible? Either no or mostly no. There might be one that I haven't heard of. >(Or are there many dialects of lint? Yes. Maybe half as many as there are C compilers. (It should be equally many rather than half of many, but some vendors are irresponsible.) > Would a Xenix lint be the same as most others?) How many others constitute "most"? If you mean others that are all the same among these others' selves, there is no "most". > Is lint likely to discover anything new or give useful advice after this > gauntlet? Yes. It is also likely to give useless advice and false error messages (if you use things like prototypes). If you choose to program in a subset of ANSI C, one that is a subset of the intersection of ANSI C and many old C's, then the amount of useless advice can be minimized, and you can pay attention to the useful advice. >Are there still things that lint can discover (by looking at all > modules simultaneously) that a C compiler cannot discover when modules are > compiled independantly? Yes, dozens. >3. Was the intention that ANSI C with prototypes/casts etc. would remove the > need for external checkers like lint? If prototypes and header files are used properly, then they can duplicate a little bit of lint's work. The answer to this half-question might be 5% yes and 95% no. How do casts add any error checking? In fact, they usually defeat error checking. And what did ANSI do to casts? The answer to this half-question might be -50% yes and +150% no. >Can we expect to see the demise of lint in the next few years? Well, error checking is pretty widely unpopular, so the answer might be yes. But neither expectation (demise vs. revival) affects the work that most of us do, so it might not be necessary to try to predict this. -- Norman Diamond, Nihon DEC diamond@tkou02.enet.dec.com Proposed group comp.networks.load-reduction: send your "yes" vote to /dev/null.
cml@tove.cs.umd.edu (Christopher Lott) (05/31/90)
A few thoughts about lint, prompted by this posting: In article <00937758.16FBE220@rigel.efd.lth.se> e89hse@rigel.efd.lth.se writes: > I don't see what lint discovers that a C-compiler with prototypes can't >discover, except wrong external declarations like: hello[100], char *hello. The use of function prototypes is very helpful, but interface errors are not the only class of errors out there! Lint will bring many common constructs to your attention. An example is doing a test on a constant expression, like "if (i = 1)" where the programmer perhaps meant "if (i == 1)" Another example is of functions returning values which are ignored. This warning causes much irritation for functions like "exit()" but can point the way to a fault in the code. Lint can also help detect nonportable constructs, but I can't think of a good example just now. Someone please correct me if some compilers flag these sorts of faults. gcc, for one, does not flag test-of-constant conditions, not even when told "-Wall -ansi -pedantic" For PC users, Gimpel Software sells PC-Lint, and it is an excellent product. It understands ANSI-style function prototypes. I convinced my old boss to buy it, and the package was very helpful. chris... -- Christopher Lott Dept of Comp Sci, Univ of Maryland, College Park, MD 20742 cml@cs.umd.edu 4122 AV Williams Bldg 301-454-8711 <standard disclaimers>
henry@utzoo.uucp (Henry Spencer) (05/31/90)
In article <6328.265D8157@puddle.fidonet.org> cspw.quagga@p0.f4.n494.z5.fidonet.org (cspw quagga) writes: >I'm after some advice on lint... >1. Is it ANSI C compatible? ... Ask your supplier. The original lint dates back well before ANSI C, so it wasn't, but your supplier may have added improvements. Given the incompetence of most Unix suppliers, the answer is probably "no". >2. I program C the 'new' way - full prototypes, casts, standard ANSI... > Is lint likely to discover anything new or give useful advice... Yes, quite possibly. It checks many things that typical compilers don't. >3. Was the intention that ANSI C with prototypes/casts etc. would remove the > need for external checkers like lint? Can we expect to see the demise of > lint in the next few years? Disciplined use of prototypes largely supersedes lint's cross-file checking, and a *really* fussy compiler can do most of the within-file checking that lint does. Very few compilers are that fussy, however. Lint is likely to remain valuable, assuming that suppliers can be convinced to update it to match their compilers. If they don't bother, then lint will indeed fall out of use. -- As a user I'll take speed over| Henry Spencer at U of Toronto Zoology features any day. -A.Tanenbaum| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
e89hse@rigel.efd.lth.se (05/31/90)
In article <1754@tkou02.enet.dec.com>, diamond@tkou02.enet.dec.com (diamond@tkovoa) writes: >In article <6328.265D8157@puddle.fidonet.org> cspw.quagga@p0.f4.n494.z5.fidonet.org (cspw quagga) writes: > >>I'm after some advice on lint: I don't use it, and want to know whether >>I should. > >You should. The question, as you point out below, is whether you CAN. At least if you don't have prototypes... >>3. Was the intention that ANSI C with prototypes/casts etc. would remove the >> need for external checkers like lint? > >If prototypes and header files are used properly, then they can duplicate >a little bit of lint's work. The answer to this half-question might be >5% yes and 95% no. How do casts add any error checking? In fact, they >usually defeat error checking. I don't see what lint discovers that a C-compiler with prototypes can't discover, except wrong external declarations like: hello[100], char *hello. Henrik Sandell
als@bohra.cpg.oz (Anthony Shipman) (05/31/90)
In article <00937758.16FBE220@rigel.efd.lth.se>, e89hse@rigel.efd.lth.se writes: > I don't see what lint discovers that a C-compiler with prototypes can't > discover, except wrong external declarations like: hello[100], char *hello. Lint does more than just type checking. It checks for possible logic errors too. A frequent life saver is the way it warns me when it finds: if (x = 1) { ... } Other checks include unreachable code etc which may indicate coding errors. -- Anthony Shipman ACSnet: als@bohra.cpg.oz.au Computer Power Group 9th Flr, 616 St. Kilda Rd., St. Kilda, Melbourne, Australia D
scs@adam.mit.edu (Steve Summit) (05/31/90)
In article <00937758.16FBE220@rigel.efd.lth.se> e89hse@rigel.efd.lth.se writes: > I don't see what lint discovers that a C-compiler with prototypes can't >discover... Lint discovers function call mismatches automatically, while compilers using ANSI prototypes can do so only if the programmer has religiously supplied prototypes for all functions. For me, providing full prototypes (even with the aid of an automatic prototype generator) is far more work than keeping function calls correct by hand, and correcting the occasional problems that lint detects. Steve Summit scs@adam.mit.edu
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (05/31/90)
In article <00937758.16FBE220@rigel.efd.lth.se> e89hse@rigel.efd.lth.se writes: > I don't see what lint discovers that a C-compiler with prototypes can't >discover, except wrong external declarations like: hello[100], char *hello. Isn't that _enough_? How is an ANSI C compiler, with just one file to look at, going to notice that you've defined two functions with the same name in different files? Yes, the linker will catch that one, but the linker won't tell you which lines the definitions are on, and lint will. And if you have set up a lint-library file for a local library, lint can warn you about attempts to redefine a function in the local library (an ANSI C compiler should tell you about redefining standard library functions, but might not warn you about conflicts with X) even though a linker might _not_ warn you about multiple definitions. (As the UNIX linker would not; it won't pull a library entry in if the function is already defined.) -- "A 7th class of programs, correct in every way, is believed to exist by a few computer scientists. However, no example could be found to include here."
ghoti+@andrew.cmu.edu (Adam Stoller) (05/31/90)
Excerpts from netnews.comp.lang.c: 31-May-90 Re: Can lint help an ANSI-C.. e89hse@rigel.efd.lth.se (1405) > Well, I've found that 99% of the times I write: printf("name=%s\n"); I > just don't care about the return value... Lint warnings about igonred > return values have never helped me up to now, just bothered me. (BTW if exit() is properly declared there won't be any warning.) You may not care about the return value - but does your compiler take the time to warn you that you didn't supply a needed argument to the printf() call?? (does lint warn about this?) --fish
e89hse@rigel.efd.lth.se (05/31/90)
In article <24660@mimsy.umd.edu>, cml@tove.cs.umd.edu (Christopher Lott) writes: >A few thoughts about lint, prompted by this posting: >In article <00937758.16FBE220@rigel.efd.lth.se> e89hse@rigel.efd.lth.se writes: >> I don't see what lint discovers that a C-compiler with prototypes can't >>discover, except wrong external declarations like: hello[100], char *hello. > >Lint will bring many common constructs to your attention. >An example is doing a test on a constant expression, like >"if (i = 1)" where the programmer perhaps meant "if (i == 1)" But you don't have to have lint to do that, in fact TurboC will warn you for that. >Another example is of functions returning values which are ignored. >This warning causes much irritation for functions like "exit()" but >can point the way to a fault in the code. Well, I've found that 99% of the times I write: printf("name=%s\n"); I just don't care about the return value... Lint warnings about igonred return values have never helped me up to now, just bothered me. (BTW if exit() is properly declared there won't be any warning.) > Lint can also help detect >nonportable constructs, but I can't think of a good example just now. Yes, but a compiler could warn you about that. (I'm not sure if anyone do.) If you write something like: printf("ASC(%u)=%c\n",++c,c); you'd better go back a take a look at the text books... Henrik Sandell
barmar@think.com (Barry Margolin) (06/01/90)
In article <009377E6.C32DAB80@rigel.efd.lth.se> e89hse@rigel.efd.lth.se writes: >In article <24660@mimsy.umd.edu>, cml@tove.cs.umd.edu (Christopher Lott) writes: >> Lint can also help detect >>nonportable constructs, but I can't think of a good example just now. > Yes, but a compiler could warn you about that. (I'm not sure if anyone do.) There are very few things that lint warns about that a compiler *couldn't*. But it checks lots of things that many C compilers *don't*. It is traditional that C compilers do minimal checking, and lint is used when the programmer wants extensive checking. This tradition is fading, though, as C has reached more environments. For instance, integrated development systems such as Turbo C generally ignore this tradition. GNU C also does lots of checking (although there are options to control it) because the GNU developers don't believe in tradition for its own sake. Additionally, hardware these days is much faster than the hardware that originally ran C, so adding the checks to the compiler doesn't make it intolerably slow. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
dmb@ns.network.com (Duane M. Butler) (06/01/90)
In article <36985@think.Think.COM> barmar@nugodot.think.com (Barry Margolin) writes: >... >There are very few things that lint warns about that a compiler *couldn't*. ^^^ ^^^^^^^^ >But it checks lots of things that many C compilers *don't*. It is Lint checks consistency across multiple files. I don't know of any C compilers that can do this. duane.
zuhn@umn-cs.cs.umn.edu (Zoo) (06/03/90)
>>>>> On 31 May 90 11:25:42 GMT, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) said:
Richard> How is an ANSI C compiler, with just one file to look at,
Richard> going to notice that you've defined two functions with the
Richard> same name in different files? Yes, the linker will catch
Richard> that one, but the linker won't tell you which lines the
Richard> definitions are on, and lint will.
Then fix your linker... I use GNU ld and it does just what you say
the linker won't do. You don't need lint to catch this.
I use GNU CC (writing ANSI style programs) and would like to be able to
use lint but I don't have access to any that deal with ANSI'isms. But
the rest of the compile-link suite of tools is getting better and better
in respect to catching things that were once caught only by lint.
david d [zoo] zuhn Univ. of Minnesota Dept. of Astronomy
zoo@aps1.spa.umn.edu Automated Plate Scanner Projectok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (06/03/90)
In article <ZUHN.90Jun2145646@umn-cs.cs.umn.edu>, zuhn@umn-cs.cs.umn.edu (Zoo) writes: > >>>>> On 31 May 90 11:25:42 GMT, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) said: > RAOK> How is an ANSI C compiler, with just one file to look at, > RAOK> going to notice that you've defined two functions with the > RAOK> same name in different files? Yes, the linker will catch > RAOK> that one, but the linker won't tell you which lines the > RAOK> definitions are on, and lint will. > Then fix your linker... I use GNU ld and it does just what you say > the linker won't do. You don't need lint to catch this. Will you kindly tell me how I can fix the linker on an Encore Multimax *without source*? Obviously a linker _could_ do this, what I said and meant is that the linkers I have to use _won't_. I learned programming on a B6700, and have never understood why other binders are less capable. But they are. If GNU ld runs on Encores, I would like to hear about it (they use COFF, even under their "BSD" version, and there are extensions to deal with sharing and other parallel-related features). What's more, even GNU ld can't report line number information that isn't _there_, and the default behaviour of cc at any rate on this system is _not_ to produce line number information. I tested this by doing cc -c last.c aoutdump -l last.o which found no line number information in last.o. Obviously, a C compiler *could* do what the Burroughs Fortran, Algol, Cobol, ESPOL, PL/I, and so on compilers did back in the 60s and leave *complete* symbol table information and complete line number information in object files as a matter of course, and linkers *could* act like the Burroughs "Binder" and check that all the references to a symbol were type-consistent. It would even be possible to have a language-specific means of checking interfile consistency despite the limitations of a linker, as Simula 67 had in the 60s and as Ada has at this day. But there is nothing in X3.159 to *force* any of this. I note that my posting listed a number of other things that lint could do for you which Zuhn has not listed Gcc/Gld as currently doing; I'll stipulate that there is no reason in principle why they _couldn't_. I'll also point out that by the time you have a compiler/linker system that _does_ do these intermodule checks, what you'll have will _be_ lint in everything but name. -- "A 7th class of programs, correct in every way, is believed to exist by a few computer scientists. However, no example could be found to include here."
harrison@necssd.NEC.COM (Mark Harrison) (06/04/90)
In article <caNG2OS00as90XZ11a@andrew.cmu.edu>, ghoti+@andrew.cmu.edu (Adam Stoller) writes: > You may not care about the return value - but does your compiler take > the time to warn you that you didn't supply a needed argument to the > printf() call?? > > (does lint warn about this?) Gimpel {PC,Flexe}-Lint checks printf/scanf strings. printf("a[%d] = %d\n", a[i]) will get a warning. When we checked our 70,000 line project (at a former company), we found five or six problems like this, almost exclusively in fatal error reporting code. -- Mark Harrison harrison@necssd.NEC.COM (214)518-5050 {necntc, cs.utexas.edu}!necssd!harrison standard disclaimers apply...
harrison@necssd.NEC.COM (Mark Harrison) (06/04/90)
In article <36985@think.Think.COM>, barmar@think.com (Barry Margolin) writes: > It is > traditional that C compilers do minimal checking, and lint is used when the > programmer wants extensive checking. This tradition is fading, though, as > C has reached more environments. For instance, integrated development > systems such as Turbo C generally ignore this tradition. GNU C also does > lots of checking (although there are options to control it) because the GNU > developers don't believe in tradition for its own sake. Turbo C also has options to control how much checking is performed. -- Mark Harrison harrison@necssd.NEC.COM (214)518-5050 {necntc, cs.utexas.edu}!necssd!harrison standard disclaimers apply...
ado@elsie.UUCP (Arthur David Olson) (06/09/90)
> You may not care about the return value - but does your compiler take > the time to warn you that you didn't supply a needed argument to the > printf() call?? > > (does lint warn about this?) Some lint's, and some newer gcc's, do. -- Arthur David Olson ado@alw.nih.gov ADO is a trademark of Ampex. Script started on Fri Jun 8 20:20:01 1990 elsie$ cat try.c #include <stdio.h> func() { printf("name=%s\n"); } elsie$ gcc -c -Wformat try.c try.c: In function func: try.c:5: warning: too few arguments for format elsie$ exit script done on Fri Jun 8 20:20:35 1990