Date: Tue, 22 Sep 2020 22:19:34 -0400
Is it just me or does restrict seem like something that should be an
attribute more than a keyword? I have always felt like it was more of a
compiler or analyzer hint than a guarantee of certain behavior (of course
the same could be said of several keywords). C compatibility would be easy
with
#ifdef __cplusplus
#define restrict [[restrict]]
Just a thought
On Tue, Sep 22, 2020 at 6:02 PM Arthur O'Dwyer via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On Tue, Sep 22, 2020 at 5:57 PM Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
> wrote:
>
>> On Tue, Sep 22, 2020 at 5:41 PM Eric Lengyel via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> > Don't assume. It can't help, but (if you assume wrong) it might hurt.
>>>
>>>
>>>
>>> I was simply attempting to acknowledge the likelihood that you possess
>>> some familiarity with the subject material because many people seem to get
>>> offended if I explain it to them as if they didn’t already understand.
>>>
>>
>> Providing some use-cases and example code is a good idea.
>> You should provide some use-cases and example code.
>>
>> [...]
>>
>>> > That's not my definition of "type safety." To me, "type safety" means
>>> that the compiler should
>>>
>>> > (A) prevent having two `disjoint` pointers to the same storage, or at
>>> least make it easier to write static-analyzer passes to detect that issue
>>>
>>>
>>>
>>> That is “alias safety”, not “type safety”. Type safety means that you
>>> can’t accidently pass a pointer to a non-disjoint object to a function
>>> expecting a disjoint object. The restrict qualifier provides no such safety
>>> (and cannot be made to), but the disjoint qualifier does. Static analyzers
>>> are certainly able to detect cases in which a program creates two pointers
>>> to the same disjoint storage (which by itself is not dangerous) and uses
>>> them in a suspicious manner (perhaps by passing both as different
>>> parameters to the same function).
>>>
>>
>> Sure, and static analyzers are equally well able to detect cases in which
>> a program creates two pointers to the same *non-disjoint* storage and
>> passes both as different parameters to the same function.
>>
>
> Oops— fixed some typos in the following code.
> With the typos fixed, GCC indeed produces warnings on the two "should
> warn" lines.
> https://godbolt.org/z/GWvox8
>
>
>> void foo(int *restrict p, int *restrict q);
>> void test( int *restrict c, int *restrict d) {
>> int a, b;
>> foo(&a, &a); // static analyzer should warn
>> foo(&a, &b); // static analyzer should not warn
>>
> foo(c, c); // should warn
>> foo(c, d); // should not warn
>> }
>>
>>
>>
>
> --
>
> Std-Proposals mailing list
>
> Std-Proposals_at_[hidden]
>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
attribute more than a keyword? I have always felt like it was more of a
compiler or analyzer hint than a guarantee of certain behavior (of course
the same could be said of several keywords). C compatibility would be easy
with
#ifdef __cplusplus
#define restrict [[restrict]]
Just a thought
On Tue, Sep 22, 2020 at 6:02 PM Arthur O'Dwyer via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On Tue, Sep 22, 2020 at 5:57 PM Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
> wrote:
>
>> On Tue, Sep 22, 2020 at 5:41 PM Eric Lengyel via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> > Don't assume. It can't help, but (if you assume wrong) it might hurt.
>>>
>>>
>>>
>>> I was simply attempting to acknowledge the likelihood that you possess
>>> some familiarity with the subject material because many people seem to get
>>> offended if I explain it to them as if they didn’t already understand.
>>>
>>
>> Providing some use-cases and example code is a good idea.
>> You should provide some use-cases and example code.
>>
>> [...]
>>
>>> > That's not my definition of "type safety." To me, "type safety" means
>>> that the compiler should
>>>
>>> > (A) prevent having two `disjoint` pointers to the same storage, or at
>>> least make it easier to write static-analyzer passes to detect that issue
>>>
>>>
>>>
>>> That is “alias safety”, not “type safety”. Type safety means that you
>>> can’t accidently pass a pointer to a non-disjoint object to a function
>>> expecting a disjoint object. The restrict qualifier provides no such safety
>>> (and cannot be made to), but the disjoint qualifier does. Static analyzers
>>> are certainly able to detect cases in which a program creates two pointers
>>> to the same disjoint storage (which by itself is not dangerous) and uses
>>> them in a suspicious manner (perhaps by passing both as different
>>> parameters to the same function).
>>>
>>
>> Sure, and static analyzers are equally well able to detect cases in which
>> a program creates two pointers to the same *non-disjoint* storage and
>> passes both as different parameters to the same function.
>>
>
> Oops— fixed some typos in the following code.
> With the typos fixed, GCC indeed produces warnings on the two "should
> warn" lines.
> https://godbolt.org/z/GWvox8
>
>
>> void foo(int *restrict p, int *restrict q);
>> void test( int *restrict c, int *restrict d) {
>> int a, b;
>> foo(&a, &a); // static analyzer should warn
>> foo(&a, &b); // static analyzer should not warn
>>
> foo(c, c); // should warn
>> foo(c, d); // should not warn
>> }
>>
>>
>>
>
> --
>
> Std-Proposals mailing list
>
> Std-Proposals_at_[hidden]
>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
Received on 2020-09-22 21:19:48