From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c Date: Mon, 26 Aug 2019 12:47:12 +0300 Message-ID: <83o90cfecf.fsf@gnu.org> 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> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="188685"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 26 11:47:29 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 1i2Bay-000mvl-KN for ged-emacs-devel@m.gmane.org; Mon, 26 Aug 2019 11:47:28 +0200 Original-Received: from localhost ([::1]:51300 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2Baw-0006hn-Qr for ged-emacs-devel@m.gmane.org; Mon, 26 Aug 2019 05:47:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59578) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2Bai-0006hf-CG for emacs-devel@gnu.org; Mon, 26 Aug 2019 05:47:13 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36948) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i2Bah-0002rA-6b; Mon, 26 Aug 2019 05:47:11 -0400 Original-Received: from [176.228.60.248] (port=3272 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i2Bag-0000TI-LZ; Mon, 26 Aug 2019 05:47:11 -0400 In-reply-to: <87cb5a0c-bdd8-726c-80ed-92e9f3518a58@cs.ucla.edu> (message from Paul Eggert on Mon, 26 Aug 2019 01:15:51 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:239573 Archived-At: > Cc: emacs-devel@gnu.org > From: Paul Eggert > Date: Mon, 26 Aug 2019 01:15:51 -0700 > > Eli Zaretskii wrote: > > > The warnings will re-appear if one > > compiles outside of Git with suitable GCC options, so the solution is > > incomplete at best. > > We can't (and shouldn't try to) defend against people compiling Emacs with > arbitrary-chosen GCC warning options, as there would be far too many false > alarms. It's not about us, it's about GCC's tendency to turn more and more warnings on by default. An explicit initialization with a comment explaining it is a small price to pay for clean compilation in arbitrary environments. > > An explicit initialization is a tad better, as it doesn't require any > > tinkering with obscure settings. > > Neither should UNINIT require tinkering, if users employ default configuration > settings. I call GCC_LINT "tinkering". > Explicit initialization uses plain C rather than the awkward UNINIT macro, and > that is a plus for explicit initialization. However, that's a style issue, and > for me it's outweighed by the technical advantage of aiding automated debugging > tools that I use occasionally. If this is just your personal stylistic preference, then I'd question whether we as a project should accept it. E.g., my stylistic preference is different; where does that leave us? > For these tools it is helpful to say that a variable is not > initialized, because that helps catch use-before-set errors. An > explicit initialization would cause these use-before-set bugs to go > uncaught by these debugging tools. What debugging tools can make a significant difference here, and how easy/practical is it to use them? I very much doubt they will catch every use-before-set bug anyway.