On Tue, 14 Feb 2023 at 15:47, Chris Ryan <chrisr98008_at_[hidden]> 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 <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
>>>
>>