The core guidelines have been out there for years but typically ignored (if they even know about them)
I view this as something with more teeth.  Based on the profile policies, I see a pass/warn/fail scale.
This type of tool could/should be built into your CI system. You don't pass, you don't get checked-in.
It could also be a compiler option but the committee does not like suggesting command line options for compilers/tools.
I expect that if the compiler did this every time people would complain about compilation speed issues (real or not)

On Tue, Feb 14, 2023 at 3:04 PM Edward Catmur <> wrote:
On Tue, 14 Feb 2023 at 16:14, Chris Ryan <> wrote:
A .data() pointer to a single object can be safe(r) but to misuse that pointer can be unsafe.
Just because the language/library can do something does not mean that you should do that.

I may be missing something. Is this an (in principle) diagnosable consideration (as Roberto is proposing) or just general advice?

On Tue, Feb 14, 2023 at 2:05 PM Edward Catmur <> wrote:
On Tue, 14 Feb 2023 at 15:59, Chris Ryan <> wrote:
The owner object's operator[] (with bounds checking) returns the reference to the indexed object.
The owner object should not return a raw pointer to the head and allow somebody else to index off of it.

You appear to be talking about a fairly extensive change to the Standard. Note that various Library components added data() member functions relatively recently; are you saying that was a mistake?

And are you saying that any component that has API returning a raw pointer is to be considered unsafe? There wouldn't be much left of the Library if all such components were barred from use.

On Tue, Feb 14, 2023 at 1:51 PM Edward Catmur <> wrote:

On Tue, 14 Feb 2023 at 15:47, Chris Ryan <> wrote:
Array indexes (by definition pointer math) that are unbounded (by owner objects) are unsafe.

I don't follow. What owner object would bound that offset indirection? Note that the indirection occurs within the body of a Library member function.

On Tue, Feb 14, 2023 at 1:21 PM Edward Catmur <> wrote:

On Tue, 14 Feb 2023 at 14:57, Roberto R via Std-Proposals <> wrote:

Hi Chris


>From the below article:

“Specifically, it proposes “packaging several features into profiles” (with profiles defined later as “a collection of restrictions and requirements that defines a property to be enforced” by, for example, triggering an automatic analysis.) In this way the new changes for safety “should be visible such that the Safe code section can be named (possibly using profiles), and can mix with normal code.”


It looks like he wants to introduce some mechanism way more sophisticated than #pragmas to define section of the code with extra safety checks, this sounds good.


Looking what the code analyser and compiler are able to detect right now, I am little bit sceptical that without some hints from the developer they will be able to do something similar to what I have proposed.

Told this: the key words to_safe and to_unsafe of my proposal are needed only because in c++ it is possible to declare the function in a file and the implementation in another, otherwise the compiler should be able to detect by itself when a parameters and objects are going to become unsafe or safe.

You talk of "safe" and "unsafe" states of objects. Fine, for a simple unique_ptr, the only precondition on its API is whether the pointer is empty. But most Standard library components have API with more complex preconditions. Even a unique_ptr<T[]> has operator[] which has precondition i < n, where n is the size of the owned array. There's no way that 1 bit of information is enough to express the affine/dependent type system that you seem to be hinting at.

Have you considered whether this would be better expressed through contracts (i.e., under SG21)? `not empty()` could be a precondition, for example.

The keyword unsafe of my proposal means: “this object is unsafe”, in the majority of the cases, maybe all, the compiler should be able to detect it.  But unsafe also says: “this function is able to manage unsafe objects”, also Rust needed to introduce some mechanism to indicate that portions of the code are able to manage unsafe situations. Maybe the profiles will provide such mechanism.


Personally: I prefer checks defined by standard and made by the compiler than checks not standardized made by code analyser: if a compiler guaranty me that an object is safe, then I don’t need to put checks in the code to verify it.


Anyway happy that security is gaining more importance, this evening I have just read a post of Herb Sutter saying that has been created a the new sub group Safety and Security inside the ISO C++ committee.


@Jason sorry I was too quick to explain the #pragma mechanism: the idea is that with them you can limit which part of the code must have the safety checks and which not, therefore you wouldn’t need to rewrite the old code.

Microsoft, Google and NSA, are saying that C++ should be deprecated because the cyber security issues due to not memory safe code are costing millions. Their statements are too bold and simplify too much the world, but there is some true.


Best Regards




From: Chris Ryan <>
Sent: Tuesday 14 February 2023 18:45
Cc: Jason McKesson <>;
Subject: Re: [std-proposals] Safety checks at compile time


Please read: 

Bjarne gave us an introduction last week at the WG21 ISO C++ Standards meeting, in Issaquah on these safety profiles.  As per ISO policies the meeting was not recorded.  I am sure that he will give this talk again soon where he can present some of these ideas publicly.

These tools are not ready yet. The idea is a good start, but we can not tool ourselves out of this.  It does not remove any legacy compatibility.  It only checks that what you are doing now is safe(r).  Just because C++ has legacy compatibility does not imply that you should be using these older mechanisms.


On Tue, Feb 14, 2023 at 9:13 AM Jason McKesson via Std-Proposals <> wrote:

On Tue, Feb 14, 2023 at 12:02 PM Roberto R via Std-Proposals
<> wrote:
> Hi all
> I guess many of you have read articles about Microsoft, Google and NSA saying that it is better to stop to use C++ and use instead memory safe languages like Rust or Java.

No, I haven't heard about that. Though I'm not sure what it matters.

> Is it possible to make C++ a memory safe language?

Not without throwing away backwards compatibility and effectively
turning it into a different language. And since different languages
already exist, and this would force people to rewrite their code
anyway, I'm not sure why they would rewrite it in this new C++.
Std-Proposals mailing list

Std-Proposals mailing list