checking return values of close(2)

[Marcus J. Ranum]

In article <19547:Oct1818:25:2690 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:

>You allude to a real problem, though: an application may have to deal
>with disk-full errors on any write(). An fwaste(fd,n) syscall, to
>allocate n bytes for a file, would solve this.

	Gee - why not just have your systems programmer allocate a fixed
number of sectors of disk for each file when you create it ? :)  Oh, oops,
I forgot - it's been done. Is anyone seriously considering an fwaste()
system call ? I can imagine the results of that ("gee, better make sure I
have a spare megabyte for this one in case I need space next week - this
disk is getting awfully tight because of all the software that uses fwaste()
to grab a spare 256K)

	What's the big deal, anyhow ? So you check your close() calls
if it's important to you that your files close properly. I'm sure everyone
makes sure that fprintf() and printf() don't return EOF, too. I do. I've
had people mention that my code might be big and slow because of all the
error checking, but nothing in my experience runs as slowly as code that
has dumped core.

	A good rule of thumb is that,
"if it returns a value, it might be trying to tell you something."

	I've seen DBMS' that don't check returns on read(2) and write(2),
but I'd be reluctant to use one, and very upset if I bought one.

mjr.
-- 
Nothing is beautiful unless it is large. Vastness and immensity can make
you forget a great many weaknesses.
	- Emperor Napoleon I, predicting the development of X-window in 1813