Re: cstring_view

From: Marshall Clow (mclow.lists_at_[hidden])
Date: 2022-05-13 22:42:59

> On May 13, 2022, at 3:19 PM, Peter Dimov via Boost <boost_at_[hidden]> wrote:
> 
> Marshall Clow wrote:
>> On May 13, 2022, at 12:29 PM, Rainer Deyke via Boost
>> <boost_at_[hidden]> wrote:
>>> 
>>> On 13.05.22 20:39, Marshall Clow via Boost wrote:
>>>> On May 13, 2022, at 11:18 AM, Peter Dimov via Boost
>> <boost_at_[hidden]> wrote:
>>>>> In what scenarios will it not give you a null-terminated string?
>>>> 	char arr[6] = “hello";
>>>> 	cstring_view csv(arr);
>>>> 	assert(strlen(csv.data())) == 5);
>>>>        arr[5] = ‘!’;
>>>> 	assert(strlen(csv.data())) == 5);  // boom — Marshall PS. It
>>>> promises to give you a null-terminated string, but has no way to actually
>> guarantee that.
>>> 
>>> That's an issue with views in general, not just cstring_view.
>>> 
>>> std::string s = "hello";
>>> string_view sv = s;
>>> assert(sv.size() == 5);
>>> s += "!";
>>> assert(sv.size() == 5); // boom
>> 
>> I don’t see the problem here (and when I run the code I get no error - after
>> adding the missing ’std::').
>> 
>> No assertion failure; no undefined behavior (unlike the cstring_view example)
> 
> Only because "hello!" fits into the small buffer, I suspect. If `s` reallocates,
> `sv` would be left dangling.

Agreed.
But even if the string *did* reallocate, the call "assert(sv.size() == 5)” is still valid and well defined.

In the cstring_view example I wrote, there are no allocations (it’s a static buffer), and the call exhibits undefined behavior (as well as the assertion failure).

The whole point of cstring_view is “I have a sequence of N characters here, and I *swear* that then n+1st one is a NUL”

— Marshall

P. S. Std::string has the same behavior (which I really dislike), but at least it owns the storage, so it can enforce the presence of the NUL.