https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 10 Apr 2018, msebor at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315 > > --- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> --- > (In reply to rguent...@suse.de from comment #4) > ... > > If you eventually expect a true result then please no - this should be > > undefined. > > The second test case in comment #4 is currently well-defined in C17 (by 6.5.9, > p6) and requires the function to return true if x and y are adjacent and i is > +/-1. (I'm not defending the requirement.) > > There is a proposal for C2X to make the result of the equality comparison > between a past-the-end pointer and another pointer unspecified instead > (N2219). > Would you prefer it to be undefined? (Making it undefined would be a rather > drastic departure from the historical requirement and likely objectionable to > the authors.) Yes, it should be undefined. GCC treats it as undefined at the moment because otherwise points-to analysis cannot be used to optimize pointer equality tests at all which would be a major showstopper. Also consider the following: int main() { int a, b = 0; int *p = &a+1; if (p == &b) *p = 1; return b; } is that now valid and required to return 1 if b appens to be adjacent to a? points-to says p points to a and thus cannot be used to modify b. And IIRC *(&a+1) isn't valid but if &a+1 == &b isn't undefined but is required to return true if they are adjacent what sense does it make to _not_ allow a pointer that is equal to &b to access b? > See http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2219.htm > (Scroll down to the Proposed Technical Corrigendum section at the end of the > paper to read the proposed changes.) It's not clear to me how "happens to immediately follow the first array object in the address space" not always contradicts "single provenance". &a+1 and &b have different provenance, no? Given GCC has leeway to pad declarations an implementation could choose to always pad variables by at least one byte and thus never making "happens to immediately follow the first array object in the address space" true? What's the intended use of that special case? Is it to make the access via p above valid? If not how is it useful to allow this kind of comparison? Users can always go via [u]intptr_t if they want to compare pointers of different "provenance" so why's it necessary to add an ability to do so without??? That just needessly complicates implementations IMHO. So that -f[no-]provenance stuff is bollocks IMHO, whoever invented it must be making sth up on a sheet of paper rather than addressing a real problem.
