Re: Making stdio writes robust/recoverable under errors

[Rich Felker <dalias@libc.org>]

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