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

[Alfred Perlstein]

On 12/29/17 10:27 AM, Ian Lepore wrote:
> On Fri, 2017-12-29 at 10:19 -0800, Yuri wrote:
>> Some base utilities sometimes close files that they open for their
>> purposes without checking the error code of close(2).
>>
>> Is this considered to be ok, because it's just a close call and we
>> are
>> done with that file descriptor, or is it considered to be more
>> appropriate to check close's error code?
>>
>> Maybe there is some policy that covers this?
>>
>> IMO, every system call's return value should be checked, just in
>> case.
>>
>>
>> Yuri
>>
> 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?
>
A file open for writing should be tested on close for NFS and other 
filesystems that have "fsync on close" semantics.

-Alfred