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]> 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://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/span#L280>
> which will be enabled by *the new GCC -fhardened
> <https://www.phoronix.com/news/GCC-fhardened-Hardening-Option>*.
>
> * 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://github.com/isocpp/CppCoreGuidelines/issues/2067> 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.
>
>
>