From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-prs-return-28810-listarch-gcc-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 18790 invoked by alias); 2 Feb 2003 17:38:24 -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 18765 invoked by uid 48); 2 Feb 2003 17:38:24 -0000
Date: Sun, 02 Feb 2003 17:38:00 -0000
Message-ID: <20030202173824.18764.qmail@sources.redhat.com>
To: bkoz@redhat.com, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
  nobody@gcc.gnu.org, paolo@gcc.gnu.org, peturr02@ru.is
From: paolo@gcc.gnu.org
Reply-To: paolo@gcc.gnu.org, bkoz@redhat.com, gcc-bugs@gcc.gnu.org,
  gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, paolo@gcc.gnu.org, peturr02@ru.is,
  gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/9439: filebuf::sputbackc ignores beginning-of-file
X-SW-Source: 2003-02/txt/msg00047.txt.bz2
List-Id: <gcc-prs.sourceware.org>

Synopsis: filebuf::sputbackc ignores beginning-of-file

Responsible-Changed-From-To: unassigned->paolo
Responsible-Changed-By: paolo
Responsible-Changed-When: Sun Feb  2 17:38:23 2003
Responsible-Changed-Why:
    Analyzed a bit.
State-Changed-From-To: open->feedback
State-Changed-By: paolo
State-Changed-When: Sun Feb  2 17:38:23 2003
State-Changed-Why:
    Hi. I don't think there is a bug here: I cannot find in the
    standard a specific prescription for the behaviour you
    expect (in particular in 27.5.2.4.4) Can you?
    Indeed, sputbackc calls, as expected, pbackfail, which in turns calls seekoff (fstream.tcc, line 218) (pay attention
    to the preceding comment which means that this specific situation was considered and _not_ supposed to lead to an
    obvious failure). The latter call then does _not_ fail and
    a put back buffer is created by _M_pback_create(), hosting
    the put back char, _exactly as happens_ when __testpb &&
    !__testeof && !__testeq, above. 
    I agree that a few widespread implementations behave
    differently in this case, but we are, I maintain, in the
    realm of implementation defined behaviour.
    
    Paolo.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9439