[PATCH] prevent retries on fclose/fflush after write errors

Rich Felker dalias at aerifal.cx
Mon Mar 12 03:36:58 UTC 2012


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


More information about the uClibc mailing list