[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <557218F5.20306@skarnet.org>
Date: Fri, 05 Jun 2015 23:47:33 +0200
From: Laurent Bercot <ska-dietlibc@...rnet.org>
To: musl@...ts.openwall.com
Subject: Re: Making stdio writes robust/recoverable under errors
On 05/06/2015 23:14, Rich Felker wrote:
> I'm a bit undecided on whether to move forward with this or not. While
> there's some benefit to being able to resume/recover transient errors
> that occur during buffered writing, there are also disadvantages
My unpopular but firm opinion, which I already have expressed here, is
that stdio is a toy interface that should not be used for any output that
requires the simplest hint of reliability. The loss of information about
the number of bytes actually written when an error occurs is a major
pain point; even if the underlying implementation is as good as can be,
the API is just too poor and it's either fight the interface (in which
case you have already lost), use non-portable extensions (which musl aims
to avoid), or put stdio back into the trash bin and use something else
entirely.
People who use stdio and expect good behaviour when an error occurs
deserve what's coming at them, and I think that worse is better in this
case: fail as badly as is permitted by the standard instead of trying to
salvage as many scraps as you can. Even if you manage to save a few close
calls, the next crash and burn is just around the corner. So, I vote for
not devoting any more brain power to "stdio robustness" than is strictly
necessary to be standards-compliant.
--
Laurent
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
