From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c Date: Mon, 26 Aug 2019 21:15:17 +0200 Message-ID: <87blwb4u2i.fsf@telefonica.net> References: <835zmnjdjm.fsf@gnu.org> <227db16b-17d1-b44b-97b3-e80211415eef@cs.ucla.edu> <831rx9iupo.fsf@gnu.org> <32f9db09-0c04-df03-4bb7-76fe2aa9a88f@cs.ucla.edu> <83tva4fjkz.fsf@gnu.org> <87cb5a0c-bdd8-726c-80ed-92e9f3518a58@cs.ucla.edu> <83o90cfecf.fsf@gnu.org> <87lfvg3qbi.fsf@telefonica.net> <83imqjgb1g.fsf@gnu.org> <87ftln4wm0.fsf@telefonica.net> <83a7bvg4a2.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="187364"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 26 21:15:41 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i2KSr-000mbw-2F for ged-emacs-devel@m.gmane.org; Mon, 26 Aug 2019 21:15:41 +0200 Original-Received: from localhost ([::1]:56748 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2KSp-0005xl-Sp for ged-emacs-devel@m.gmane.org; Mon, 26 Aug 2019 15:15:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37825) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2KSj-0005xb-EP for emacs-devel@gnu.org; Mon, 26 Aug 2019 15:15:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i2KSi-00069X-9q for emacs-devel@gnu.org; Mon, 26 Aug 2019 15:15:33 -0400 Original-Received: from 195-159-176-226.customer.powertech.no ([195.159.176.226]:50238 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i2KSi-00069K-2q for emacs-devel@gnu.org; Mon, 26 Aug 2019 15:15:32 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1i2KSZ-000mKH-UC for emacs-devel@gnu.org; Mon, 26 Aug 2019 21:15:23 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:pNdF+sT5YJ1JdbZToXLwIVL40WI= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:239587 Archived-At: Eli Zaretskii writes: >> From: Óscar Fuentes >> Date: Mon, 26 Aug 2019 20:20:23 +0200 >> >> Valgrind knows nothing about UNINIT as it works with machine code, not >> with source code. But AFAIK that macro is conditionally defined to "=0" >> (for silencing bogus gcc warnings) or to nothing (for leaving the >> variable uninitalized at the declaration point). The later allows >> Valgrind to do a proper check. >> >> Simply changing >> >> int x; >> >> to >> >> int x = 0; >> >> just for silencing the gcc warning can hide a bug that Valgrind would >> detect otherwise. > > This is backwards: it would mean we should use UNINIT all over the > place just to be sure we will be able to spot some imaginary bugs by > flipping a compiler switch. UNINIT should only be used to avoid bogus warnings, *actual* bogus warnings, not potential ones. > The initialization in this case was added because GCC flagged a > potential use-before-define. After that, there's no more bug for > Valgrind to find, so I see no reason to leave UNINIT around. Let's suppose that the warning was correct and the hacker was wrong when judged it bogus. Adding the initialization silences the warning *and* Valgrind, while the UNINIT trick would cause Valgrind to complain (when Valgrind examines an Emacs executable built with the options that cause UNINIT to be empty.) Or suppose that the warning is indeed bogus now. By adding the initialization you are precluding Valgrind to find a bug if some future code change introduces it. > I could understand using UNINIT (or something similar) when the > developer has no idea what not initializing could cause. But this is > not that case. One of the most important things of the mental model of a C/C++ hacker is the declare->initialize->use->dispose sequence of any storage. If the developer is unsure about where to initialize a variable, he must stop and think. The declaration should do the initialization only when it is the right thing, that means that the variable must have that value from that point. A variable shouldn't be assigned before the point where the information it is supposed to store is available. (Sorry if that sounds as if I were giving a lesson, that's not my intention at all. I'm sure that you know what I explained by heart, but it seems to me that you are not fully aware of the fact that some tools do provide reliable detection of certain conditions that the compilers tried half-assedly to detect for ages only to annoy experienced hackers and force them to use workarounds that now are counterproductive.)