Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!husc6!panda!genrad!decvax!ittatc!bunkerb!garys
From: garys@bunkerb.UUCP (Gary M. Samuelson)
Newsgroups: net.lang.c
Subject: Re:  questions from using lint
Message-ID: <640@bunkerb.UUCP>
Date: Tue, 13-May-86 13:35:00 EDT
Article-I.D.: bunkerb.640
Posted: Tue May 13 13:35:00 1986
Date-Received: Fri, 16-May-86 05:06:53 EDT
References: <501@brl-smoke.ARPA> <797@bentley.UUCP>
Reply-To: garys@bunkerb.UUCP (Gary M. Samuelson)
Organization: Bunker Ramo, Trumbull Ct
Lines: 30

In article <797@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes:

>[2] close(), as near as I can tell, can only fail by being handed a number
>    that does not denote an open file.  I usually assume that this error
>    would have been caught earlier.

Assuming a buffered device, the last block of data will not be physically
written until close(), in which case nearly all of the errors possible with
write() could occur with close().

>[3] unlink() and most other system calls should be checked!  (It's too bad
>    lint can't tell whether you've tested the return value of open(), etc.)

??? Lint certainly can check for that (at least the lint I use); it says
something like "open returns value which is sometimes ignored" (or
"always", as the case may be).  It does this by checking the definition
of open() in /usr/lib/lint

>"lint returns an error which is always ignored" :-)

This is going to my collection of classic quotes.

From Jim Cotrl (yes, I know the spelling is wrong, but after all,
think of all the keystrokes I saved):
>>And as someone pointed out, assignments return a value too, so should we
>>cast them to void as well?  Oh yeah, assignment is `different'.

If I say "a = b", I have clearly used the value of the expression.

Gary Samuelson