On Sun, 30 Apr 2023, Gabriel Dos Reis wrote:

> Ideally, students should be taught practices they can deploy in production setting.

Isn't it still common to have (at least) 2 builds using different options,
one for debugging, and one for production?

> While sanitizers and fuzzers have become accepted elements of the dev
> toolbox, they can't be deployed in production.

I think -D_GLIBCXX_ASSERTIONS (libstdc++) or -D_LIBCPP_ENABLE_ASSERTIONS
(libc++) can be, depending on the behavior you expect when an error
occurs.

> That is part of why it is critical that we have a standard mechanism

The name of the option currently differs by compiler, but then so do the
options to enable optimizations, warnings, etc.

> 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.

Vendors can already easily choose to configure libc++ with
LIBCXX_ENABLE_ASSERTIONS=ON so bound checking is on by default, like
Ubuntu defines _FORTIFY_SOURCE for C.

Sure, more consistency would be nice, but I think the main reason the
current situation is not satisfactory is that people don't use the
existing tools enough (often because they don't know or have
misconceptions about them). I am always wary of thinking that one more
tool, even if it is standard, will solve the problem of people not using
the tools (maybe it will, I have no idea).

-- 
Marc Glisse