The core guidelines have been out there for years but typically ignored (if
they even know about them)
I view this as something with more teeth. Based on the profile policies, I
see a pass/warn/fail scale.
This type of tool could/should be built into your CI system. You don't
pass, you don't get checked-in.
It could also be a compiler option but the committee does not like
suggesting command line options for compilers/tools.
I expect that if the compiler did this every time people would complain
about compilation speed issues (real or not)

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

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