[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: intptr_t vs. uintptr_t

From: Bruno Haible
Subject: Re: intptr_t vs. uintptr_t
Date: Sat, 14 Dec 2019 10:14:44 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-166-generic; KDE/5.18.0; x86_64; ; )

Hi Paul,

> >   "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.
> It depends on the application. For example, with two char * pointers P and Q
> into an array, it can be helpful that P - Q yields the same integer as
> ((intptr_t) P - (intptr_t) Q), assuming the usual representation.

Suppose that we have an array that extends from 0x7fff8000 to 0x80003fff - this
can happen! look at the address range maps -, and
- either P = 0x7fffc000 and Q = 0x80003000
  then ((intptr_t) P - (intptr_t) Q) causes a signed integer overflow
  (value > INTPTR_MAX),
- or vice versa: P = 0x80003000 and Q = 0x7fffc000
  then ((intptr_t) P - (intptr_t) Q) causes a signed integer overflow
  (value < INTPTR_MIN).
So, with an undefined-behaviour sanitizer enabled, the program will crash.

> That's not true for uintptr_t.

With uintptr_t, the program will not crash for an address difference 
The expression (intptr_t)((uintptr_t) P - (uintptr_t) Q) will always return
the expected value. (Here we assume that no array consumes more than half of
the address range, a constraint that is also your justification for using

> In practice, Emacs uses uintptr_t quite a bit for things like hashes and tags;
> but it uses intptr_t a bit more, so the advice seems reasonable for Emacs.

No, the advice is bad, even for Emacs.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]