Paul Eggert wrote:
> https://www.gnu.org/software/emacs/manual/html_node/elisp/C-Integer-Types.html
Quoting it:
"Prefer intptr_t for internal representations of pointers"
I disagree with this advice. uintptr_t ought to be used for representing the
address of a pointer.
Why? Because when signed comparisons or pointer differences come into play,
- uintptr_t creates a boundary line at 0x00000000,
- intptr_t creates a boundary line at 0x80000000.
Now look at the virtual memory map of a process (e.g. by compiling vma-iter.c
with -DTEST).
On all OSes, there is a natural boundary line at 0x00000000 - simply because
there is the null-pointer catching area there.
On many OSes, memory allocations can lie around 0x80000000.
So, it is possible to have ptr1 = 0x7fffc000 and ptr2 = 0x80003000 point into
the same object (allocated through mmap or malloc). Then
- you DO want ptr1 < ptr2 to evaluate to true, not false,
- you DO want ptr2 - ptr1 to evaluate to 0x7000, not to a signed integer
overflow.
Bruno
