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".
