Date: Fri, 13 Oct 2023 20:27:20 +0000
This reminds me of a potential issue I thought of when converting my codebase to use more string_view.
The issues is that, while conversion from a temporary to a string_view parameter is great, if you return a string_view, you open yourself up to dangerous user-after-frees if you suddenly decide to return "string" instead (which can become necessary as suddenly I no longer have a persistent representation of the data I want to return), as code like:
string_view x = giveMeText();
becomes incorrect.
Obviously removing the implicit conversion from string && to string_view would make all the interfaces that take as string_view argument much harder to use.
Arguably using "auto" prevents this specific bug, but I really prefer avoiding "auto".
A facility to allow constructing a temporary from a temporary, but not constructing something longer-lived, would be nice.
________________________________________
From: SG23 <sg23-bounces_at_[hidden]> on behalf of Tom Honermann via SG23 <sg23_at_[hidden]>
Sent: Friday, October 13, 2023 1:09 PM
To: sg23_at_[hidden]; C++ Library Evolution Working Group
Cc: Tom Honermann; SG16; Herb Sutter
Subject: Re: [isocpp-sg23] [isocpp-lib-ext] Span (et al.) for better bounds safety in the standard library
On 10/13/23 1:46 PM, Jonathan Wakely via SG23 wrote:
On Fri, 13 Oct 2023, 18:09 Herb Sutter via Lib-Ext, <lib-ext_at_[hidden]<mailto:lib-ext_at_[hidden]>> wrote:
Bounds safety is important, and our standard library APIs could use our own bounds-safe types more:
* C++20 has std::span. [Party Popper Emoji (U+1F389)]
* We are seeing more “bounds-checked std::span” modes: The C++ Core Guidelines Support Library (GSL) gsl::span, and GCC std::span (and other indexed access) checking<https://urldefense.com/v3/__https://github.com/gcc-mirror/gcc/blob/master/libstdc*2B*2B-v3/include/std/span*L280__;JSUj!!A4F2R9G_pg!c1kW4x8_Os2Dmn3bidi9i5I0w8m6PxYzphyegF26Z_CzeMpM9IUVHKonPuWx7k4-g9fK6oj5LM--f2My$> which will be enabled by the new GCC -fhardened<https://urldefense.com/v3/__https://www.phoronix.com/news/GCC-fhardened-Hardening-Option__;!!A4F2R9G_pg!c1kW4x8_Os2Dmn3bidi9i5I0w8m6PxYzphyegF26Z_CzeMpM9IUVHKonPuWx7k4-g9fK6oj5LHNoP71D$>.
* We are seeing user demand for std::span upgrades to standard library interfaces that currently use less-safe (raw-pointer, length) pairs: For example, here is a C++ Core Guidelines Issue<https://urldefense.com/v3/__https://github.com/isocpp/CppCoreGuidelines/issues/2067__;!!A4F2R9G_pg!c1kW4x8_Os2Dmn3bidi9i5I0w8m6PxYzphyegF26Z_CzeMpM9IUVHKonPuWx7k4-g9fK6oj5LLbatAG9$> that asks the non-standard GSL to add more span APIs for standard functionality (in that case, to make up for basic_istream::read taking the error-prone (charT*, length), which really should be considered in the standard itself (e.g., shouldn’t basic_istream::read at least have an overload that takes std::span<charT>? – similarly, what about s[n]printf?).
* We look forward to adding contracts to the language, but those are complementary: Bounds-safe vocabulary types like std::span can cover cases preconditions can’t, and vice versa.
Call to action: Are there any folks interested in writing on a paper to survey how/where to apply std::span (or other bounds-checkable ranges/views) broadly across the standard library to augment (even if we can’t replace) APIs that currently take raw pointers and lengths?
I’m sure there would be strong support for this direction, so your time would be well spent. The heavy lift is for someone(s) to do the analysis and write the paper. Hence this request for that… any takers please?
I think we could collaborate here, with volunteers taking one of more subclauses to review. The combined analysis could be pulled together into a single paper, or we could do a paper per clause, as we did for the "mandating" papers.
If our wiki was safe for concurrent editing we could use that to gather the work, but maybe a Google doc would be better.
I agree.
Given that a large chunk of the problematic interfaces relate to text, SG16 seems like a good place to start asking for suggestions; copying the SG16 mailing list.
I like Jonathan's suggestion of using a Google Doc to crowd source suggestions.
Tom.
I would be very willing to review some library clauses but can't commit to the whole library.
The issues is that, while conversion from a temporary to a string_view parameter is great, if you return a string_view, you open yourself up to dangerous user-after-frees if you suddenly decide to return "string" instead (which can become necessary as suddenly I no longer have a persistent representation of the data I want to return), as code like:
string_view x = giveMeText();
becomes incorrect.
Obviously removing the implicit conversion from string && to string_view would make all the interfaces that take as string_view argument much harder to use.
Arguably using "auto" prevents this specific bug, but I really prefer avoiding "auto".
A facility to allow constructing a temporary from a temporary, but not constructing something longer-lived, would be nice.
________________________________________
From: SG23 <sg23-bounces_at_[hidden]> on behalf of Tom Honermann via SG23 <sg23_at_[hidden]>
Sent: Friday, October 13, 2023 1:09 PM
To: sg23_at_[hidden]; C++ Library Evolution Working Group
Cc: Tom Honermann; SG16; Herb Sutter
Subject: Re: [isocpp-sg23] [isocpp-lib-ext] Span (et al.) for better bounds safety in the standard library
On 10/13/23 1:46 PM, Jonathan Wakely via SG23 wrote:
On Fri, 13 Oct 2023, 18:09 Herb Sutter via Lib-Ext, <lib-ext_at_[hidden]<mailto:lib-ext_at_[hidden]>> wrote:
Bounds safety is important, and our standard library APIs could use our own bounds-safe types more:
* C++20 has std::span. [Party Popper Emoji (U+1F389)]
* We are seeing more “bounds-checked std::span” modes: The C++ Core Guidelines Support Library (GSL) gsl::span, and GCC std::span (and other indexed access) checking<https://urldefense.com/v3/__https://github.com/gcc-mirror/gcc/blob/master/libstdc*2B*2B-v3/include/std/span*L280__;JSUj!!A4F2R9G_pg!c1kW4x8_Os2Dmn3bidi9i5I0w8m6PxYzphyegF26Z_CzeMpM9IUVHKonPuWx7k4-g9fK6oj5LM--f2My$> which will be enabled by the new GCC -fhardened<https://urldefense.com/v3/__https://www.phoronix.com/news/GCC-fhardened-Hardening-Option__;!!A4F2R9G_pg!c1kW4x8_Os2Dmn3bidi9i5I0w8m6PxYzphyegF26Z_CzeMpM9IUVHKonPuWx7k4-g9fK6oj5LHNoP71D$>.
* We are seeing user demand for std::span upgrades to standard library interfaces that currently use less-safe (raw-pointer, length) pairs: For example, here is a C++ Core Guidelines Issue<https://urldefense.com/v3/__https://github.com/isocpp/CppCoreGuidelines/issues/2067__;!!A4F2R9G_pg!c1kW4x8_Os2Dmn3bidi9i5I0w8m6PxYzphyegF26Z_CzeMpM9IUVHKonPuWx7k4-g9fK6oj5LLbatAG9$> that asks the non-standard GSL to add more span APIs for standard functionality (in that case, to make up for basic_istream::read taking the error-prone (charT*, length), which really should be considered in the standard itself (e.g., shouldn’t basic_istream::read at least have an overload that takes std::span<charT>? – similarly, what about s[n]printf?).
* We look forward to adding contracts to the language, but those are complementary: Bounds-safe vocabulary types like std::span can cover cases preconditions can’t, and vice versa.
Call to action: Are there any folks interested in writing on a paper to survey how/where to apply std::span (or other bounds-checkable ranges/views) broadly across the standard library to augment (even if we can’t replace) APIs that currently take raw pointers and lengths?
I’m sure there would be strong support for this direction, so your time would be well spent. The heavy lift is for someone(s) to do the analysis and write the paper. Hence this request for that… any takers please?
I think we could collaborate here, with volunteers taking one of more subclauses to review. The combined analysis could be pulled together into a single paper, or we could do a paper per clause, as we did for the "mandating" papers.
If our wiki was safe for concurrent editing we could use that to gather the work, but maybe a Google doc would be better.
I agree.
Given that a large chunk of the problematic interfaces relate to text, SG16 seems like a good place to start asking for suggestions; copying the SG16 mailing list.
I like Jonathan's suggestion of using a Google Doc to crowd source suggestions.
Tom.
I would be very willing to review some library clauses but can't commit to the whole library.
Received on 2023-10-13 20:27:32