Discarded Function Values (To Cast or Not to Cast)

T. William Wells bill at twwells.com
Fri Nov 24 10:34:03 AEST 1989


In article <20882 at mimsy.umd.edu> kilroy at mimsy.umd.edu (Nancy's Sweetie) writes:
: In article <11644 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn) writes:
: > 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.
:
: With which I totally agree:  shut up lint.  Completely.
:
: In article <1989Nov19.171815.17445 at twwells.com> bill at twwells.com
: (T. William Wells) writes:
: >
: >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.
:
: and
:
: >Anyway, my approach to this is to shut lint up on anything where
: >I might be confused by its output, and ignore the rest.
:
: Which irritates me more than I can express.  (Though I'll try anyway.  8-)
:
: [He then goes on to describe a program modified by a bunch of asshole
: programmers.]

If someone wants to take my code and do stupid things with it, I
can't stop him. Even if I had written my code to be lintless, had
they not used lint after each modification, it would be as bad as
if I had left in lint warnings.

: Now, you may feel that you have better things to do, and you may feel that
: *you* are not confused by some of the messages.  But if you don't care to
: put *hard work* into making your programs maintainable for the next guy who
: comes along, then why are you even bothering to write programs?

Because, you asshole, I *do* put hard work into my programs. But
there are are better things for me to do than to deal with this:

function returns value which is always ignored
    fprintf         umask           putenv
    setgid          setuid          time
    signal          strcpy          unlink
    fflush          printf          sprintf
    strcat          sleep           fputs

(The sum total of lint warnings from a program *under
development*. I can tell you why *each* of these is there. And I
can tell you, also, which I'm not going to get rid of in the
production version.)

(Why the obscenity? If people throw ad hominems at me, I feel it
perfectly reasonable to return them in kind.)

: I also have things to do besides spend a half hour ensuring that a program
: that works has all the lint-shutter-uppers in it.  But a little hard work
: never killed anybody, especially if it can help the next person in line.
: Nobody will ever get *any* lines of output running lint on a program I've
: written, let alone ~800.

EXCUSE me. If I have a half hour to spend, I have to decide on
where it is best spent. Since I'm already chin deep in things to
do, I'm not going to spend time on something that makes no
significant difference.

If the people who are working with your programs are competent, a
few lint warnings will be easy enough for them to deal with. If
they are not, nothing you can do will make a bit of difference.

Followups have been directed to alt.flame.

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



More information about the Comp.lang.c mailing list