good point but of course neither compiler cares about the actual value...
-
-
Replying to @johnregehr @oshepherd
Indeed. At first it seems reasonable that a ptr converted from int could only meaningfully point to fixed hw or an obj whose addr leaked...
1 reply 0 retweets 0 likes -
However pigeonhole principle makes things get nasty.
2 replies 0 retweets 0 likes -
Replying to @RichFelker @oshepherd
yes an LLVM bug is filed about the case where you make a pointer (on a 32-bit machine) and try to guess it in a loop and it thinks you can't
1 reply 0 retweets 0 likes -
Replying to @johnregehr @oshepherd
If your guess involves any accesses, I think the bug is invalid; the compiler can infer UB from the access.
2 replies 0 retweets 0 likes -
Replying to @RichFelker @oshepherd1 reply 0 retweets 0 likes
-
Replying to @johnregehr @oshepherd
Does it still happen if &i == (int*)cur is changed to (uintptr_t)i == cur?
1 reply 0 retweets 0 likes -
There may be an argument that using an invalid pointer as an operand to == invokes UB, but ops on uintptr_t are all 100% well-defined.
1 reply 0 retweets 0 likes -
Replying to @RichFelker @oshepherd
neither compiler cares about that distinction:https://godbolt.org/g/rJAetU
1 reply 0 retweets 1 like -
Replying to @johnregehr @oshepherd
In that case they're probably both doing LOTS of wrong optimizations of stuff involving uintptr_t...
2 replies 0 retweets 0 likes
I would be surprised if they didn't even manage to break xor-linked-lists...
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.