Path: utzoo!attcan!uunet!samsung!uakari.primate.wisc.edu!uflorida!novavax!twwells!bill
From: bill@twwells.com (T. William Wells)
Newsgroups: comp.lang.c
Subject: Re: Discarded Function Values (To Cast or Not to Cast)
Message-ID: <1989Nov19.171815.17445@twwells.com>
Date: 19 Nov 89 17:18:15 GMT
References: <316@voa3.UUCP> <1989Nov17.154621.2698@aqdata.uucp> <1989Nov18.062322.12728@twwells.com> <11644@smoke.BRL.MIL>
Organization: None, Ft. Lauderdale, FL
Lines: 50

In article <11644@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
: In article <1989Nov18.062322.12728@twwells.com> bill@twwells.com (T. William Wells) writes:
: >I don't worry about lint warnings about functions whose return
: >value is never used. It is generally a very short list, ...
:
: If it isn't a problem for you, more power to you.

Not so long as I keep the list *short*.

: I find that I am less likely to overlook genuine problems
: reported by "lint" if NO lint output is expected than if
: SOME lint output is expected.  This is difficult to enforce
: when malloc() is involved, although there are ways.

I've found that completely shutting up lint is not worth my time.
Not that it is impossible, but I have better things to do.

For example, read() and write(), on different machines, take
either an unsigned int or an int as their third arguments; while
one *could* set things up so that lint won't complain about this,
why bother?

Another gotcha is those irritating truncated long messages; at
least one lint I've worked with won't stop them even if you use a
cast. (And what is so irritating is that one *can't* ignore them.)

Another irritation is the sizeof problem. Things that want a size
should take an unsigned something (or a size_t). But sizeof often
generates an int, which some lints complains about.

Anyway, my approach to this is to shut lint up on anything where
I might be confused by its output, and ignore the rest. (In one
case, I got sufficiently irritated that I wrote a script to
remove the noise. This is risky, unfortunately.)

One thing that helps is that I do most of my work development at
home on my sysV/386 and immediately port it to the Sun at work.
(Typically, I develop it here at home and then run it there:
4MIPS bests ~2MIPS, especially when it takes two hours even at 4!)
Porting is usually a copy, but I sometime catch errors that way.
The real advantage is that, when coding, I am pretty much required
to keep in mind that there are at *least* three other kinds of
machines that my code *will* be run on.

That is a real incentive to avoid those practices that lint would
otherwise complain about.

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.com