--- Additional Comments From ralfixx at gmx dot de 2005-07-18 12:03 ---
Thanks. At this point in 3_4-branch go only very-very safe changes. Therefore,
before considering fixing in that branch too the problem (*), let's test the
new algorithm in mainline and 4_0-branch for a while.
--- Additional Comments From pcarlini at suse dot de 2005-07-18 12:28
---
I'm wondering why this problem does not break tons of code,
Just read the audit trail, about that. In particular my comment #3: portable C++
code using pipes has better being very very careful with short reads,
--- Additional Comments From ralfixx at gmx dot de 2005-07-18 15:01 ---
portable C++ code using pipes has better being very very
careful with short reads, because the current Standard is
way too vague in this area
I prefer C++ for the abstractions it allows. Having to code my I/O
--- Additional Comments From pcarlini at suse dot de 2005-07-18 15:56
---
Let's pronounce it [k#601;#712;p#650;t] then :-)
http://en.wiktionary.org/wiki/Kaput
Yes. My point was simply that in order to have the attention of the maintainers
you don't need to use exagerated expressions.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-18
18:32 ---
Subject: Bug 21286
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-07-18 18:32:00
Modified files:
libstdc++-v3 :
--- Additional Comments From amu at alum dot mit dot edu 2005-07-14 20:45
---
FWIW, the same broken optimization, and hence the same bug, also appears to have
materialized in the 3.4 branch somewhere between 3.4.2 and 3.4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21286
--- Additional Comments From pcarlini at suse dot de 2005-07-14 23:51
---
Thanks. At this point in 3_4-branch go only very-very safe changes. Therefore,
before considering fixing in that branch too the problem (*), let's test the
new algorithm in mainline and 4_0-branch for a while.
--- Additional Comments From ralfixx at gmx dot de 2005-05-01 17:44 ---
[EMAIL PROTECTED]:
A note for Ralf: It is incorrect to use cin.eof()
to watch for the end of a stream.
The correct flag to check is fail().
eof() is really meant for seeing if that's why op failed.
Yup.
--- Additional Comments From pcarlini at suse dot de 2005-05-01 18:12
---
You can find weekly snapshots both of mainline and 4_0 here:
ftp://gcc.gnu.org/pub/gcc/snapshots/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21286
--- Additional Comments From ralfixx at gmx dot de 2005-05-01 19:12 ---
ftp://gcc.gnu.org/pub/gcc/snapshots/
Just tried gcc-4.0-20050430: the problem is gone.
However, I could not reintroduce the problem by just reverting the patch for
fstream.cc (still works after I undo the patch),
--- Additional Comments From pcarlini at suse dot de 2005-05-01 19:28
---
OK, thanks. Maybe you cannot see the problem by just reverting the patch,
because at least part of the data remained in the cache: I found your procedure
very useful to expose the problem but very sensitive to
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-30
06:54 ---
Subject: Bug 21286
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-30 06:54:08
Modified files:
libstdc++-v3 : ChangeLog
--
What|Removed |Added
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21286
--- Additional Comments From ralfixx at gmx dot de 2005-04-30 14:16 ---
Paolo Carlini wrote:
I'd like to know your opinion, as a user: are you
noticing worthwhile performance improvements?
Would you consider very annoying trying to read again
(calling clear()), when pipes are used?
--- Additional Comments From ncm-nospam at cantrip dot org 2005-04-30
15:48 ---
A note for Ralf: It is incorrect to use cin.eof() to watch for the end
of a stream. The correct flag to check is fail(). eof() is really
meant for seeing if that's why op failed.
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-30
22:55 ---
Subject: Bug 21286
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-04-30 22:55:34
Modified files:
libstdc++-v3 :
--- Additional Comments From pcarlini at suse dot de 2005-04-30 22:57
---
Should now be fixed for 4.1.0 and 4.0.1. Ralf, if you get a chance to test a
4.0.1 snapshot...
--
What|Removed |Added
--- Additional Comments From ncm-nospam at cantrip dot org 2005-04-30
02:11 ---
Just to add... if sgetn() loops reading until it gets n bytes, but
underflow() accepts a pipe's short reads, then in_avail() will report
the size of the short read. Then, istream::read_some() will
--- Additional Comments From ncm-nospam at cantrip dot org 2005-04-30
03:49 ---
(In reply to comment #5)
... Thus, if you're writing structs, the reader will
see half a struct.
Sorry, that's will never see half a struct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21286
19 matches
Mail list logo
