Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 1 Jan 2018 07:54:10 -0800
From:      Mark Millard <markmi@dsl-only.net>
To:        Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc:        "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net>, FreeBSD Hackers <freebsd-hackers@freebsd.org>
Subject:   Re: Is it considered to be ok to not check the return code of close(2) in base?
Message-ID:  <6658FD9E-3170-4249-8AEC-002E112473F4@dsl-only.net>
In-Reply-To: <69801.1514801240@critter.freebsd.dk>
References:  <201801010305.w0135luG084158@pdx.rh.CN85.dnsmgr.net> <559541DD-3287-4473-B7DE-B4DDC6860DF7@dsl-only.net> <5AD2D86A-2515-4D4D-91B2-1919531F7CC3@dsl-only.net> <69801.1514801240@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help

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

> --------
> In message <5AD2D86A-2515-4D4D-91B2-1919531F7CC3@dsl-only.net>, Mark =
Millard wr
> ites:
>=20
>> asserts that call abort are difficult to
>> guarantee specific program-exit behavior
>> for, based on just the standards anyway.
>=20
> One should read "assert" in a source code as a curse along the lines =
of
> "Strike me by lightning if this is not true!"
>=20
> If you want more gentle behaviour you should implement proper =
errorhandling.
>=20
> 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".


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6658FD9E-3170-4249-8AEC-002E112473F4>