Your message dated Sun, 23 Dec 2001 23:55:10 +0100
with message-id <[EMAIL PROTECTED]>
and subject line fixed in libstdc++2.10-glibc2.2-2.95.4-0.011223
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 17 Aug 2001 21:27:23 +0000
>From [EMAIL PROTECTED] Fri Aug 17 16:27:23 2001
Return-path: <[EMAIL PROTECTED]>
Received: from (mail.grossprofit.com) [12.151.134.178]
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 15Xr9D-0007wJ-00; Fri, 17 Aug 2001 16:27:19 -0500
Received: from profitlogic.com (dkatz.grossprofit.com [10.0.2.71]) by
mail.grossprofit.com with SMTP (Microsoft Exchange Internet Mail Service
Version 5.5.2653.13)
id NXWP17D3; Fri, 17 Aug 2001 17:26:06 -0400
Received: by profitlogic.com (sSMTP sendmail emulation); Fri, 17 Aug 2001
17:26:48 -0400
Sender: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: stringstream adds extra characters at the end
From: Daniel Katz <[EMAIL PROTECTED]>
Date: 17 Aug 2001 17:26:47 -0400
Message-ID: <[EMAIL PROTECTED]>
Lines: 95
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Delivered-To: [EMAIL PROTECTED]
Package: libstdc++2.10-dev
Version: 2.95.4-0.010810
When I upgraded from 2.95.4-0.010424, I found that code which used
stringstreams (or istringstreams or ostringstreams) broke. In
particular, I find that extra characters are added to the end of the
stream which complicate reading and writing. For example, I wrote the
following program:
------------------------------------------------------------------------
#include <sstream>
#include <iostream>
void
writer(int i)
{
static stringstream sstr;
// shove some stuff into the stringstream
sstr << "This is a fubar test. " << i;
sstr.unsetf(ios::skipws); // keep spaces
char c = 'Q'; // A throwaway that appears nowhere in the message
while (sstr >> c)
{
// print out each character and its hex representation. It
// should stop printing out when the end of the string is
// reached.
cout << c << "[" << hex << static_cast<int>(c) << "] ";
c = 'Q';
}
cout << "\n----------------" << endl ;
// reset the stringstream after it has gone out of good state
sstr.clear();
}
int
main()
{
for (int i = 0; i != 2; ++i)
{
writer(i);
}
return 0;
}
------------------------------------------------------------------------
which returns the following under 2.95.4-0.010810:
------------------------------------------------------------------------
T:54 h:68 i:69 s:73 :20 i:69 s:73 :20 a:61 :20 f:66 u:75 b:62 a:61 r:72 :20
t:74 e:65 s:73 t:74 .:2e :20 0:30 :0 :0 :0 :0 :0 :0 :0 :0
----------------
a:61 :20 f:66 u:75 b:62 a:61 r:72 :20 t:74 e:65 s:73 t:74 .:2e :20 1:31 :0
:0 :0 :0 :0 :0 :0 :0 :0 :0 :0 :0 :0 :0 :0 :0 :0
----------------
------------------------------------------------------------------------
while 2.95.4-0.010424 gives the correct (I think):
------------------------------------------------------------------------
T:54 h:68 i:69 s:73 :20 i:69 s:73 :20 a:61 :20 f:66 u:75 b:62 a:61 r:72 :20
t:74 e:65 s:73 t:74 .:2e :20 0:30
----------------
T:54 h:68 i:69 s:73 :20 i:69 s:73 :20 a:61 :20 f:66 u:75 b:62 a:61 r:72 :20
t:74 e:65 s:73 t:74 .:2e :20 1:31
----------------
------------------------------------------------------------------------
Note the trailing null characters in the 2.95.4-0.010810 version, and
notice also that the number of trailing nulls in the first half of the
output (8) exactly corresponds to the number of characters missing
from the string in the second half ("This is ").
Note that other tests we have done involving streaming in and out
numerical types have resulted in non-null characters being added at
the end. It is not only nulls which can be added, although only nulls
seem to be added in this particular case.
I am submitting this to Debian rather than to gcc since it is not
obvious to me whether this is a problem with the packaging or the
source. If the latter, would you please forward this report to the
gcc folks?
Thanks.
Dan Katz
---------------------------------------
Received: (at 109073-done) by bugs.debian.org; 23 Dec 2001 23:00:16 +0000
>From [EMAIL PROTECTED] Sun Dec 23 17:00:16 2001
Return-path: <[EMAIL PROTECTED]>
Received: from mail.cs.tu-berlin.de [130.149.17.13] (root)
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 16IHbM-0003vx-00; Sun, 23 Dec 2001 17:00:16 -0600
Received: from bolero.cs.tu-berlin.de ([EMAIL PROTECTED] [130.149.19.1])
by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id XAA11309;
Sun, 23 Dec 2001 23:55:11 +0100 (MET)
Received: (from [EMAIL PROTECTED])
by bolero.cs.tu-berlin.de (8.10.2+Sun/8.9.3) id fBNMtBo28770;
Sun, 23 Dec 2001 23:55:11 +0100 (MET)
From: Matthias Klose <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[EMAIL PROTECTED]>
Date: Sun, 23 Dec 2001 23:55:10 +0100
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: fixed in libstdc++2.10-glibc2.2-2.95.4-0.011223
X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
Delivered-To: [EMAIL PROTECTED]
gcc-2.95 (2.95.4.ds7-0.011223) unstable; urgency=medium
* Undo debian/patches/libstdc++-sstream.dpatch. Closes #109073, #115978.
Reopens #92524, #100571. The patch breaks debian/bugs/bug-115978.cc.
