[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 6 Jun 2015 01:32:57 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Making stdio writes robust/recoverable under errors
On Fri, Jun 05, 2015 at 11:47:33PM +0200, Laurent Bercot wrote:
> 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.
Yes, I'm aware of your position, and while I don't agree with it in
general -- there are plenty of cases where the weak control/guarantees
stdio gives you are perfectly fine and worth the simplicity and
portability the buy you -- I think you're right on this one. I meant
to mention that glibc currently behaves like musl does now, at least
for regular files.
I still think this issue should be kept "open" at least until musl's
stdio internals are well-documented, because there might currently be
inconsistent behavior with regards to how fmemopen and
open_[w]memstream files behave, which should be investigated. But I'm
leaning towards not trying to preserve buffer contents after write
errors.
Rich
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.
