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_at_[hidden]>
wrote:

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