I wouldn't be opposed to using a separate class. As for the comment WRT contiguous object sizes, I presume that could be left as an implementation detail, and the standard would just specify the semantics of the ::null_terminated() member?

On Wed, Dec 23, 2020, at 2:12 AM, Charles Milette via Std-Proposals wrote:
> 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
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>