I agree with Yehezkel that introducing address sanitizer as their guard is
important.
As they may get index out of bounds also using std::array or C-Style arrays
for example.

It is to be noted though, that address sanitizer is not a guaranteed guard,
and it will not always track out of bounds access, especially if capacity
is bigger than size, such as in this example
<https://compiler-explorer.com/z/bje35cnM5>:

    std::vector v = {1, 2, 3, 4, 5};
    v.push_back(6);
    v[8] = 7; // way beyond the end
              // missed by address sanitizer
              // as within capacity

Then the question should be: how come we are worried about our students and
less so about production code? (yes, testing, static code analysis, more
mature programmers etc. Yet the risks of out of bounds in production code,
if passed all safety nets, are of course much higher).

Bjarne says above:
> This fits with "profiles".
If I understand correctly, the idea is having a profile, for example for
"bounds-checking", that will bring in a somewhat different implementation
of std containers.
I believe this *should* be the solution! The sooner the better.

Amir


On Sat, Apr 29, 2023 at 11:23 PM Yehezkel Bernat via SG20 <
sg20_at_[hidden]> wrote:

> Today, with address sanitizer available on all main compilers and
> platforms, maybe this is a better tool to avoid memory access problems, not
> only for vectors?
>
> On Sat, Apr 29, 2023 at 10:32 PM Bjarne Stroustrup via SG20 <
> sg20_at_[hidden]> wrote:
>
>> "As close as possible, but no closer" as the old slogan has it.
>>
>> I once observed a freshman class in an excellent university. Over the
>> first couple of months more than 50% of the errors and even more of the
>> frustration was range errors. That is counter productive when trying to
>> teach programming. What I do is simply to get the errors reported promptly;
>> I turn UB into predictable, guaranteed, reported errors.
>>
>> If the standard offered a standard way to get range checking I would not
>> need hacks and I would be very happy. I would also recommend using it for
>> essential all development, so it would be "realistic."
>>
>> I guess that I should be happy that the standard rules are tight enough
>> to make my hack unnecessary.
>>
>>
>> On 4/29/2023 12:22 PM, Arthur O'Dwyer wrote:
>>
>> On Fri, Apr 28, 2023 at 9:46 PM Bjarne Stroustrup via Ext <
>> ext_at_[hidden]> wrote:
>>
>>> On 4/28/2023 8:55 PM, Ville Voutilainen wrote:
>>> > On Sat, 29 Apr 2023 at 03:40, Bjarne Stroustrup <bjarne_at_[hidden]>
>>> wrote:
>>> >>> Name lookup in C++ is complicated. :P
>>> >> Too complicated, and there is probably little we can do about it.
>>> > Right, but we would curse the language if it just allowed what you're
>>> > trying to do, when programming at scale(*). You have
>>> > an altruistic hack here, but it's still a hack.
>>>
>>> Agreed. What we need is a way of getting a portable guarantee that range
>>> checking is done for at least non-sneaky uses. This fits with "profiles".
>>>
>>
>> Isn't this roughly what the "GSL" project tried to do, several years
>> back? You'd write something like this:
>>
>> #include <gsl/vector.h>
>> int main() {
>> gsl::vector<int> v = {1,2,3};
>> v[4] = 2; // guaranteed abort (or exception, or whatever) here
>> }
>>
>> By using `gsl::vector` instead of `std::vector`, you'd be guaranteed to
>> get the behavior designed by the type author of `gsl::vector`, rather than
>> the "non-portable" (in this context) behavior of `std::vector`.
>> Bloomberg does something similar with `bsl::vector` instead of
>> `std::vector`. Now, I believe Bloomberg also has some machinery in place so
>> that you can write `std::vector` in the source code and get `bsl::vector`
>> under the hood; maybe someone who actually works with BSL will comment
>> here. They also of course have more resources to devote to library hacks
>> (e.g., "reimplement the entire STL from scratch so it does exactly what you
>> want, portable to all architectures you care about") than the average C++
>> trainer.
>>
>> When teaching C++, I advise teaching as close as possible to what the
>> students will be expected to do in real life; that means teaching them how
>> to use namespaces (especially the `std` namespace), how to #include
>> third-party libraries, and so on. This is Day-1 material in any beginner
>> class, AFAIC.
>>
>> > You're trying to take
>>> > everything that's in std, but sneak
>>> > in an alternative for vector, with slightly different semantics. The
>>> > language quite reasonably says "Whoa. If you
>>> > want that, establish a new namespace where you can decide what the
>>> > rules are, but no such sneaking under
>>> > my watch." [...]
>>> >
>>> > (*) I mean, imagine working on a large project, getting puzzled why
>>> > your vectors don't seem to work as expected,
>>> > and then finding out a sneak-in. You would curse. You would think that
>>> > the language shouldn't allow such
>>> > sneaking to occur.
>>>
>>
>> +100.
>> Corollary: When teaching C++, please don't teach this kind of hack,
>> either. Teach the actual, real-world way to deal with suboptimal libraries:
>> how to replace them with third-party dependencies, for example. Even if the
>> "third party" is just the instructor, and the dependency is just a single
>> file containing a basic reimplementation of `vector`.
>>
>> (Of course the instructor's reimplementation won't get picked up by
>> places that *the STL itself* uses `vector`, such as `seed_seq` and
>> `regex` and now `flat_set`. But again, that's going to be a problem in the
>> real world too, so you shouldn't train students to expect anything
>> unrealistic.)
>>
>> –Arthur
>>
>> --
>> SG20 mailing list
>> SG20_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg20
>>
> --
> SG20 mailing list
> SG20_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg20
>