From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 361371F463 for ; Sat, 14 Dec 2019 22:29:49 +0000 (UTC) Received: from localhost ([::1]:34066 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1igFv1-0003FU-Nq for normalperson@yhbt.net; Sat, 14 Dec 2019 17:29:47 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45673) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1igFuu-0003FO-As for bug-gnulib@gnu.org; Sat, 14 Dec 2019 17:29:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1igFuq-0001qM-Nd for bug-gnulib@gnu.org; Sat, 14 Dec 2019 17:29:38 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:56700) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1igFup-0001p3-Qz for bug-gnulib@gnu.org; Sat, 14 Dec 2019 17:29:36 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5A0E61605A6; Sat, 14 Dec 2019 14:29:33 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 6AaDnby-qlRs; Sat, 14 Dec 2019 14:29:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 41D251605B5; Sat, 14 Dec 2019 14:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8sYmz9rO7sZu; Sat, 14 Dec 2019 14:29:32 -0800 (PST) Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id EDB4A1605A6; Sat, 14 Dec 2019 14:29:31 -0800 (PST) Subject: Re: intptr_t vs. uintptr_t To: Bruno Haible References: <20190323080618.E6EB.27F6AC2D@kcn.ne.jp> <2169340.l2UmpkpDhn@omega> <5120e6e1-1116-dc47-292f-d721014e3aea@cs.ucla.edu> <2783436.Tsuh4lOfYa@omega> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <362ef4f4-83b7-1630-9ad3-4453ae2b5e64@cs.ucla.edu> Date: Sat, 14 Dec 2019 14:29:31 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <2783436.Tsuh4lOfYa@omega> Content-Type: multipart/mixed; boundary="------------EE2916EABC6FD0039707EF3C" Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: bug-gnulib@gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" This is a multi-part message in MIME format. --------------EE2916EABC6FD0039707EF3C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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. --------------EE2916EABC6FD0039707EF3C Content-Type: text/x-patch; charset=UTF-8; name="0001-Adjust-intptr_t-advice.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Adjust-intptr_t-advice.patch" >From 67adb673e799b394eab346e44a08b63daa0412ae Mon Sep 17 00:00:00 2001 From: Paul Eggert 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 --------------EE2916EABC6FD0039707EF3C--