https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
Alexander Cherepanov <ch3root at openwall dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ch3root at openwall dot com
--- Comment #17 from Alexander Cherepanov <ch3root at openwall dot com> ---
(In reply to [email protected] from comment #1)
> Just because two pointers print the same and have the same bit-pattern
> doesn't mean they need to compare equal
The standard seems to disagree. C11, 6.2.6.1p4: "Two values (other than NaNs)
with the same object representation compare equal".
;-)
(In reply to [email protected] from comment #3)
> Except within a larger object, I'm not aware of any reason the cases of
> two objects following or not following each other in memory must be
> mutually exclusive.
I guess it depends on the transitivity of the == operator. After this bug is
fixed it will be possible to constuct a third pointer r from two pointer p and
q such that r == p and r == q but p != q. For p and q take &x + 1 and &y as
above, obtain r by stripping provenance info from p or q (e.g. by printf/scanf
with %p).
My impression is that the text of the standard implies interchangability of
equal pointers (and hence transitivity of == ) but this area is underspecified
and probably could be fixed in a way that doesn't imply transitivity of == .
But is gcc ok with this? This bug and pr65752 show some complexities. OTOH ==
is not reflexive for double and it's ok.
