In B I did not mean the view to do the modification, but if the underlying storage changes, and the final NUL byte vanishes, we at least would know, how far we can read the string without UB.   Optionally we could demand that the last byte of the underlying storage stays a NUL byte as sentinel. Even if the string ends with NUL earlier.   That would remove some classes of UB and could be tested by the view, if it knows the size of the underlying storage.   -----Ursprüngliche Nachricht----- Von:Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 06.02.2026 21:26 Betreff:Re: [std-proposals] [Idea] Null-terminated string view (c_str_view / c_wstr_view) – a simpler alternative/complement to zstring_view Anlage:signature.asc An:std-proposals_at_[hidden]; CC:Thiago Macieira <thiago_at_[hidden]>; On Friday, 6 February 2026 08:19:37 Pacific Standard Time Sebastian Wittmeier via Std-Proposals wrote: > A) would be good for quick estimates, e.g. buffer space > > B) would be a safety-feature/limit for mutable C strings, if the NUL byte > gets overwritten I don't think a type with "view" in the name should allow mutating, at all. If you want to change the string, go back to the original buffer, which is probably a std::string, std::vector, or std::span. That one will provide you with the capacity. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org  Principal Engineer - Intel Data Center - Platform & Sys. Eng. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals