[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