@johnregehr @RichFelker @ch3root @spun_off ...it doesn't guarantee anything if you do any math on the [u]intptr_t value in the middle.
-
-
Replying to @BRIAN_____
@BRIAN_____@johnregehr@ch3root @spun_off If you do math on the uintptr_t and get back a uintptr_t you got from converting a pointer...1 reply 0 retweets 0 likes -
Replying to @RichFelker
@BRIAN_____@johnregehr@ch3root @spun_off ...then you are certainly justified in converting it back to a pointer.2 replies 0 retweets 0 likes -
Replying to @RichFelker
@RichFelker@johnregehr@ch3root @spun_off Justified by what? It would be nice but I don't think there's any guarantee.2 replies 0 retweets 0 likes -
Replying to @BRIAN_____
@BRIAN_____@johnregehr@ch3root @spun_off Because it's the same value, and C guarantees round-trip of pointers through uintptr_t.1 reply 0 retweets 0 likes -
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
@RichFelker @johnregehr @ch3root @spun_off Imagine uintptr_t is a key to a hash table mapping (uint64_t -> pointer).
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.