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