[SG16-Unicode] SG16 approval for LEWG to review std::filesystem::path_view

Lyberta lyberta at lyberta.net
Wed Jul 3 21:40:00 CEST 2019


JeanHeyd Meneide:
>      Finally, I have one more... thing? It's not really a concern or a nit
> with the paper, just a bit of sadness: had we standardized a c_string_view
> of some form, we wouldn't need what will probably amount of "*Expects:
> *ptr[size]
> == 0 is true" on all the specifications on the constructors for the string
> view / charX + pointer overloads. I agree with the reasoning in the paper
> that there is rarely a case where users expect that to be the case, but
> it's not exactly impossible: I have received a lovely crop of bug reports
> from people seeing "std::string_view" overloads in my libraries and passing
> non-null-terminated strings into them, because that's what string_view
> promises. Whether or not your wording has an "expects" clause, it's not
> difficult or hard to imagine substring or other similar pointer + size
> manipulations to produce hell here.
> 
>       Then again, this is marked as the *path*_view type. Maybe that will
> be enough visual indication to the user they should think carefully and not
> just toss in random substrings. I certainly hope it is.

Since std::c_string_view would not own the string, how do you enforce
the null terminator because the user can mutate the buffer. Do you check
manually in every member function and assert?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
Url : http://www.open-std.org/pipermail/unicode/attachments/20190703/e4404fe7/attachment.bin 


More information about the Unicode mailing list