On Mon, Mar 12, 2012 at 01:50:27AM +0100, Denys Vlasenko wrote: > On Sunday 11 March 2012 18:10, Rich Felker wrote: > > On Sun, Mar 11, 2012 at 04:12:19PM +0100, Denys Vlasenko wrote: > > > On Sunday 11 March 2012 14:46, Denys Vlasenko wrote: > > > > I propose the following patch. > > > > Only compile tested by me, care to run-test? > > > > > > A more correct (I hope) version: > > > > I'm curious why this is such a big patch introducing new functions and > > struct members. Couldn't it be just a one-line change in the function > > that writes out the buffers (i.e. do the buffer-voiding as soon as the > > error is hit rather than testing for it later)? > > EINTR and EAGAIN should not result in output buffers being dropped. > You need to remember the error code for this.
Why? I don't see any way an application could make use of this behavior to avoid losing data on EINTR or EAGAIN. As an application writer I would just treat any write error (or short write) from stdio as an unrecoverable situation. Even if some implementations might find a way to make it so an application could recover (I'd be interested in hearing if you have an idea how this would work...), I don't see any part of the standard that requires the implementation to behave that way, so an application depending on it would be non-portable. > > Perhaps I'm missing > > something about uclibc's design that makes this not work well, but > > it's how my implementation in musl has always done it and I could > > switch to the bad glibc behavior just by changing one line... > > How about this simpler one? Looks better. Rich _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
