--- Comment #18 from paolo at gcc dot gnu dot org 2006-09-22 17:51 ---
Subject: Bug 29134
Author: paolo
Date: Fri Sep 22 17:51:01 2006
New Revision: 117148
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117148
Log:
2006-09-22 Paolo Carlini <[EMAIL PROTECTED]>
PR libst
--- Comment #17 from paolo at gcc dot gnu dot org 2006-09-21 10:34 ---
Subject: Bug 29134
Author: paolo
Date: Thu Sep 21 10:34:48 2006
New Revision: 117109
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117109
Log:
2006-09-21 Paolo Carlini <[EMAIL PROTECTED]>
PR libst
--- Comment #16 from pcarlini at suse dot de 2006-09-21 10:22 ---
(In reply to comment #15)
> Ok, seems sane enough. Just curious about the omission.
I'm going to adjust vstring first. Hopefully we can back port something to
basic_string, but really seems tricky (_S_max_size is static,
--- Comment #15 from bkoz at gcc dot gnu dot org 2006-09-21 10:21 ---
Ok, seems sane enough. Just curious about the omission.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134
--- Comment #14 from pcarlini at suse dot de 2006-09-21 09:13 ---
(In reply to comment #13)
> I like this solution a lot. NICE!
>
> It seems as if everything is now consistent except for std::string. Any
> thoughts on that one?
basic_string is delicate, from many different points of vi
--- Comment #13 from bkoz at gcc dot gnu dot org 2006-09-21 09:00 ---
I like this solution a lot. NICE!
It seems as if everything is now consistent except for std::string. Any
thoughts on that one?
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134
--- Comment #12 from pcarlini at suse dot de 2006-09-21 00:13 ---
Fixed for 4.2.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #11 from paolo at gcc dot gnu dot org 2006-09-21 00:12 ---
Subject: Bug 29134
Author: paolo
Date: Thu Sep 21 00:11:52 2006
New Revision: 117099
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117099
Log:
2006-09-20 Paolo Carlini <[EMAIL PROTECTED]>
PR libst
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #10 from pcarlini at suse dot de 2006-09-20 15:57 ---
(In reply to comment #9)
> I'm only wondering whether it would make sense to divide by sizeof(T) also in
> the other containers beside vector: the upper bound would be somewhat tighter
> and still correct, AFAICS. What do
--- Comment #9 from pcarlini at suse dot de 2006-09-20 15:00 ---
(In reply to comment #8)
> I agree also we can't do any better. On 64 bit systems it will be even harder
> to give anything sensible.
I'm only wondering whether it would make sense to divide by sizeof(T) also in
the other
--- Comment #8 from chris at bubblescope dot net 2006-09-20 11:10 ---
I agree also we can't do any better. On 64 bit systems it will be even harder
to give anything sensible.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134
--- Comment #7 from pcarlini at suse dot de 2006-09-20 10:45 ---
... and in fact, even for vector, I think we can only reasonably provide a
time-independent upper-bound, because in general we cannot know how much memory
each element' constructor is going to allocate... No, I'm more and m
--- Comment #6 from pcarlini at suse dot de 2006-09-20 10:22 ---
(In reply to comment #5)
> The reason I bought this up here, is because I thought (and I could be wrong,
> sorry) that the overflow was being caused by the fact that we allow the
> container size to get too big, and if we p
--- Comment #5 from chris at bubblescope dot net 2006-09-20 10:15 ---
The reason I bought this up here, is because I thought (and I could be wrong,
sorry) that the overflow was being caused by the fact that we allow the
container size to get too big, and if we pull max_size() down to a p
--- Comment #4 from pcarlini at suse dot de 2006-09-20 10:09 ---
(In reply to comment #3)
> Actually, I think deque could do with a better max_size.
It's not at all clear to me what we can possibly do in the general case of
discontiguous containers. Certainly, we don't want Segmentation
--- Comment #3 from chris at bubblescope dot net 2006-09-20 09:50 ---
Actually, I think deque could do with a better max_size.
Some tests:
vector v;
v.resize(v.max_size());
Throws bad_alloc.
deque v;
v.resize(v.max_size());
Bus errors.
This is on i686-apple-darwin8, 4.0.1 Apple's b
--- Comment #2 from pcarlini at suse dot de 2006-09-18 23:26 ---
(In reply to comment #1)
> And what does the C++ standard say about this case?
As far as I can see, the standard is very vague about the relationship between
the two max_size. About allocator::max_size, it says "the larges
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-18 23:12 ---
And what does the C++ standard say about this case?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134
19 matches
Mail list logo
