From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7887 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Making stdio writes robust/recoverable under errors Date: Sat, 6 Jun 2015 01:32:57 -0400 Message-ID: <20150606053257.GX17573@brightrain.aerifal.cx> References: <20150529135300.GD17573@brightrain.aerifal.cx> <20150605211401.GW17573@brightrain.aerifal.cx> <557218F5.20306@skarnet.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1433568797 21837 80.91.229.3 (6 Jun 2015 05:33:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Jun 2015 05:33:17 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7900-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jun 06 07:33:17 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Z16jK-00077y-Kt for gllmg-musl@m.gmane.org; Sat, 06 Jun 2015 07:33:14 +0200 Original-Received: (qmail 32230 invoked by uid 550); 6 Jun 2015 05:33:11 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 32210 invoked from network); 6 Jun 2015 05:33:10 -0000 Content-Disposition: inline In-Reply-To: <557218F5.20306@skarnet.org> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7887 Archived-At: 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