checking return values of close(2)

[Dan Bernstein]

In article <1990Oct18.194707.12313 at decuac.dec.com> mjr at hussar.dco.dec.com (Marcus J. Ranum) writes:
> 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)

At worst the application will ftruncate() before closing the file.
fwaste()ing too much is just as dumb as write()ing too much. 

Periodically there are requests for functions to do the same thing. Most
applications know how much disk they need, and it's a lot better to
allocate the space beforehand than to wait for disaster to strike. What
do you think the news package's ``spacefor'' does? fwaste() is also very
useful for asynchronous I/O.

> 	What's the big deal, anyhow ? So you check your close() calls
> if it's important to you that your files close properly.

And do what if it returns EDQUOT? It is simply wrong for write() to
succeed if there's no space for the data. The application might erase
what it wrote; how do you expect it to recover if it doesn't find out
until later? Well?

What excuse do you have for forcing applications to buffer all their
data until close()? There's no efficiency loss in making write() return
accurate errors.

> I'm sure everyone
> makes sure that fprintf() and printf() don't return EOF, too.

But those are meant to use internal buffers, and if you want better
error checking you can and should be using descriptors directly. There's
no level to escape to below descriptors if they don't do the job.

---Dan