On Sun, 30 Apr 2023 at 19:50, Andrew Tomazos via SG20
<sg20@lists.isocpp.org> wrote:
>
> On Mon, May 1, 2023 at 2:15 AM Gabriel Dos Reis via Ext <ext@lists.isocpp.org> 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())