Date: Thu, 16 Feb 2012 16:00:28 GMT From: Matthew Story <matthewstory@gmail.com> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/164674: vsprintf/vswprintf return error (EOF) on success if __SERR flag is already set on file Message-ID: <201202161600.q1GG0Sxg001035@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/164674; it has been noted by GNATS. From: Matthew Story <matthewstory@gmail.com> To: freebsd-gnats-submit@freebsd.org, freebsd-standards@freebsd.org Cc: Subject: Re: kern/164674: vsprintf/vswprintf return error (EOF) on success if __SERR flag is already set on file Date: Thu, 16 Feb 2012 10:55:11 -0500 --14dae93403056d11e204b916da9f Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jan 31, 2012 at 6:06 PM, Matthew Story <matthewstory@gmail.com>wrote: > > >Number: 164674 > >Category: kern > >Synopsis: vfprintf/vfwprintf return error (EOF) on success if > __SERR flag is already set on file > Apologies for cross-posting, but I think that standards might be a more appropriate responsible party for this than -bugs or kern. See description for more info, but the basic issue is that C99 and C11 stipulate that fprintf should return -1 "if an output or encoding error occurred." Currently, printf is encoding and outputting successfully (on line or fully buffered FILEs), but returning -1 if the FILE has an error. The C99/C11 specifications make no mention of FILE state in fprintf return conditions, so this functionality seems to not conform to the specification, attached patch resolves that issue. > >Confidential: no > >Severity: non-critical > >Priority: low > >Responsible: freebsd-bugs > >State: open > [...snip] > >Description: > The printf family of functions behaves unpredictably if the file passed to > the function has the __SERR flag set in _flags. The one consistency across > all of the cases detailed below is that regardless of the number of bytes > written to the file, and the success/failure of that operation, the printf > functions (printf, fprintf, wprintf, fwprintf) will always return -1 (EOF). > > * For the case of an unbuffered file, the operation currently fails > transmitting no bytes, and returns -1. > * For the case of a buffered file, the operation transmits all bytes and > the function returns -1. > > The problem is that the behavior here is inconsistent, and should not be. > The question is wether all should be made to fail consistently and > transmit no bytes if __SERR is set on _flags, or if failure should be > determined based on the success of byte transmission, discounting file > state. > > Per the ISO/IEC 9899:201x (C11) Section 7.21.6.1, 14: > > The fprintf function returns the number of characters transmitted, or a > negative value if an output or encoding error occurred. > > My reading of this specification is that success should be determined > based on byte-transmission, and should not factor-in file state. In > addition to the ISO standard, the glibc implementation will reliably > succeed with any error flag set if bytes are successfully transmitted > (although it will transmit partial messages prior to successful conversion, > which is unfortunate). > > The attached patch makes the operation on buffered and unbuffered files > consistent across the affected printf/wprintf functions, determines > success/failure based on successful byte-transmission alone, and preserves > _flags state for __SERR as passed in. > > [...snip] -- regards, matt --14dae93403056d11e204b916da9f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jan 31, 2012 at 6:06 PM, Matthew Story <span dir=3D"ltr"><<a hre= f=3D"mailto:matthewstory@gmail.com" target=3D"_blank">matthewstory@gmail.co= m</a>></span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"= gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-= left:1ex"> <br> >Number: =A0 =A0 =A0 =A0 164674<br> >Category: =A0 =A0 =A0 kern<br> >Synopsis: =A0 =A0 =A0 vfprintf/vfwprintf return error (EOF) on success = if __SERR flag is already set on file<br></blockquote><div><br></div><div>A= pologies for cross-posting, but I think that standards might be a more appr= opriate responsible party for this than -bugs or kern. =A0See description f= or more info, but the basic issue is that C99 and C11 stipulate that fprint= f should return -1 "if an output or encoding error occurred." Cur= rently, printf is encoding and outputting successfully (on line or fully bu= ffered FILEs), but returning -1 if the FILE has an error. =A0The C99/C11 sp= ecifications make no mention of FILE state in fprintf return conditions, so= this functionality seems to not conform to the specification, attached pat= ch resolves that issue.</div> <div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex"> >Confidential: =A0 no<br> >Severity: =A0 =A0 =A0 non-critical<br> >Priority: =A0 =A0 =A0 low<br> >Responsible: =A0 =A0freebsd-bugs<br> >State: =A0 =A0 =A0 =A0 =A0open<br>[...snip]<br> >Description:<br> The printf family of functions behaves unpredictably if the file passed to = the function has the __SERR flag set in _flags. =A0The one consistency acro= ss all of the cases detailed below is that regardless of the number of byte= s written to the file, and the success/failure of that operation, the print= f functions (printf, fprintf, wprintf, fwprintf) will always return -1 (EOF= ).<br> <br> =A0* For the case of an unbuffered file, =A0the operation currently fails t= ransmitting no bytes, and returns -1.<br> =A0* For the case of a buffered file, the operation transmits all bytes and= the function returns -1.<br> <br> The problem is that the behavior here is inconsistent, and should not be. = =A0 The question is wether all should be made to fail consistently and tran= smit no bytes if __SERR is set on _flags, or if failure should be determine= d based on the success of byte transmission, discounting file state.<br> <br> Per the ISO/IEC 9899:201x (C11) Section 7.21.6.1, 14:<br> <br> The fprintf function returns the number of characters transmitted, or a neg= ative value if an output or encoding error occurred.<br> <br> My reading of this specification is that success should be determined based= on byte-transmission, and should not factor-in file state. =A0In addition = to the ISO standard, the glibc implementation will reliably succeed with an= y error flag set if bytes are successfully transmitted (although it will tr= ansmit partial messages prior to successful conversion, which is unfortunat= e).<br> <br> The attached patch makes the operation on buffered and unbuffered files con= sistent across the affected printf/wprintf functions, determines success/fa= ilure based on successful byte-transmission alone, and preserves _flags sta= te for __SERR as passed in.<br> <br>[...snip]</blockquote></div><div><br></div>-- <br>regards,<br>matt<br> --14dae93403056d11e204b916da9f--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201202161600.q1GG0Sxg001035>