4 ms·
This code doesn't assume that q follows p, that's the trick to it. The way you are trying to explain this to me, I feel like you haven't read the article or und
by James_K 2y ago
This code doesn't assume that q follows p, that's the trick to it. The way you are trying to explain this to me, I feel like you haven't read the article or understood the code snippet.
- chongli 2y agoAfter (re)reading the article I've come to the conclusion that with proper provenance tracking through the cast to an integer, the comparison: (iq == ip) Should be replaced (at compile time) with the constant 0 (or false, if you like). Since iq and ip have different provenances -- even though they may (or may not) be bitwise equal (which is entirely implementation-dependent in C) -- they can never be considered equal, so falsity can be deduced at compile time. It should also be considered invalid (and a compile-time error) to cast any old plain integer (one whose provenance is not a pointer) to a pointer, regardless of whether or not the address of said pointer lands on a live object, because an integer created by any means other than a cast from a pointer should have empty provenance. Edit: Ahhh, this provenance story is way messier than I thought. One serious problem with tracking provenance is that functions like memcpy become a huge headache to deal with.