kern/164674: vsprintf/vswprintf return error (EOF) on success if __SERR flag is already set on file

Matthew Story matthewstory at gmail.com
Thu Feb 16 16:00:28 UTC 2012


The following reply was made to PR kern/164674; it has been noted by GNATS.

From: Matthew Story <matthewstory at gmail.com>
To: freebsd-gnats-submit at freebsd.org, freebsd-standards at 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 at 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">&lt;<a hre=
 f=3D"mailto:matthewstory at gmail.com" target=3D"_blank">matthewstory at gmail.co=
 m</a>&gt;</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>
 &gt;Number: =A0 =A0 =A0 =A0 164674<br>
 &gt;Category: =A0 =A0 =A0 kern<br>
 &gt;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 &quot;if an output or encoding error occurred.&quot; 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">
 &gt;Confidential: =A0 no<br>
 &gt;Severity: =A0 =A0 =A0 non-critical<br>
 &gt;Priority: =A0 =A0 =A0 low<br>
 &gt;Responsible: =A0 =A0freebsd-bugs<br>
 &gt;State: =A0 =A0 =A0 =A0 =A0open<br>[...snip]<br>
 &gt;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--


More information about the freebsd-bugs mailing list