From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c Date: Mon, 26 Aug 2019 01:15:51 -0700 Organization: UCLA Computer Science Department Message-ID: <87cb5a0c-bdd8-726c-80ed-92e9f3518a58@cs.ucla.edu> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="77300"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 26 10:16:45 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 1i2ABA-000JyX-UY for ged-emacs-devel@m.gmane.org; Mon, 26 Aug 2019 10:16:45 +0200 Original-Received: from localhost ([::1]:50790 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2AB9-0007Cv-Sb for ged-emacs-devel@m.gmane.org; Mon, 26 Aug 2019 04:16:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45609) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2AAO-0007CW-SZ for emacs-devel@gnu.org; Mon, 26 Aug 2019 04:15:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i2AAN-0004p3-FI for emacs-devel@gnu.org; Mon, 26 Aug 2019 04:15:56 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:56498) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i2AAM-0004oE-0c; Mon, 26 Aug 2019 04:15:54 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 419DB160079; Mon, 26 Aug 2019 01:15:52 -0700 (PDT) Original-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 InS5g_mxzptQ; Mon, 26 Aug 2019 01:15:51 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 801D61600BF; Mon, 26 Aug 2019 01:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-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 NwFWeAKNv0w1; Mon, 26 Aug 2019 01:15:51 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 52479160079; Mon, 26 Aug 2019 01:15:51 -0700 (PDT) In-Reply-To: <83tva4fjkz.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 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:239571 Archived-At: 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. The best we can do is pacify GCC when a reasonable set of warning options is used, where "reasonable" is up to us (and is automated by 'configure'). >> Admittedly UNINIT is a bit of a kludge, but it's the best kludge we have in the >> area. > > 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. 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. 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.