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.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 84D541F463 for ; Sat, 14 Dec 2019 09:14:58 +0000 (UTC) Received: from localhost ([::1]:57404 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ig3Vo-0007M2-Hu for normalperson@yhbt.net; Sat, 14 Dec 2019 04:14:56 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46564) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ig3Vj-0007Lj-Qv for bug-gnulib@gnu.org; Sat, 14 Dec 2019 04:14:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ig3Vi-00062o-JS for bug-gnulib@gnu.org; Sat, 14 Dec 2019 04:14:51 -0500 Received: from mo6-p00-ob.smtp.rzone.de ([2a01:238:20a:202:5300::1]:34001) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ig3Vh-0005of-Qs for bug-gnulib@gnu.org; Sat, 14 Dec 2019 04:14:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1576314886; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=G/27aXbSsThz/hmJSMgc3emLtWal1u5YyjOwFQi+MEw=; b=jcCeFmtpY+ki1b15rALsfywmUQ5EpuHTOu/pEVsPPW/Z2xYXFZlMt1RFLHE6MFmelh zpPsO7nLCsJfdgEHdHMrVbvOtDcduRBPrg7RLdTgHb9yGfaZd7W/Ki1p9ZGMbqtxcQgv T/FocHlbj1KZEnkAB0412eICz8c7Oal0BX2NbFq15KUoFZfYX+BsOB9c8NtGcwId5YZH GXwuLUrAyNfX5Gn36W/Z7GdR4GoMkKp8I56exfY41vWiJ96WOVCYoCfE7eRAhChu3IBN 9HzGvCUhYmGg/uZ2vZZHFnG5IHBMAzFAf/ALdf38CKetlKP6E6YnzlLFw0GtgLBpROmm kpaA== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOH6fzxfs=" X-RZG-CLASS-ID: mo00 Received: from bruno.haible.de by smtp.strato.de (RZmta 46.0.7 DYNA|AUTH) with ESMTPSA id 3049ecvBE9Ei9lk (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Sat, 14 Dec 2019 10:14:44 +0100 (CET) From: Bruno Haible To: Paul Eggert Subject: Re: intptr_t vs. uintptr_t Date: Sat, 14 Dec 2019 10:14:44 +0100 Message-ID: <2783436.Tsuh4lOfYa@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-166-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <5120e6e1-1116-dc47-292f-d721014e3aea@cs.ucla.edu> References: <20190323080618.E6EB.27F6AC2D@kcn.ne.jp> <2169340.l2UmpkpDhn@omega> <5120e6e1-1116-dc47-292f-d721014e3aea@cs.ucla.edu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:238:20a:202:5300::1 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" 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 computation. 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 ptrdiff_t.) > 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. Bruno