On Tue, 14 Feb 2023 at 14:57, Roberto R via Std-Proposals <
std-proposals_at_[hidden]> 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_at_[hidden]>
> *Sent:* Tuesday 14 February 2023 18:45
> *To:* std-proposals_at_[hidden]
> *Cc:* Jason McKesson <jmckesson_at_[hidden]>; roberto.romani_at_[hidden]
> *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_at_[hidden]> wrote:
>
> On Tue, Feb 14, 2023 at 12:02 PM Roberto R via Std-Proposals
> <std-proposals_at_[hidden]> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>