On Wed, Feb 4, 2026 at 11:16 AM Ell via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Wednesday, February 4th, 2026 at 3:07 AM, Thiago Macieira <thiago_at_[hidden]> wrote:
>
> >
> >
> > On Tuesday, 3 February 2026 13:00:18 Pacific Standard Time Ell wrote:
> >
> > > OTOH producers of null-terminated strings don't know how the string is
> > > going to be used, so it makes sense to return a string_view with the
> > > added information that it's null terminated (as in
> > > https://eel.is/c++draft/meta.reflection#meta.syn-3). This information is
> > > useful even in the presence of embedded nulls (at the very least, it
> > > allows you to safely strlen() the string). The name "cstring_view" might
> > > be misleading though, if the actual C-string might be different.
> >
> >
> > If I'm producing one, then "view" is the wrong type. It should be just
> > std::string with a promise of not containing an embedded NUL.
> >
>
> Bad word choice on my part. My point was that cstring_view makes more
> sense on the providing end than the receiving end. Some APIs provide
> existing strings without transfer of ownership or a copy. Obviously, if
> you return a new string then it's irrelevant.

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.