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.8 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, SPF_HELO_PASS,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 EF3551F5AE for ; Mon, 19 Jul 2021 00:37:49 +0000 (UTC) Received: from localhost ([::1]:42884 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m5HI4-0004xb-5Y for normalperson@yhbt.net; Sun, 18 Jul 2021 20:37:48 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54404) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m5HHz-0004xQ-3U for bug-gnulib@gnu.org; Sun, 18 Jul 2021 20:37:43 -0400 Received: from mo4-p00-ob.smtp.rzone.de ([85.215.255.21]:32202) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m5HHx-0001Cy-1d for bug-gnulib@gnu.org; Sun, 18 Jul 2021 20:37:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1626655057; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=KF+uzbCGoMgtujHXtMo4ryT81In7Ez+3mo5Ugd235aM=; b=c9h0/VhpDVRQUn5iM/344q9HWkudIMwxusJEJY0nRd5EgHejkZQwK1Ed2xDw6SzCEq KTI7/nUPRA0xYnOGmaJm65PTI8p1vGZrhJ9o2BEBs51Ydc7E63iDhiY3639qGp8z0xod Qw8su2gXPIxVndfMugkNxILfY6OazZZQvPOb7RgdoUnTRFxZ5dsXvdubHL6YtX2Mw3NH IGwtLhTYFoMzD7hZDE3jFn1PbVQit5JzYVrinE4rHGkaMKzxDsXQZI0W67hkdUJQruEb 12oOXzRj5Md/7XuALnfqi89vuteqHjaS7N1tpGfBzwH5wFUAtujGl9dmlvq/AibD1rdz Z6DA== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH/DXj0JGsbh0vbrMZq" X-RZG-CLASS-ID: mo00 Received: from bruno.haible.de by smtp.strato.de (RZmta 47.28.1 DYNA|AUTH) with ESMTPSA id u08ae3x6J0bbHnE (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); Mon, 19 Jul 2021 02:37:37 +0200 (CEST) From: Bruno Haible To: Paul Eggert Subject: Re: [PATCH 1/2] explicit_bzero-tests: pacify GCC Date: Mon, 19 Jul 2021 02:37:36 +0200 Message-ID: <1722919.vQ5SAmhZEJ@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-210-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <7d3aed6a-e6f5-e5cb-373a-d5dec068ea0b@cs.ucla.edu> References: <20210718045621.1058412-1-eggert@cs.ucla.edu> <2568272.mkVSEl9qYJ@omega> <7d3aed6a-e6f5-e5cb-373a-d5dec068ea0b@cs.ucla.edu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Received-SPF: none client-ip=85.215.255.21; envelope-from=bruno@clisp.org; helo=mo4-p00-ob.smtp.rzone.de X-Spam_score_int: -21 X-Spam_score: -2.2 X-Spam_bar: -- X-Spam_report: (-2.2 / 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, NICE_REPLY_A=-0.07, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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.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" Paul Eggert wrote: > No initiatives are needed, at least for C. Using uninitialized storage > is undefined behavior in the current C standard and this has been true > ever since C was standardized. I imagine C++ is similar. > ... > But in cases like these GCC > actually "knows" that variables are uninitialized and it sometimes > optimizes based on this knowledge. For example, for: > > _Bool f (void) { char *p; return !p; } > > gcc -O2 (GCC 11.1.1 20210531 (Red Hat 11.1.1-3)) "knows" that P is > uninitialized and generates code equivalent to that of: > > _Bool f (void) { return 1; } > > That is, GCC optimizes away the access to p's value, which GCC can do > because the behavior is undefined. Ouch, I seriously underrated this warning. Thanks for correcting me. Indeed, GCC does this optimization already since version 4.3. > > If GCC ever > > infers that it is "certainly uninitialized", we could defeat that > > through a use of 'volatile', such as > > Yes, some use of volatile should do the trick for GCC (which is what my > patch did). However, one would still have problems with a debugging > implementation, e.g., if GCC ever supports an -fsanitize=uninitialized > option that catches use of uninitialized storage. Yes, this test probably fails under 'valgrind'. I don't know a fail-safe workaround. When the purpose is to verify whether a memory region that has gone out-of-scope has been cleared, it necessarily means to access this memory region as if it were uninitialized. Bruno