Date: Wed, 21 Mar 2012 23:43:24 -0400 From: Matthew Story <matthewstory@gmail.com> To: Matthew Story <matthewstory@gmail.com>, standards@freebsd.org, jhb@freebsd.org Subject: Re: PR kern/164674 Message-ID: <CAB%2B9ogdc3g4BAvzQkjEnPL9QGRmUxN2bn8bg=7N_cytjjJ2MRA@mail.gmail.com> In-Reply-To: <20120321214525.GA46850@zim.MIT.EDU> References: <201203041403.29020.jhb@freebsd.org> <CAB%2B9ogfLych1xcCR1eVT%2BAMCsUah0EC6nZ-%2Bm3ixHtwJ5Pb5aw@mail.gmail.com> <20120321214525.GA46850@zim.MIT.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 21, 2012 at 5:45 PM, David Schultz <das@freebsd.org> wrote: > On Mon, Mar 12, 2012, Matthew Story wrote: > > On Sun, Mar 4, 2012 at 2:03 PM, John Baldwin <jhb@freebsd.org> wrote: > [...snip] > There ought to be a less ugly fix than the one proposed. Probably > the PRINT macro and the various other evil macros in vfprintf() > should set ret to EOF, and the following lines in vfprintf.c should > be removed: > > if (__sferror(fp)) > ret = EOF; > > If vfprintf() is fixed so that printing to a buffered stream > always returns success after a successful write (regardless of the > prior state of the stream's error indicator), that should fix the > problem for unbuffered streams automatically. Unbuffered streams > go through __sbprintf(), which throws away the output if > vfprintf() returns -1. > yeah ... I wasn't overly pleased with my fix as it stands. my concern was that the __sferror(fp) acts as a catch-all for any non-handled error case in the actual print logic. there are only 2 places in the function that explicitly set __SERR and goto error. i'll do a thorough audit of all potential side-effects of the above calls re: __SERR, and follow-up with something less butchered. -- regards, matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAB%2B9ogdc3g4BAvzQkjEnPL9QGRmUxN2bn8bg=7N_cytjjJ2MRA>