@BRIAN_____ @johnregehr @ch3root @spun_off Because it's the same value, and C guarantees round-trip of pointers through uintptr_t.
-
-
Replying to @RichFelker
@RichFelker@johnregehr@ch3root @spun_off I think the C std should say that arithmetic on uint8_t* is equiv to arith on uintptr_t reps...1 reply 0 retweets 0 likes -
Replying to @BRIAN_____
@BRIAN_____@johnregehr@ch3root @spun_off This would force impls with advanced ptr models not to define [u]intptr_t at all.1 reply 0 retweets 0 likes -
Replying to @RichFelker
@RichFelker@johnregehr@ch3root @spun_off I'm not sure what you mean then. Isn't that a prereq. for ptr -> uintptr_t math -> ptr?1 reply 0 retweets 0 likes -
Replying to @BRIAN_____
@BRIAN_____@johnregehr@ch3root @spun_off No. Without that you can still do all sorts of math treating the values as opaque.1 reply 0 retweets 0 likes -
Replying to @RichFelker
@BRIAN_____@johnregehr@ch3root @spun_off Hashing or encryption of ptrs, xor linked lists, 'base-relative' diffs for ptrs in shm, etc.2 replies 0 retweets 0 likes -
Replying to @RichFelker
@RichFelker@johnregehr@ch3root @spun_off The standard says only that given a uintptr_t converted from pointer, you can recover pointer.2 replies 0 retweets 0 likes -
Replying to @BRIAN_____
@BRIAN_____@johnregehr@RichFelker @spun_off Right. That's why I like one conv (ptr->uint) more than two (ptr->uint & uint->ptr).1 reply 0 retweets 1 like -
Replying to @ch3root
@BRIAN_____@johnregehr@RichFelker @spun_off The difference is not that big given ptr->uint conv is impl-def anyway.1 reply 0 retweets 1 like -
Replying to @ch3root
@BRIAN_____@johnregehr@RichFelker @spun_off But mappings are "intended to be consistent with the addressing structure of the exec. env.".2 replies 0 retweets 1 like
@ch3root @johnregehr @RichFelker @spun_off Thank you for this. I appreciate the quote and I learned something from this.
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.