Yeah, this does make the "read pointer from user input" case (which is actually sometimes useful) a bit weird however but it seems pretty obvious that ptr-to-int should probably be exposing at the very least
> Yeah, this does make the "read pointer from user input" case (which is actually sometimes useful) a bit weird
I think it works out quite reasonably and elegantly, actually.
If you can prove that an address wasn't leaked -- then you can assume the program behavior is independent of any pointer read from user input, and thus optimize as if the pointer wasn't read from user input.
Otherwise, you assume the address was leaked, and thus must act as if the target might overlap said address.
> however but it seems pretty obvious that ptr-to-int should probably be exposing at the very least
I don't think that's necessary, but it's certainly a valid way to write a compiler. (I say this because I don't think (void)(uintptr_t)ptr; should be considered exposing, for example.)
