C++ Logo

sg20

Advanced search

Re: [isocpp-ext] namespace composition

From: Gabriel Dos Reis <gdr_at_[hidden]>
Date: Sun, 30 Apr 2023 17:28:37 +0000
[Marc]
> Isn't it still common to have (at least) 2 builds using different options,
> one for debugging, and one for production?

Yes, it is common. But, we are talking about bound checking and production setting, specifically.
Is the suggestion that bound checking is only for debugging purposes?

> [...] 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).

Have we gotten ourselves into a self-fulfilling prophecy universe?

-- Gaby

-----Original Message-----
From: Ext <ext-bounces_at_[hidden]> On Behalf Of Marc Glisse via Ext
Sent: Sunday, April 30, 2023 10:22 AM
To: Gabriel Dos Reis <gdr_at_[hidden]>
Cc: Marc Glisse <marc.glisse_at_[hidden]>; sg20_at_[hidden]; Ville Voutilainen via Ext <ext_at_[hidden]>
Subject: Re: [isocpp-ext] [SG20] namespace composition

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
_______________________________________________
Ext mailing list
Ext_at_[hidden]
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
Link to this post: http://lists.isocpp.org/ext/2023/04/21178.php

Received on 2023-04-30 17:28:46