--- Comment #7 from Martin Sebor <msebor at gcc dot> ---
I asked Peter about that yesterday.  The access to *p in your example is still
meant to be undefined even under the proposed provenance rules.  Here's his
response:  It's not yet entirely
clear to me how to derive this answer from the proposed wording but if it can't
be it's presumably just a bug that will be fixed.

I think the intent of the "happens to immediately follow the first array 
object in the address space" was to allow implementations to return true for
the (&a + i == &b) kind of equalities and the text just came out wrong (as a
requirement rather than a permission).  The text was added in C99 but I haven't
yet been able to find the paper that added it.

The implications of the "immediately follows the first array" sentence for
equality having to return true would be at odds with the "single provenance"
and so the result of the equality is only specified with -fno-provenance
(otherwise it's unspecified).

Regarding your suggestion for the equality being undefined, since it's
well-defined in C and  explicitly unspecified in C++, changing it to undefined
in C would introduce an incompatibility with C++.  That would go against WG14's
goal (part of C2X charter) to align more closely with C++.  To make it pass in
WG14, C++ would most likely have to agree to change first.  But I'll bring it
up during the meeting.

The rationale for the-f[no-]provenance option is discussed in N2119.  It sounds
like the authors think it disabling the provenance rules might make for more
intuitive behavior and help avoid bugs.  I'll also bring it at the meeting.

Reply via email to