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.