On Mon, May 1, 2023 at 3:01 AM Ville Voutilainen <
ville.voutilainen_at_[hidden]> wrote:

> On Sun, 30 Apr 2023 at 19:50, Andrew Tomazos via SG20
> <sg20_at_[hidden]> wrote:
> >
> > On Mon, May 1, 2023 at 2:15 AM Gabriel Dos Reis via Ext <
> ext_at_[hidden]> wrote:
> >>
> >> Ideally, students should be taught practices they can deploy in
> production setting. While sanitizers and fuzzers have become accepted
> elements of the dev toolbox, they can't be deployed in production. That is
> part of why it is critical that we have a standard mechanism for turning
> bound checking on - or better yet, have bound checking on by default and
> have mechanism to opt out, after profiling data have shown that's what is
> needed.
> >
> >
> > If/when we ship contracts, aren't we going to eventually add them to the
> standard library to check preconditions? and bounds-checking of the
> standard containers would be amongst them? Isn't turning contracts
> on-and-off exactly that standard mechanism to turn bounds checking
> on-and-off? Or are we talking about bound-checking at the lower
> builtin-array level?
>
> We are talking about students that will be taught this year and the
> next. The forthcoming contracts don't arrive in time for that.
>

Well then perhaps worth mentioning is that libstdc++ (at least) has
something like it today. This is std::vector::operator[] from libstdc++

    reference
    operator[](size_type __n)
    {
        __glibcxx_requires_subscript(__n);
        return *(this->_M_impl._M_start + __n);
    }

That __glibcxx_requires_subscript is like a C assert or something:

#ifndef _GLIBCXX_ASSERTIONS
# define __glibcxx_requires_subscript(_N)
#else
# define __glibcxx_requires_nonempty() __glibcxx_assert(!this->empty())
#endif

I'm not sure what the deal is with _GLIBCXX_ASSERTIONS and
__glibcxx_assert. Maybe jwakely would know.