From owner-freebsd-bugs@FreeBSD.ORG Thu Feb 16 16:00:28 2012 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99797106564A for ; Thu, 16 Feb 2012 16:00:28 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 828F18FC0C for ; Thu, 16 Feb 2012 16:00:28 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1GG0S8O001037 for ; Thu, 16 Feb 2012 16:00:28 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1GG0Sxg001035; Thu, 16 Feb 2012 16:00:28 GMT (envelope-from gnats) Date: Thu, 16 Feb 2012 16:00:28 GMT Message-Id: <201202161600.q1GG0Sxg001035@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Matthew Story Cc: Subject: Re: kern/164674: vsprintf/vswprintf return error (EOF) on success if __SERR flag is already set on file X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthew Story List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 16:00:28 -0000 The following reply was made to PR kern/164674; it has been noted by GNATS. From: Matthew Story 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 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 <matthewstory@gmail.co= m> wrote:

>Number: =A0 =A0 =A0 =A0 164674
>Category: =A0 =A0 =A0 kern
>Synopsis: =A0 =A0 =A0 vfprintf/vfwprintf return error (EOF) on success = if __SERR flag is already set on file

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.
=A0
>Confidential: =A0 no
>Severity: =A0 =A0 =A0 non-critical
>Priority: =A0 =A0 =A0 low
>Responsible: =A0 =A0freebsd-bugs
>State: =A0 =A0 =A0 =A0 =A0open
[...snip]
>Description:
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= ).

=A0* For the case of an unbuffered file, =A0the operation currently fails t= ransmitting no bytes, and returns -1.
=A0* 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. = =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.

Per the ISO/IEC 9899:201x (C11) Section 7.21.6.1, 14:

The fprintf function returns the number of characters transmitted, or a neg= ative 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. =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).

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.

[...snip]

--
regards,
matt
--14dae93403056d11e204b916da9f--