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

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

Quuxplusone added inline comments.


================
Comment at: libcxx/include/string_view:334
     _LIBCPP_CONSTEXPR _LIBCPP_INLINE_VISIBILITY
-    size_type max_size() const _NOEXCEPT { return numeric_limits<size_type>::max(); }
+    size_type max_size() const _NOEXCEPT { return (numeric_limits<size_type>::max() - sizeof(*this)) / sizeof(value_type); }
 
----------------
aaronpuchert wrote:
> ldionne wrote:
> > mclow.lists wrote:
> > > Quuxplusone wrote:
> > > > (1) This seems unnecessarily fiddly; I don't really see anything wrong with the original.
> > > > (2) If we're going to do this, let's add a line break somewhere.
> > > > (3) Since `sv.size()` cannot physically return anything bigger than `PTRDIFF_MAX`, you probably want to use `ptrdiff_t` instead of `size_type` here... or maybe return `std::min(PTRDIFF_MAX, SIZE_MAX / sizeof(value_type))`? But again, this is needlessly fiddly and I see nothing wrong with just returning `SIZE_MAX` unconditionally. Literally nobody should ever be calling this method.
> > > > 
> > > > Do any of the other methods (e.g. the constructor) need to do something special to preserve the postcondition that `sv.size() <= sv.max_size()`? Before this change, the postcondition was vacuously true; now, it could conceivably be false, and maybe we need to check for that?
> > > My preference is `return (numeric_limits<size_type>::max() / sizeof(value_type)` since this is the max number of elements that a `string_view` can hold.
> > > 
> > > As for "literally nobody should be calling this method", I agree, with the exception of people writing test suites.
> > @Quuxplusone 
> > 
> > > (1) This seems unnecessarily fiddly; I don't really see anything wrong with the original.
> > 
> > If the character type is more than 1 byte long, the original is wrong.
> > 
> > @mclow.lists 
> > 
> > > My preference is return `(numeric_limits<size_type>::max() / sizeof(value_type)` since this is the max number of elements that a string_view can hold.
> > 
> > Yeah, I agree now. I was using `- sizeof(*this)` as some sort of poor man's way of removing the current `string_view`'s memory usage from the lot. However, this is entirely misguided -- re-reading the definition of `size_t`:
> > 
> > > `std::size_t` can store the maximum size of a theoretically possible object of any type (including array).
> > 
> > It doesn't have anything to do with the amount of memory usable on a system, it's only the maximum size of a single object. So yeah, I agree with your suggested definition.
> Isn't the point of `max_size` to return the maximal size so that address or memory consumption computation doesn't wrap around or overflow? So I think this change is correct. Surely `max_size` is more relevant in (owning) containers, but staying below should guarantee that `size() * sizeof(value_type)` doesn't overflow.
> 
> > Do any of the other methods (e.g. the constructor) need to do something special to preserve the postcondition that `sv.size() <= sv.max_size()`? Before this change, the postcondition was vacuously true; now, it could conceivably be false, and maybe we need to check for that?
> 
> One might add an assertion to the `basic_string_view(const _CharT*, size_type)` constructor, but it'll probably not find anything relevant.
> Do any of the other methods (e.g. the constructor) need to do something special to preserve the postcondition that `sv.size() <= sv.max_size()`?

Actually, I'm now reasonably confident that we should //not// assert or throw in this situation. It would even be worthwhile to add a unit test for this:
```
std::u16string_view sv(nullptr, size_t(-1));  // all preconditions are met; this must work
assert(sv.size() == size_t(-1));
```
It's true that accessing `sv[42]` would be UB at this point, but I think the Standard is 100% clear about the values that `sv`'s data members must have, after that constructor call.

However, I admit that this is irrelevant to what value we return for `max_size()`. It's OK for `sv.size() > sv.max_size()`. (`string_view` is different from `string` in this respect.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114395