On Wednesday, February 4th, 2026 at 10:23 PM, Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> wrote:

>
>
> OK, so there's this API that has a NUL-terminated string inside some
> object or system. And you call a function which retrieves a
> `cstring_view` of that internal string. So...
>
> How would that internal string get embedded NUL characters?
>
> I mean, if the API expects to work with NUL-terminated strings, then
> it probably is going to break if you give it a string with embedded
> NULs. Or at the very least, it will internally truncate the string
> to the first NUL character, since it is internally storing a string
> that is required to be NUL-terminated.
>
> Put simply, if you're dealing with a NUL-terminated string-based
> interface, then the string view you get back should respect that
> behavior. This API shouldn't have a problem with returning a
> `cstring_view` that truncates the string's length to the first NUL
> character, since that is precisely what it did internally when storing
> that string.
>
> 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. I don't think that doing a strlen everywhere is the answer
(or rather, I think that'll make cstring_view pretty useless).

You deal with it the same way you deal with std::string allowing
embedded nulls. You validate untrusted input, and then you probably
assume there are none. And if your string does have unexpected embedded
nulls then you already have a problem, truncating is just papering over
it.