Re: close return value

["Patrick J. LoPresti" <patl@curl.com>]

"Joseph Malicki" <jmalicki@starbak.net> writes:

> Those mistakes are your ignorance.  The manpage is wrong.  It does
> return -1 on error.  Also, errno is in libc, not the kernel.  Man
> library functions do in fact use errno.

Sigh.  OK, so I should have read SuSv2 instead of my local man page.
Mea culpa.  (Once upon a time, the buffered I/O libc routines made no
promises about which system calls they made or when.  On such systems,
errno after printf() had no guaranteed semantics.)

> And it's not an issue of whether an error is "impossible".  It's
> whether or not you would do anything if it failed.  It's not totally
> uncommon to actually not care whether or not it succeeds, but a
> valiant attempt is enough, such as in the case of printf.

If it is a diagnostic printf() to the screen, sure.  But an fprintf()
to update some state file on disk is a different matter entirely.

> Sure, if you require an event to be successful to continue you
> should always check it.  And yes, it's nice to print an error
> message on close sometimes, if something is critical.  But the
> question to ask is what you would actually _DO_ about an error... if
> the answer is nothing, then why check it?

To abort, plain and simple.  As I said, if you really think your call
to close() or gettimeofday() or whatever can never fail, you are much
better off dying immediately than proceeding on the assumption that it
succeeded.

Of course, checking errors in order to handle them sanely is a good
thing.  Nobody is arguing that.  What I am arguing is that failing to
check errors when they can "never happen" is wrong.

Anyway, back to lurker mode for me.

 - Pat