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

[Mark Millard]

On 2018-Jan-1, at 2:07 AM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:

> --------
> In message <5AD2D86A-2515-4D4D-91B2-1919531F7CC3 at dsl-only.net>, Mark Millard wr
> ites:
> 
>> asserts that call abort are difficult to
>> guarantee specific program-exit behavior
>> for, based on just the standards anyway.
> 
> One should read "assert" in a source code as a curse along the lines of
> "Strike me by lightning if this is not true!"
> 
> If you want more gentle behaviour you should implement proper errorhandling.
> 
> But for all the places where you think "Nahh ... that's never going to
> happen", you should document your decision with assert().

(I'm ignoring the NDEBUG issue here.)

Just be sure that for your context of use
that the consequences of failure can be
tolerated.

Even the vintage of linux glibc matters:

http://man7.org/linux/man-pages/man3/abort.3.html

says:
(note the reference to deadlocks and data corruption)

       Up until glibc 2.26, if the abort() function caused process
       termination, all open streams were closed and flushed (as with
       fclose(3)).  However, in some cases this could result in deadlocks
       and data corruption.  Therefore, starting with glibc 2.27, abort()
       terminates the process without flushing streams.  POSIX.1 permits
       either possible behavior, saying that abort() "may include an attempt
       to effect fclose() on all open streams".


===
Mark Millard
markmi at dsl-only.net