--- Comment #8 from pcarlini at suse dot de 2007-02-13 00:26 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from paolo at gcc dot gnu dot org 2007-02-13 00:25 ---
Subject: Bug 21172
Author: paolo
Date: Tue Feb 13 00:25:30 2007
New Revision: 121875
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121875
Log:
2007-02-12 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #6 from pcarlini at suse dot de 2006-10-18 11:37 ---
A straightforward approach to the problem uses the unsigned type associated
with _Distance (via __gnu_cxx::__add_unsigned) to avoid the risk of overflows
in __adjust_heap completely. I'm currently looking into the cleanest
--- Comment #5 from pcarlini at suse dot de 2006-04-17 18:35 ---
Working on a fix.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned a
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-04-
--- Additional Comments From pcarlini at suse dot de 2005-04-28 00:08
---
Ok, let's reopen the PR as "enhancement": actually, it's easy to produce a
testcase that leads to __secondChild growing beyond __len and the latter
can be equal to the biggest representable _Distance.
--
--- Additional Comments From pcarlini at suse dot de 2005-04-27 19:26
---
Please, either provide an analysis that the problem really happens, *given the
specific algorithm*, or provide a testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21172
--- Additional Comments From pete_a90 at yahoo dot com 2005-04-27 19:09
---
I know there are no practical risks to this (heap isn't that popular and it's
practically impossible to allocate an array that large) but it won't work if
the user made a custom iterator with unsigned char as t
--- Additional Comments From pcarlini at suse dot de 2005-04-26 15:21
---
Actually, all the callers of __adjust_heap either pass a null second argument,
or a "small" second argument (case of make_heap). Thus, no real risks. Notice
that the function is an internal detail (double underscor
