[libcxx-dev] Why does std::allocator<T>::allocate throw std::length_error?

[Arthur O'Dwyer via libcxx-dev]

Hi Mikhail,

The following LWG issues are related. This seems to be a maze of twisty
little DRs and I'm not surprised libc++ isn't fully up to date.
https://cplusplus.github.io/LWG/issue3038
https://cplusplus.github.io/LWG/issue3190
https://cplusplus.github.io/LWG/issue3237
It also would not surprise me if that commit from 2016 was due to a simple
mixup of the common (but wrong in this case) "length_error" with the
uncommon (but IIUC correct) "bad_array_new_length".
However, also notice that that commit comes right after a patch series
implementing <experimental/memory_resource>, which *was* initially
specified to throw `length_error` from polymorphic_allocator<T>. LWG3237
fixed it to throw `bad_array_new_length` instead.

Anyway, I'm sure a patch would be welcomed... and then held up for a while
as Louis ponders the ABI-break implications. ;)

my $.02,
–Arthur


On Tue, Sep 28, 2021 at 9:21 AM Mikhail Maltsev via libcxx-dev <
libcxx-dev at lists.llvm.org> wrote:

> Hi,
>
> I noticed that for some reason in libc++ the function
> std::allocator<T>::allocate throws std::length_error when the allocation
> size
> exceeds the maximum size, wheres the C++ standard [allocator.members]
> requires
> to throw std::bad_alloc or std::bad_­array_­new_­length depending on the
> version
> of the standard.
>
> AFAICT this deviation from the standard was introduced intentionally in the
> following commit:
>
> commit 4524d6e73953322eafee72aba62ddebef8f7c5cd
> Author: Eric Fiselier <eric at efcs.ca>
> Date:   Sat May 7 03:12:24 2016 +0000
>
>     Change allocator<T>::allocate to throw length_error, not bad_alloc
>
>     llvm-svn: 268842
>
> What is the rationale behind this change?
>
> --
> Regards,
>   Mikhail Maltsev
> _______________________________________________
> libcxx-dev mailing list
> libcxx-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20210928/30d5bbf6/attachment.html>