Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 05 Jun 2015 23:47:33 +0200
From: Laurent Bercot <>
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

  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.


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.