Bruno Haible wrote:
Paul Eggert wrote:
converting a pointer to uintptr_t and back means that GCC won't connect
the resulting pointer to the original and this messes up bounds checking
on the result.
I don't observe this. This test program:
The problem typically doesn't occur with simple casts of pointer to integer and
back because these are optimized away. It occurs only when the compiler doesn't
determine that the result was derived from the original pointer. This requires
more-complicated test code. If you're interested in exploring this, you might
take a look at the GNU Emacs source code master branch, which has a few ifdefs
for __CHKP__ and which avoids the conversions in question for the __CHKP__ case.
I remember long ago I was skeptical when Jim Meyering changed some code to avoid
signed integer overflow when wraparound yielded the correct answer. I wondered,
"what compiler would ever care?" Well, Jim was right: eventually some compilers
started to care. I view conversion from intptr_t to pointer as being in a
similar category: if we avoid these conversions now we will be saving some work
in the future.
