Is it considered to be ok to not check the return code of close(2) in base?

[Rodney W. Grimes]

> 30.12.2017 1:27, Ian Lepore wrote:
> 
> > There's really no point in checking on a close from a file opened only
> > for reading.  You can argue it should be checked on a file open for
> > writing, but often isn't because you're then confronted with the
> > question "what should/can I do if there is an error?"  If you report
> > the error and exit, then what about other files that were open at the
> > time?  They're going to be closed by the kernel as part of process
> > cleanup, with no error checking or reporting.
> > 
> > Also, with the async nature of filesystems, IO errors can still happen
> > after the close, unless fsync() was used.  So if you're going to miss
> > most of the errors because of that, why bother to check at all?
> 
> Almost any file opened for writing may occur to reside on NFS
> or some strange FUSE file system or just on removable storage.
> 
> As general rule, an application should somehow report any file i/o error
> including close(), especially when data loss can happen due to unflushed buffers.
> 
> It may be messages written to syslog or stderr with no error checking here
> to prevent recursion. For example, a word processing application must warn
> user in any such case and not remove temporary copy, if any etc.
> 
> It's up to user whether to utilize such async filesystems that lie about
> success of close() system call. Properly written application should not excuse itself
> just because of existence of such file systems.
> 
> Of course, there are cases when that's irrelevant, f.e. closing temporary file
> that is no more needed and being unlinked anyway.

No error on close should be treated as irreleveant, they signify something
has gone wrong and itis best to inform the user and let the user decide
if this is irrelevant or not.

Code that does not test return codes from EVERY single thing that can
return an error should be taken out back shown the danish axe, clean it
up or get it out of our tree!

One should never code to the "normal" conditions situation, it makes for
code that does not work well when the "abnormal" conditions arrise.

I would argue that in the above sample of "closing and unlinking" it
would actually be better to exit if the close failed possibly leaving
behind the evidence of why/what failed rather than blindling forging
ahead and potentially destroying the evidecnce by unlinking the file.

If someone wants to go chasing after "failure to check exit codes" please
begin with /etc/rc.d/*, these scripts are so full of it I laugh every
time I see a system come up multiuser after 10+ errors have happendend
in them.

-- 
Rod Grimes                                                 rgrimes at freebsd.org