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.

Reply via email to