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.

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