On Wed, Feb 4, 2026, at 16:53, Alejandro Colomar via Std-Proposals wrote:
> Hi,
>
> On 2026-02-04T22:41:29+0000, Ell via Std-Proposals wrote:
>> On Wednesday, February 4th, 2026 at 10:23 PM, Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>

>> > How would that internal string get embedded NUL characters?
>> >
>> > So I don't see how having the size be correct for `strlen` instead of
>> > respecting the size it is given is a problem here.
>>
>>
>> The problem isn't not respecting the size, it's deciding what the
>> implications of saying that cstring_view can't have embedded nulls are
>> in practice.
>
> Reminder: ISO C defines what is a string, and it disallows embedded
> nulls.

That isn't quite right - the string itself of course cannot have embedded nulls. However there often are bytes after the first null that are illegal to read (though I doubt the standard has this wording) but legal to write. Functions like strncpy will often write to those extra bytes and change the length of the string. It is important that c/zstring_view have a length that indicates how many bytes total can be written to, perhaps with a note that all bytes after the first null are unspecified.

Thus the open question is should c/zstring_view have two length functions, one that gives the length of the string, and one that gives the length of the underling buffer? I'm not a C programmer so I will just say we need to ask them what is useful.