search for: bad_array_new_length

...has a compile-time limit for sizes of objects and types which is SIZE_MAX. For example, it compiles "char a[-1ul]; int main() {}" but complains about "char a[-1ul + 1ull]; int main() {}"; - `new` for more than PTRDIFF_MAX works fine when compiled by clang++ (but throws std::bad_array_new_length when compiled by g++). > On Fri, May 20, 2016 at 1:31 AM, John Regehr via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> It could be that 32-bit systems are disappearing so rapidly that nobody >> cares too much about this issue, Please note that there is a whole n...

I've come across this issue before and came to the following conclusion: - We are not obligated to support objects that large, C11 5.2.4.1/1 only requires that we support objects of size 65535! Their guidance for maximum object size is stated to be half of SIZE_MAX in C11 K.3.4/4 which is typically equivalent to PTRDIFF_MAX. - The expectation that PTRDIFF_MAX is more or less a proxy for the

It could be that 32-bit systems are disappearing so rapidly that nobody cares too much about this issue, but this blog post is still worth reading: http://trust-in-soft.com/objects-larger-than-ptrdiff_max-bytes/ John

...imit for sizes of objects and types which is > SIZE_MAX. For example, it compiles "char a[-1ul]; int main() {}" but > complains about "char a[-1ul + 1ull]; int main() {}"; > > - `new` for more than PTRDIFF_MAX works fine when compiled by clang++ (but > throws std::bad_array_new_length when compiled by g++). > > On Fri, May 20, 2016 at 1:31 AM, John Regehr via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >> It could be that 32-bit systems are disappearing so rapidly that nobody >>> cares too much about this issue, >>> >&gt...