Array indexes (by definition pointer math) that are unbounded (by owner objects) are unsafe.



On Tue, Feb 14, 2023 at 1:21 PM Edward Catmur <ecatmur@googlemail.com> wrote:


On Tue, 14 Feb 2023 at 14:57, Roberto R via Std-Proposals <std-proposals@lists.isocpp.org> 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

Roberto

 

 

From: Chris Ryan <chrisr98008@gmail.com>
Sent: Tuesday 14 February 2023 18:45
To: std-proposals@lists.isocpp.org
Cc: Jason McKesson <jmckesson@gmail.com>; roberto.romani@gmail.com
Subject: Re: [std-proposals] Safety checks at compile time

 

Please read: https://thenewstack.io/can-c-be-saved-bjarne-stroustrup-on-ensuring-memory-safety 

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 <std-proposals@lists.isocpp.org> wrote:

On Tue, Feb 14, 2023 at 12:02 PM Roberto R via Std-Proposals
<std-proposals@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals