On Tue, 14 Feb 2023 at 16:14, Chris Ryan <chrisr98008_at_[hidden]> wrote:

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

I may be missing something. Is this an (in principle) diagnosable
consideration (as Roberto is proposing) or just general advice?

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