On Mon, Feb 2, 2026 at 11:38 AM Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Monday, 2 February 2026 00:00:04 Pacific Standard Time FPE via
> Std-Proposals
> wrote:
> > 4. On Thiago Macieira's security concerns (embedded nulls): Great points
> –
> > these are real risks in untrusted input scenarios. However, going back to
> > string_view's original goals: it accelerates code by trusting input
> > (avoiding repeated strlen) and consolidating (ptr, len) into one object.
>
> I don't have a problem if one declares that modifying the string
> underneath
> the container and inserting a NUL or removing the one that terminates is
> unsupported. That's usually not a problem. Strings are easy to retain
> unmodified.
>
> What I have a problem with is trusting basic_string / basic_string_view's
> size() and requiring them to not have an embedded NUL. If cstring_view
> stores
> a size value, it must be obtained from strlen() on construction.
>

I agree that it's weird, but, wouldn't you agree that the currently
proposed behavior of cstring_view is consistent with the
standard-since-C++17 behavior of string_view?
    auto s = std::string("hello\0world", 11);
    auto sv = std::string_view(s); // gets 11 characters, not 5
    auto cv = std::cstring_view(s); // should get 11 characters, not 5,
right? for consistency?
    auto sv2 = std::string_view(std::cstring_view(s)); // should get 11
characters, not 5, right? for consistency?
That is, constructing from a std::string and constructing from a const
char* have always (since C++17) behaved weirdly differently. We can't get
rid of that weirdness, but we can at least be consistent with it. Being
weird *and* inconsistent would be worse, wouldn't it?

–Arthur