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=-4.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,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 34AC51F47C for ; Sun, 15 Jan 2023 03:02:46 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; unprotected) header.d=cs.ucla.edu header.i=@cs.ucla.edu header.a=rsa-sha256 header.s=78364E5A-2AF3-11ED-87FA-8298ECA2D365 header.b=luHGPT/z; dkim-atps=neutral Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pGtI1-00052j-Aq; Sat, 14 Jan 2023 22:02:33 -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 1pGtHz-00052G-B8 for bug-gnulib@gnu.org; Sat, 14 Jan 2023 22:02:31 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pGtHx-0008Ty-4d for bug-gnulib@gnu.org; Sat, 14 Jan 2023 22:02:31 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 50B47160040; Sat, 14 Jan 2023 19:02:25 -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 IDZN_vAOTvmY; Sat, 14 Jan 2023 19:02:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A3CFF160044; Sat, 14 Jan 2023 19:02:23 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu A3CFF160044 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1673751743; bh=gfbkEekFL4PF54O30Q0ngqoJ3bDWsQv29yCWCN8mUQA=; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type: Content-Transfer-Encoding; b=luHGPT/zW16Bw+vquJCEjxArKAe70GjByCLQbL8vGvpQkGIQb3FQZy0pQydd9Df6f 2mwUL8xPz89a30ozFAy6tXfDqOPZDaMULCszbtZEk09z6a/U3KOXzohjbmVvNwAy25 fXt39iAVnEqi2aQd3dCc42fWZZ7DnPdSQLU3xAcE= 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 o85pqwoOpIv4; Sat, 14 Jan 2023 19:02:23 -0800 (PST) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 6F7E5160041; Sat, 14 Jan 2023 19:02:23 -0800 (PST) Message-ID: Date: Sat, 14 Jan 2023 19:02:23 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Content-Language: en-US To: Bruno Haible , bug-gnulib@gnu.org References: <20230113201704.325290-1-eggert@cs.ucla.edu> <17910367.MNNF8PUAaN@nimes> <8041574.c9vzh5UkMf@nimes> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: [PATCH 1/4] localename: -Wtautological-pointer-compare In-Reply-To: <8041574.c9vzh5UkMf@nimes> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=131.179.128.68; envelope-from=eggert@cs.ucla.edu; helo=zimbra.cs.ucla.edu X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 On 2023-01-14 03:00, Bruno Haible wrote: > Is that what you are worried about? Should I work on this? No, please don't bother. I was partly confused by the situation and your email helped clear up some of it. Hope you don't mind this followup. 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 - though I hope the approximations are slowly getting better. > * To avoid garbage-in - garbage-out behaviour, which in general encourages > the presence of bugs. Yes, that's a good thing, though in this particular case abort and dereferencing NULL have similar effects on typical platforms so this doesn't argue for one method or the other. > * So that when an invalid argument gets passed and the developer happened > to compile with -g, the debugger will point to the exact line of the > abort(). When you say "the input should be checked anyway ... dynamically > by the MMU", what the user would see is a SIGSEGV, and would start wondering > whether the bug is in his code or in our code. In my experience users don't care whether the application died due to SIGABRT or to SIGSEGV. 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. And come to think of it, I have somewhat better luck with gdb's reports of SIGSEGV from dereferencing null pointers (though there are obviously issues there too) than I do from abort() calls. 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. Sure, the longer form is safer for oddball platforms, but it's not worth the aggravation. > * For documentation purposes: So that it's clear that we have considered > the doc of the function, and NULL at this particular place is invalid. I'm willing to trust the intelligence of the reader to know that if a function computes *P, then it's invalid for P to be null. Admittedly there's a lot of low-quality code out there where this isn't true, but here I'm focusing on the relatively high-quality code in Gnulib and GNU apps. > (This is not evident: For example, does glibc's error_at_line() support a > NULL fname argument? Hard to say from > .) The documentation is indeed unclear there, but this sort of thing is inevitable in any large system using C. For each such function where the spec is unclear, we should document whether a null pointer arg is allowed, and if it's not allowed the implementation of the function shouldn't need to worry about null pointer args (implementers already have too much to worry about, and part of the point of an API is simplification).