From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-prs-return-16743-listarch-gcc-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 8445 invoked by alias); 3 Apr 2002 10:36:02 -0000
Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-prs/>
List-Post: <mailto:gcc-prs@gcc.gnu.org>
List-Help: <mailto:gcc-prs-help@gcc.gnu.org>
Sender: gcc-prs-owner@gcc.gnu.org
Received: (qmail 8426 invoked by uid 71); 3 Apr 2002 10:36:01 -0000
Date: Wed, 03 Apr 2002 02:36:00 -0000
Message-ID: <20020403103601.8425.qmail@sources.redhat.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
From: Richard Kettlewell <rjk@greenend.org.uk>
Subject: Re: optimization/4130: gcc 3.0 -O2 and printf optimization
Reply-To: Richard Kettlewell <rjk@greenend.org.uk>
X-SW-Source: 2002-04/txt/msg00206.txt.bz2
List-Id: <gcc-prs.sourceware.org>

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

From: Richard Kettlewell <rjk@greenend.org.uk>
To: rth@gcc.gnu.org,
    gcc-bugs@gcc.gnu.org,
    gcc-prs@gcc.gnu.org,
    nobody@gcc.gnu.org,
    gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: optimization/4130: gcc 3.0 -O2 and printf optimization
Date: Wed, 3 Apr 2002 11:25:54 +0100

 rth@gcc.gnu.org writes:
 > Synopsis: gcc 3.0 -O2 and printf optimization
 > 
 > State-Changed-From-To: open->closed
 > State-Changed-By: rth
 > State-Changed-When: Wed Apr  3 00:20:49 2002
 > State-Changed-Why:
 >     According to Uli Drepper, whom I consider an authority in this area:
 >     
 >        The handling of byte sequences which are not valid in the current locale
 >        is unspecified.  Either result is valid.  There is the different result
 >        but people writing incorrect code should not get into to way of
 >        optimizing code.  And there always is the opportunity to compile with -O0.
 >     
 >     Although -fno-builtin-printf is certainly more palletable
 >     than -O0.
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=4130
 
 My copy of the draft standard says:
 
     An encoding error occurs if the character sequence presented to
     the underlying mbrtowc function does not form a valid
     (generalized) multibyte character, or if the code value passed to
     the underlying wcrtomb does not correspond to a valid
     (generalized) multibyte character. The wide-character input/output
     functions and the byte input/output functions store the value of
     the macro EILSEQ in errno if and only if an encoding error occurs.
 
 And:
 
     The printf function returns the number of characters transmitted,
     or a negative value if an output or encoding error occurred.
 
 Granted this may have changed between the draft and the standard, but
 it looks quite adequately specified to me.
 
 ttfn/rjk