https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89157
Bug ID: 89157 Summary: Pointers comparison do not correspond to the standard Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: SztfG at yandex dot ru Target Milestone: --- Target: x86_64-linux-gnu Testcase: #include <stdio.h> #include <stdlib.h> #include <inttypes.h> int main(void) { char a[8], b[8]; char *a_ptr = a+8; char *b_ptr = b; printf("a_ptr = %p, b_ptr = %p\n", a_ptr, b_ptr); if (a_ptr != b_ptr) { printf("a_ptr != b_ptr\n"); } else { printf("a_ptr == b_ptr\n"); } if ((uintptr_t)a_ptr != (uintptr_t)b_ptr) { printf("(uintptr_t)a_ptr != (uintptr_t)b_ptr\n"); } else { printf("(uintptr_t)a_ptr == (uintptr_t)b_ptr\n"); } return EXIT_SUCCESS; } Checked with option gcc test.c -std=c18 -Wall -Wextra -O2 Output: a_ptr = 0x7ffc0a1dea38, b_ptr = 0x7ffc0a1dea38 a_ptr != b_ptr (uintptr_t)a_ptr == (uintptr_t)b_ptr I think this is wrong. According to latest available C18 draft: https://web.archive.org/web/20181230041359if_/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf#subsection.6.5.9 > Two pointers compare equal if and only if both are null pointers, both are > pointers to the same object(including a pointer to an object and a subobject > at its beginning) or function, both are pointers to one past the last element > of the same array object, or one is a pointer to one past the end of one > array object and the other is a pointer to the start of a different array > object that happens to immediately follow the first array object in the > address space. .111) > 111)Two objects may be adjacent in memory because they are adjacent elements > of a larger array or adjacent members of a structure with no padding between > them, or because the implementation chose to place them so, even though they > are unrelated. If prior invalid pointer operations (such as accesses outside > array bounds) produced undefined behavior, subsequent comparisons also > produce undefined behavior. Here we have the case when "one is a pointer to one past the end of one array object and the other is a pointer to the start of a different array object that happens to immediately follow the first array object in the address space" AND "implementation chose to place them so, even though they are unrelated".