Re: intptr_t vs. uintptr_t

[Paul Eggert <eggert@cs.ucla.edu>]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

On 12/14/19 1:14 AM, Bruno Haible wrote:
> Suppose that we have an array that extends from 0x7fff8000 to 0x80003fff

Ah, I hadn't thought about that. Thanks for mentioning it.

With Emacs's use of intptr_t this should not be an issue, since Emacs either
does no arithmetic on intptr_t values, or does only minor arithmetic (typically
pointer tagging) that keeps the address on the same page. However, you're right
that uintptr_t is preferable in cases that might cross page boundaries, and I
installed the attached into the Emacs Lisp reference manual to try to capture
that advice.

[-- Attachment #2: 0001-Adjust-intptr_t-advice.patch --]
[-- Type: text/x-patch, Size: 1505 bytes --]

From 67adb673e799b394eab346e44a08b63daa0412ae Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 14 Dec 2019 14:22:03 -0800
Subject: [PATCH] Adjust intptr_t advice

* doc/lispref/internals.texi (C Integer Types): Say to prefer
uintptr_t when pointer arithmetic might overflow intptr_t.
---
 doc/lispref/internals.texi | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/doc/lispref/internals.texi b/doc/lispref/internals.texi
index 8c55f4ea37..2a4e64dbb5 100644
--- a/doc/lispref/internals.texi
+++ b/doc/lispref/internals.texi
@@ -2825,12 +2825,14 @@ C Integer Types
 @code{SSIZE_MAX}.
 
 @item
-Prefer @code{intptr_t} for internal representations of pointers, or
+Normally, prefer @code{intptr_t} for internal representations of pointers, or
 for integers bounded only by the number of objects that can exist at
 any given time or by the total number of bytes that can be allocated.
-Currently Emacs sometimes uses other types when @code{intptr_t} would
-be better; fixing this is lower priority, as the code works as-is on
-Emacs's current porting targets.
+However, prefer @code{uintptr_t} to represent pointer arithmetic that
+could cross page boundaries.  For example, on a machine with a 32-bit
+address space an array could cross the 0x7fffffff/0x80000000 boundary,
+which would cause an integer overflow when adding 1 to
+@code{(intptr_t) 0x7fffffff}.
 
 @item
 Prefer the Emacs-defined type @code{EMACS_INT} for representing values
-- 
2.17.1