--- Comment #8 from pcarlini at suse dot de 2006-09-25 10:07 ---
Fixed for 4.1.2.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
--- Comment #7 from paolo at gcc dot gnu dot org 2006-09-25 10:05 ---
Subject: Bug 29179
Author: paolo
Date: Mon Sep 25 10:05:43 2006
New Revision: 117194
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117194
Log:
2006-09-25 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #6 from paolo at gcc dot gnu dot org 2006-09-25 10:05 ---
Subject: Bug 29179
Author: paolo
Date: Mon Sep 25 10:05:27 2006
New Revision: 117193
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117193
Log:
2006-09-25 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29179
--- Comment #5 from pcarlini at suse dot de 2006-09-22 14:48 ---
(In reply to comment #4)
> ok, perhaps this is not really a bug, however segfault is not very user
> friendly. could ASSERT solve it?
No, we don't have asserts anywhere, for various reasons. Really, the
documentation must
--- Comment #4 from random at adriver dot ru 2006-09-22 14:40 ---
(In reply to comment #3)
> No, for the simple reason that the allocator does not work is __block_count
> turns out to be zero. The problem with your PR is that you are doing sort of
> syntactical analysis of the code witho
--- Comment #3 from pcarlini at suse dot de 2006-09-22 13:42 ---
(In reply to comment #2)
> would it not be easier to do a post increment and not have a problem with
> people never reading documentation? especially considering that it's so easy
> to
> fix?
No, for the simple reason tha
--- Comment #2 from random at adriver dot ru 2006-09-22 13:32 ---
(In reply to comment #1)
> The first "bug" simply doesn't exist given the comment at the beginning of
> __pool_base
In the beginning of __pool_base we see:
// Using short int as type for the binmap implies we are never
--- Comment #1 from pcarlini at suse dot de 2006-09-22 11:19 ---
The first "bug" simply doesn't exist given the comment at the beginning of
__pool_base. The second one is at most a documentation issue: _M_chunk_size
shall be always much bigger than _M_max_bytes, thus __block_count always
