>
> If you ban embedded NULs (or, phrased better, pretend they don't exist),
> then
> conversion from basic_string is fine.
>

Well, it's not entirely fine because std::string does allow embedded nulls,
so even when constructing std::cstring_view from std::string, you would
need to rescan the string contents, which seems silly.


> I don't buy the argument on conversion from existing C strings. Those
> usually
> don't have a length passed in the first place. And where an strlen() has
> been
> done, as I said in my reply, compilers are good at remembering the value.
>

I think it's plausible that you pass null-terminated string data and the
string length into opaque APIs which are implemented in some other TU, and
then compilers cannot optimize out redundant length checks. For example,
you may want to have an open_file(std::cstring_view) function. On some
operating systems, there may be an underlying API available that lets you
pass a size.


> > While one
> > could equally argue that the string view cannot guarantee that its null
> > terminator remains present, this can at least be asserted on debug builds
> > whenever the type is used. That is, whenever performing an operation, one
> > could assert that data[size()] is still null. Rescanning the entire
> string
> > is not realistic due to performance cost, so this invariant is not only
> > unenforceable, it also cannot be sanity-checked. That sounds like adding
> > more undiagnosable UB to the library; we don't need that.
>
> True.
>
> cstring_view might solve one class of problems, that of using
> non-terminated
> strings with APIs that require termination. A runtime check for the
> presence
> of the NUL helps; but as violations go, all it can do is abort the program
> early before further damage happens. It can't insert the NUL to let the
> program continue. And as I argued, the act of verifying can crash the
> application, so the failure to comply is UB.
>
> But I don't agree it suffices. The bigger problem I see is one of
> security. We
> have had security issues in the past where a NUL was passed and caused a
> string to be terminated short of where the caller expected it to. An
> example
> was in X.509 certificates issued with CN=bank.com%00.attacker.net: the
> percent-
> decoder operating in C++ calculated the full length of the string and
> placed a
> null terminator at the end, then this resulting decode was passed to a C
> API
> that stopped short.
>

>From a security standpoint, since std::cstring_view cannot guarantee that
it contains no embedded nulls (because it doesn't own and control its
data), you will always need to rescan the contents anyway. It's always
possible to maliciously craft a view that has embedded nulls, no matter
whether the standard permits them on paper or not.

I would find the arguments against embedded nulls convincing if they
revolved around proper invariants and hard guarantees, but that's not the
case. We either permit embedded nulls, or we permit embedded nulls and have
the standard PDF say that actually they're not okay (but no one can enforce
this realistically).