@RichFelker @spun_off @ch3root Consider an implementation that implements (uintptr_t) casting in the following way:
-
-
Replying to @BRIAN_____
@RichFelker @spun_off@ch3root uintptr_t x = (uintptr_t)p; // x := 1 uintptr_t y = (uintptr_t)p; // y := 2, y != x.2 replies 0 retweets 0 likes -
Replying to @BRIAN_____
@RichFelker @spun_off@ch3root however (void*)x == (void*)y, assuming that casting from uintptr_t to void* is just looking up ptr in array.2 replies 0 retweets 0 likes -
Replying to @BRIAN_____
@BRIAN_____@RichFelker @spun_off Yes, I can imagine this. I think it's unlikely, in practice, for a cast to uintptr_t but comparisons of\1 reply 0 retweets 0 likes -
Replying to @ch3root
@BRIAN_____@RichFelker @spun_off pointers are definitely behave strangely.1 reply 0 retweets 0 likes -
Replying to @ch3root
@BRIAN_____@RichFelker @spun_off E.g. p==q is unstable -- it could be false now and true later even if p and q are not changed\1 reply 0 retweets 0 likes -
Replying to @ch3root
@BRIAN_____@RichFelker @spun_off (due to lost provenance info).1 reply 0 retweets 0 likes -
Replying to @ch3root
@BRIAN_____@RichFelker @spun_off Or there could be pointers p, q, r such that r == p, r == q, p != q.1 reply 0 retweets 0 likes -
Replying to @ch3root
@BRIAN_____@RichFelker @spun_off Probably most wtf moments are in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 … and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752 …1 reply 1 retweet 1 like -
Replying to @ch3root
@BRIAN_____@RichFelker @spun_off BTW Robbert which reported https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752 … is that Robbert.2 replies 0 retweets 1 like
@ch3root @BRIAN_____ @spun_off Robbert's comment 2 there is excellent.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.