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

[Arthur O'Dwyer via Phabricator via libcxx-commits]

Quuxplusone added a comment.

@aaronpuchert wrote:

> Which kinds of errors would you be worried about? The sizeof division itself isn't so complicated that I'd be worried about it being wrong.

Well, the original PR had had a division-and-subtraction, and then was //updated// to just a division when the original math turned out to have been factually wrong. https://reviews.llvm.org/D114395?vs=389034&id=389624#toc This follows the "Less code = less bugs" principle: division+subtraction turned out to have been wronger than division, and I'm just saying that division in turn is potentially wronger than no-division (and cannot possibly be //righter// than no-division, since no-division is a factually correct upper bound by definition).

@mclow.lists writes:

> Consider a 32 bit system... `string_view(p, 3'000'000'000)` ... That works today.

Yes, and it will keep working after any of these proposed changes, right? We just need to maintain `string_view::max_size() > 3000000000`.
The interesting case for this PR is `u16string_view(p, 1'500'000'000)`... which is still satisfied by both the existing `size_t(-1)` and the proposed `size_t(-1) / sizeof(char16_t)`. So the question is just whether any libc++ user will be looking at `u16string_view::max_size()` and making decisions based on its value, and if so, what value will lead to them making better decisions — `size_t(-1)`, or `size_t(-1)`-divided-by-something.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114395