An overview ...
Tom Culliton x2278
culliton at cdss.UUCP
Wed Jul 4 01:42:59 AEST 1990
In article <1990Jul1.065531.18620 at acc.stolaf.edu>, hannum at haydn.psu.edu (Charles Hannum) writes:
> of some of the current flame wars on comp.lang.c ...
>
... deleted text ...
>
> How to shut up lint
> -------------------
>
> How do you keep lint from complaining about things like the arguments to
> malloc()?
>
> My solution: Don't use lint; it's ancient and brain-dead. Learn C, or get a C
> guru to help you.
>
... deleted text ...
PLEASE, don't encourage people to abandon lint! Yes, its not all that it
could/should be, BUT, I've seen a lot of code that could have really
benifited from an inspection by the cranky old lady of the "C"
programming world. You don't have to fix all the things that it
complains about but its catches things that you might otherwise overlook.
Let me give you an example... When I was porting some GNU code at my
last job (it was either SED or AWK, I don't recall which) there were a
couple of terrible problems I was having a hard time tracking down, (and
I'm something of a guru at debugging) the breakthrough was when I ran
the whole thing through lint. Lint gave me a LOT of extraneous garbage,
which I ignored, and spotted a couple of functions which didn't return a
value along every path! My immediate question was, why hadn't somebody
else taken such a simple QC step before releasing the silly thing?
Using lint does take some judgement, (you can't and shouldn't fix
everything it complains about) but isn't that one of the principles of C
programming? The programmer should be trusted to be a responsible adult
and take the necessary steps to produce solid dependable code in return
for the freedom to do whatever it takes to get there. In my opinion
using lint, or something like it, is one of those steps.
Tom
*****************************************************************************
* uunet!culliton at cdss - Tom Culliton at Arinc Research Corp. Annapolis MD *
* "I haven't lost my mind -- it's backed up on tape somewhere." *
*****************************************************************************
More information about the Comp.lang.c
mailing list