[comp.lang.c] So where is a lint for ANSI C code?

robert@cs.arizona.edu (Robert J. Drabek) (12/24/89)

Lint doesn't accept prototypes and in general is ignorant of the changes
made by ANSI C and C++.  The compilers with all warnings turned on still
don't give us everything lint does.

So why haven't the GNU people given us "glint"?  Or can we get hold of
an ANSI-knowledgeable lint right away?  Any leads would be appreciated.
-- 
Robert J. Drabek                            robert@cs.Arizona.EDU
Department of Computer Science              uunet!arizona!robert
The University of Arizona
Tucson, AZ  85721

gumby@Gang-of-Four.Stanford.EDU (David Vinayak Wallace) (12/25/89)

   Date: 24 Dec 89 14:44:32 GMT
   From: robert@cs.arizona.edu (Robert J. Drabek)

   So why haven't the GNU people given us "glint"?  Or can we get hold of
   an ANSI-knowledgeable lint right away?  Any leads would be appreciated.

They're mostly volenteers, you know!  You could write one.
But GCC and G++ by themselves are pretty good; with -Wall I doubt you
need a special lint.  Though they'd have to be modified to understand
/*NOTREACHED*/ and such...

quiroz@cs.rochester.edu (Cesar Quiroz) (12/27/89)

gumby@Gang-of-Four.Stanford.EDU (David Vinayak Wallace) wrote:
| But GCC and G++ by themselves are pretty good; with -Wall I doubt you
| need a special lint.

Some of lint's finest moments come when one runs it on *several* C
sources simultaneously.  The usual style of Unix C compilation is to
perform separate runs on each file for object code production, but
just one lint run on the whole thing[1].  Admittedly, prototypes
catch one of the more common reasons for having all the files
visible at once (caller-callee disagreement).  Still, a system-wide
checker that is not also expected to generate code could prove
useful.

Anecdote: once I helped some people debug a program that had a weird
case of def-def disagreement.  I think it involved a program that
declared the same structure in two files, altering the order of two
of the fields.  This was just poor coding, of course, but (1) none
of the -c compiles saw anything bad, (2) dbx just went crazy on it.
I recall that I insisted on a full-system lint and saw there the
double, inconsistent, definition.  This was under Sun OS x.y, where
x was most likely something like 2).  I tried reconstructing the
case for posting not long ago, but I failed under Sun OS 4; perhaps
someone more patient can produce an example based on the above
information.

Have a happy New Year!  And let's hope we get a C standard this
year.

Cesar ( Why didn't they invent a trigraph to let me put an accent on
that e?  I thought the C committee was into character set
standardization and transmission protocols too, right? :-)

[1] Unbelievers don't run lint at all.  Naive believers run lint on
each file separately.  None of these strategies is particularly
persuasive, although both yield plenty of excitement during
debugging.


-- 
                                      Cesar Augusto Quiroz Gonzalez
                                      Department of Computer Science
                                      University of Rochester
                                      Rochester,  NY 14627

javiv@nsi.UUCP (Javier Vilarroig Christensen.) (01/02/90)

In article <1989Dec27.035411.23602@cs.rochester.edu> quiroz@cs.rochester.edu (Cesar Quiroz) writes:
>Some of lint's finest moments come when one runs it on *several* C
>sources simultaneously.

[stuff deleted]

>[1] Unbelievers don't run lint at all.  Naive believers run lint on
>each file separately.  None of these strategies is particularly
>persuasive, although both yield plenty of excitement during
>debugging.

If you run lint with "-c" flag (yes, like cc!!), you obtain a file with
extension .ln, then you can run lint with all the .ln files, like an 
incremental compilation. It's veri useful for large sets of files.




-- 
+------------------------------------+-------------------------------------+
| Javier Vilarroig Christensen       | PHONE: 34 3 210-33-55 (VOICE)       |
| NEXUS Servicios de Informacion S.L.|        34 3 214-72-62 (DATA)        |
+------------------------------------+-------------------------------------+
| SMAIL: Travesera de Dalt 104 Ent. 5| EUNET: javiv@nsi.es                 |
|        08024 - Barcelona - Spain   |        javiv@nexus.nsi.es           |
+------------------------------------+-------------------------------------+