Date: Wed, 10 Apr 2019 23:40:37 +0200
On 09/04/2019 10.36, Peter Sewell wrote:
>>> N2363 C provenance semantics: examples.
>>> Peter Sewell, Kayvan Memarian, Victor B. F. Gomes, Jens Gustedt, Martin
>>> Uecker.
>>> This explains the proposal and its design choices with discussion of a
>>> series of examples.
>>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2363.pdf
>>
>> It seems to me that most of the introductory examples have clear
>> answers in current C++. In particular:
>>
>> — If one pointer represents the address of a complete object, and another
>> pointer represents the address
>> one past the last element of a different complete object, the result of
>> the comparison is unspecified.
>>
>> The proposal in N2362 seems to make such a comparison yield "true".
>>
>> I actually like our current rule: never ever compare / subtract pointers
>> to different complete objects. If you must compare, use std::less.
>
> This is only a corner of the provenance proposal, but also important.
>
> C distinguishes equality (==, !=) and relational (<, <=, >, >=) comparison.
>
> Inter-object equality comparison has to be supported,
"Supported" in the sense of "getting a well-defined, stable answer", I presume.
Why do you need that?
> though there's some
> debate about what the semantics should be in the one-past case -
> whether the result should be allowed to be provenance-sensitive or not.
>
> Inter-object relational comparison is not allowed in ISO C. Perhaps that's
> also debatable, as real code seems to rely on it, but it's not the main
> subject of the provenance proposal - probably best not to go into it right now.
It seems odd to desire support for equality comparisons, but not relational ones.
Jens
>>> N2363 C provenance semantics: examples.
>>> Peter Sewell, Kayvan Memarian, Victor B. F. Gomes, Jens Gustedt, Martin
>>> Uecker.
>>> This explains the proposal and its design choices with discussion of a
>>> series of examples.
>>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2363.pdf
>>
>> It seems to me that most of the introductory examples have clear
>> answers in current C++. In particular:
>>
>> — If one pointer represents the address of a complete object, and another
>> pointer represents the address
>> one past the last element of a different complete object, the result of
>> the comparison is unspecified.
>>
>> The proposal in N2362 seems to make such a comparison yield "true".
>>
>> I actually like our current rule: never ever compare / subtract pointers
>> to different complete objects. If you must compare, use std::less.
>
> This is only a corner of the provenance proposal, but also important.
>
> C distinguishes equality (==, !=) and relational (<, <=, >, >=) comparison.
>
> Inter-object equality comparison has to be supported,
"Supported" in the sense of "getting a well-defined, stable answer", I presume.
Why do you need that?
> though there's some
> debate about what the semantics should be in the one-past case -
> whether the result should be allowed to be provenance-sensitive or not.
>
> Inter-object relational comparison is not allowed in ISO C. Perhaps that's
> also debatable, as real code seems to rely on it, but it's not the main
> subject of the provenance proposal - probably best not to go into it right now.
It seems odd to desire support for equality comparisons, but not relational ones.
Jens
Received on 2019-04-10 23:40:42