[libcxx-commits] [PATCH] D114395: [libc++] Fix the return value of max_size()

[Marshall Clow via Phabricator via libcxx-commits]

mclow.lists added a comment.

In D114395#3159050 <https://reviews.llvm.org/D114395#3159050>, @Quuxplusone wrote:

> FWIW, I'm still of the (very firmly held) opinion that this patch is unnecessary. `max_size()` is //always// just an upper bound on the size of the sequence. Lowering that upper bound
>
> - might introduce actual factual errors, e.g. if we get the bound wrong — whereas `size_t(-1)` can never be wrong
> - will never help any user of libc++, because a loose upper bound (as returned by `max_size`) is never useful and always useless
> - is no closer to being "accurate," because it is just as impossible //in practice// to have a `string_view` of length 9223372036854775807 or 4611686018427387903, as to have a `string_view` of length 18446744073709551615. These are all equally lying numbers, and there's no point pretending that any one of them is "more useful" or "more accurate" than any other.

Consider a 32 bit system. `numeric_limits<size_t>::max()` is 4294967295.
Now consider: `string_view(p, 3'000'000'000);` i.e, a string view that encompasses 3GB of RAM.

That works today.   I will concede that if you try to calculate `distance(begin(), end())` you get an overflow, but all the other calls work fine. You can enumerate the elements, you can resize, etc.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114395/new/

https://reviews.llvm.org/D114395