libstdc++/8230: Buggy allocator behaviour

[Benjamin Kosnik]

>20.4.1.1 allocator members
>
>2/
>  pointer allocator(size_type n, allocator<void>::const_pointer = 0);
>
>7/
>  Throws: bad_alloc if the storage cannot be obtained

Got it, thanks for the clarification.

>int main()
>{
>   try {
>      std::allocator<int> alloc;
>      const std::allocator<int>::size_type n = alloc.max_size();
>      int* p = alloc.allocate(n + 1);
>      p[n] = 2002;
>      std::cout << p[n] << std::endl;
>   } catch(const std::bad_alloc& e) {
>      std::cerr << e.what() << std::endl;
>   }
>}
>This coredumps on my machine using current source.  The problem here is
>that std::allocator<> is not checking the bounds as required and it is
>lying.

Correct, with the pool allocators. If you add GLIBCPP_FORCE_NEW
everything is ok.

See attached patch for a way to fix this with the pool allocators.
>
>I'm also nervous about:
>
>   std::vector<int> v;
>   v.resize(v.max_size());
>
>   v[v.max_size() - 1] = 2002;
>
>I didn't test it with your patch.

My patch is only for reserve, as it's expected to throw length_error.
I believe it's still correct, regardless of resolving this issue.
For resize, the above issue comes into play.

On a completely unrelated note, what's up with std::vector and all the gooey 
allocator typedefs? Ick.

The allocator_type typedef is always allocator, as far as I can tell.
And _Alloc_type (should be __underlying_allocator or whatever) seems
superfluous. Instead of typedefing the base type all the time, with g++
one can just use the name of the template proper. There's got to be a
cleaner way to do a lot of this. Matt?

best,
benjamin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: p.20021114-1
Type: application/octet-stream
Size: 1699 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20021114/a396b34e/attachment.obj>