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 11:50:23 -0700 Organization: UCLA Computer Science Department Message-ID: <0d879611-8569-0876-bbbb-e706d13d669e@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> <87cb5a0c-bdd8-726c-80ed-92e9f3518a58@cs.ucla.edu> <83o90cfecf.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="81057"; 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 20:50: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 1i2K4f-000Kxm-Ft for ged-emacs-devel@m.gmane.org; Mon, 26 Aug 2019 20:50:41 +0200 Original-Received: from localhost ([::1]:56556 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2K4c-00036Z-Vc for ged-emacs-devel@m.gmane.org; Mon, 26 Aug 2019 14:50:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33303) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2K4T-00030y-1q for emacs-devel@gnu.org; Mon, 26 Aug 2019 14:50:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i2K4R-00037h-N6 for emacs-devel@gnu.org; Mon, 26 Aug 2019 14:50:28 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:49418) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i2K4Q-00032u-4Q; Mon, 26 Aug 2019 14:50:26 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 62B7C1600CE; Mon, 26 Aug 2019 11:50:24 -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 3tC033j5tylF; Mon, 26 Aug 2019 11:50:23 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9939F1600E6; Mon, 26 Aug 2019 11:50:23 -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 cBmPO-he7WsG; Mon, 26 Aug 2019 11:50:23 -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 656DE1600CE; Mon, 26 Aug 2019 11:50:23 -0700 (PDT) In-Reply-To: <83o90cfecf.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:239584 Archived-At: Eli Zaretskii wrote: > It's not about us, it's about GCC's tendency to turn more and more > warnings on by default. GCC does not enable this particular warning by default, and it's not likely ever to do so given the high rate of false alarms. People run into warnings like this because Emacs 'configure' enables them, and Emacs 'configure' is our responsibility. > I call GCC_LINT "tinkering". Developers and builders should not need to tinker in the typical case, if the default settings are OK. And developers using unusual tools will likely need to specify special arguments to 'configure' or 'make' anyway, so that's OK. > 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. Valgrind is one. There are also proprietary tools such as Coverity, QA-C, and Oracle Studio. Although they don't catch every use-before-set bug, they catch enough to be useful and they are practical to use. Admittedly they might not be *trivial* to use, but they aren't that hard and they don't (or at least shouldn't) require changing the Emacs source code. Valgrind works with Emacs master as-is, if you configure Valgrind and Emacs correctly and avoid having Emacs call library functions that rely on undefined behavior (Gtk has some, unfortunately, so I typically use -nw when using Valgrind to debug Emacs). I have used Valgrind to find and fix uninitialized-memory bugs in Emacs that would have been very difficult to find simply by using GDB or by staring at the code. As far as I know Valgrind is the best free tool for debugging some types of low-level errors that GCC does not diagnose, and this includes some significant classes of use-before-set bugs.