@RichFelker @ch3root The code does have UB because you aren't allowed to access objects via a pointer to another.
-
-
Replying to @CopperheadOS
@RichFelker@ch3root The pointer used to access an object has to be derived from a pointer to that same object. Not a different one.2 replies 0 retweets 0 likes -
Replying to @CopperheadOS
@CopperheadSec@ch3root I don't see that language anywhere in the spec. Certainly cast to uintptr_t and back should be able to bypass.2 replies 0 retweets 0 likes -
Replying to @RichFelker
@CopperheadSec@ch3root If the values as uintptr_t are equal, casting back should yield a pointer which could access either object.1 reply 0 retweets 0 likes -
Replying to @RichFelker
@RichFelker@CopperheadSec This is wrong in practice. gcc tracks pointer's origin through casts to integers (and even floats).2 replies 0 retweets 0 likes -
Replying to @ch3root
@ch3root@RichFelker Yes, it's difficult to interpret the standard. But it's objectively true that GCC and LLVM do it this way.1 reply 0 retweets 0 likes -
Replying to @CopperheadOS
@CopperheadSec@ch3root Do you have an example to demonstrate the behavior I claim is a bug?1 reply 0 retweets 0 likes -
Replying to @RichFelker
@RichFelker@CopperheadSec Sure. It's too big for a tweet. Sent by email.1 reply 0 retweets 0 likes -
Replying to @ch3root
@ch3root@CopperheadSec Thanks. I think this should be a bug report.1 reply 0 retweets 0 likes -
Replying to @RichFelker
@RichFelker@CopperheadSec Wait, you said that equality doesn't imply interchangability. What's the problem then? :-)1 reply 0 retweets 0 likes
@ch3root @CopperheadSec For integers it does. The requirements of an implementation-defined conversion and faithfulness for uintptr_t...
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.