From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 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 AF2EA1F47C for ; Sun, 15 Jan 2023 22:03:44 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=clisp.org header.i=@clisp.org header.a=rsa-sha256 header.s=strato-dkim-0002 header.b=LQgFcbR3; dkim-atps=neutral Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pHB66-00018C-Gm; Sun, 15 Jan 2023 17:03:26 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pHB64-00017s-Na for bug-gnulib@gnu.org; Sun, 15 Jan 2023 17:03:24 -0500 Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.220]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pHB62-0007rD-O9 for bug-gnulib@gnu.org; Sun, 15 Jan 2023 17:03:24 -0500 ARC-Seal: i=1; a=rsa-sha256; t=1673820190; cv=none; d=strato.com; s=strato-dkim-0002; b=TQp3JYVRukPLPwP9RftOEe3vIT5NqPoqWA60mYqMwEEzdedUsDLBD8W74wAYeR7e6j +TZTYLaLkfsPUEnzxmb+iDMkKgES6wNvXscEy6/dk9a7iV6utQlRYGEhhDYfuKKbX4o7 6G2WENz8CBzrR5Qmm5s1UJive+ylX+8nqQriOvusiRio1jnQYDcEWlnqdzNlQAtw9DhR SdPY0wJ7Y4a15mXwFILVeq9STk7awszVAYW9KazeL+RDM5hd/44MXuwwPS2+O38Y4nRk Ue6/OKLtO3qCp4QvZU+0hmvg3XKgAGOPszG6tlF5MpyLMZzqH432G6jENnRN4wuZQcUb 73Gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1673820190; s=strato-dkim-0002; d=strato.com; h=References:In-Reply-To:Message-ID:Date:Subject:To:From:Cc:Date:From: Subject:Sender; bh=kVRVEtAesHLwOIENrqkgwgQJ0uXyrzKQ/BQ3nGJ3td8=; b=gqHRlhitlUFm2oosYFHUP0c/P8+Qrlm/Pz/2Tz0H+zOKoTjym5CecZNNt6d6BC3jAz GraVlOeZPSntf160LzXbum4/t2nvcyjlASKKC6hZnA9Uc5+rW9/Tbbq9hlRriZyJl4JQ 4unhjo6hcC0B+MbG+kB1cH7CQqTYSluIaVv2NJkqGOD8DHSFAto6G3kHY5Vpqn7LpN/z vpGB1amMP5HF4eAYtR/m6hiimLUbJi8cjDPy1/YHLq4g8EaEXUA2arm9rp1Ue05sFxkU 9PaG5iH0tkg0Sc6fBV/6QMYUbK9ksqMH+ZdSFakSlW5h9lAASBI4TeI1pVZDHsGwbVuz rR+g== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1673820190; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:To:From:Cc:Date:From: Subject:Sender; bh=kVRVEtAesHLwOIENrqkgwgQJ0uXyrzKQ/BQ3nGJ3td8=; b=LQgFcbR3K1nZbsKhxKi8hLD/EL+KpEtEZwp1jN+MmHGueid/VGefAjPVMe+UpyRnR5 yU6b8vRNwtItjTfU5CMLk+Wi9tccJIV8HEYS3pyX9s0MQiQkIpfYuFEPxqaRoCPebiBz 7fRiI4JMlx1ZrWwPn5OmXnXeZrBiBb6i1v97elF80TKeSDTFVjtAkEnMhb9jM6gU/lCn a25GRwHo4g2dfppjAdAKLh7aXL931E+wbMqxwdzcAdg65ex6DnyQvgqCcoYZqVYSgm37 xJw5CllevRsEkX0MufrPoqX2Fv0x/1GMMG0X+DW5IH7vLvZzhyBAPdimLlJOfxEjD3dn 1HcA== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94zq68+3cfpPC36MKRCY/l9/dcAUOVs3n6M4G" Received: from nimes.localnet by smtp.strato.de (RZmta 48.6.2 AUTH) with ESMTPSA id I8f358z0FM39IkW (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Sun, 15 Jan 2023 23:03:09 +0100 (CET) From: Bruno Haible To: bug-gnulib@gnu.org, Paul Eggert Subject: Re: [PATCH 1/4] localename: -Wtautological-pointer-compare Date: Sun, 15 Jan 2023 23:03:09 +0100 Message-ID: <2228043.iJkMF17ckq@nimes> In-Reply-To: References: <20230113201704.325290-1-eggert@cs.ucla.edu> <8041574.c9vzh5UkMf@nimes> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Received-SPF: none client-ip=81.169.146.220; envelope-from=bruno@clisp.org; helo=mo4-p00-ob.smtp.rzone.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Hi Paul, > My confusion arose partly because I am accustomed to languages where the > distinction between null and non-null pointers is checked statically and > reliably, and I keep forgetting that with C, GCC and Clang are only poor > approximations to that Oh, now I understand. May I guess the language: Haskell, OCaml, TypeScript, Rust? > - though I hope the approximations are slowly getting better. Still it will take a lot of time. The following steps need to happen: 1. Standards need to define a notation for declaring a non-null type value, non-null argument, or non-null return value. (Partially done.) 2. Compilers need to diagnose places where a non-null declaration could be added, like they do for function attributes __pure__ and __const__. 3. Developers need to add such declarations to their .h files. Then only such static checking can happen, without producing floods of diagnostics that developers would discard. > Also, in my experience the debugger doesn't always point to the exact > line of the abort(). For example, if there are two abort() calls in the > same function they are routinely coalesced. True :( I should have mentioned to compile with "-g -O0", not just "-g". > To give a different example: I wouldn't bother with the following code > (where M and N are int arguments to a function): > > if (n == 0) > abort (); > if (n == -1 && m < -INT_MAX) > abort (); > return m / n; > > and would instead write this: > > return m / n; > > as the user and debugging experiences are similar and the shorter form > simplifies code maintenance. Unfortunately, this is an excellent example for a portability problem: The division yields a SIGFPE on x86, x86_64, alpha, m68k, and s390/s390x CPU, but not on other architectures. > Sure, the longer form is safer for oddball > platforms, but it's not worth the aggravation. Some distros feel differently. I have such code in GNU gettext, and optimize away the entry checks on platforms where I know it yields a SIGFPE. And some distros disabled these optimizations, i.e. enabled the entry checks always... Bruno