I have my own class for that already in my codebase. Basically just
inherited from std::string_view and = delete'd the members and constructors
which would violate that assumption. I would not oppose adding a
cstring_view to the standard.

On Tue., Dec. 22, 2020, 20:13 Thiago Macieira via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On Tuesday, 22 December 2020 21:33:35 -03 Tom Mason via Std-Proposals
> wrote:
> > The problem is that there is no way to know if a given string_view is
> null
> > terminated. My proposal is to add a method bool null_terminated() to
> > string_view. When a string_view is constructed, the caller can tell the
> > implementation that the pointer it is providing is null terminated. The
> > conversion from std::string to std::string_view would set this flag.
>
> This is an ABI-changing proposal. Please provide strong enough motivation
> to
> warrant it.
>
> Given the cost, it might be worth to have a separate class to indicate
> zero-
> terminated string views.
>
> > At the point where you need a null-terminated string, you can check the
> > null_terminated() member before proceeding, and handle it accordingly. I
> > have a proof of concept implementation here:
> > https://gist.github.com/wheybags/3c06795d251f004e007d47b3a5d823a7. This
> PoC
> > stores the "null terminated" flag in the highest bit of the length field,
> > so the memory footprint is unchanged. On a 64 bit machine this is no loss
> > really, as storing exabytes of data in one std::string is not reasonable.
> > On machines with small word sizes the null_terminated() member just
> returns
> > false. Of course, you could also just use a separate flag boolean.
>
> Reasonableness is not the point, it's disallowed by the standard actually
> on
> those machines. The maximum size of any contiguous object on modern
> architectures is PTRDIFF_MAX-1, which is less than half SIZE_MAX. So, for
> those, there's one bit free in the size field, even on 32-bit platforms.
> But
> this consideration is not valid for the standard, which can't make that
> same
> assumption.
>
> > I hope this is not a duplicate posting, and that this writeup is
> acceptable.
> > I did try searching both here and the old google groups list, and I
> didn't
> > find anything that looked like this. Please let me know what you think.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel DPG Cloud Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>