@BRIAN_____ @johnregehr @ch3root @spun_off ...then you are certainly justified in converting it back to a pointer.
-
-
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 -
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@ch3root @spun_off Yes. But you need to understand "a uintptr_t converted from a pointer" is a _value_.1 reply 0 retweets 0 likes
@BRIAN_____ @johnregehr @ch3root @spun_off You can recover the ptr as long as you have that value. Ways of keeping the value are limitless.
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.