A .data() pointer to a single object can be safe(r) but to misuse that
pointer can be unsafe.
Just because the language/library can do something does not mean that you
should do that.

On Tue, Feb 14, 2023 at 2:05 PM Edward Catmur <ecatmur_at_[hidden]>
wrote:

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