From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: New warnings on emacs-26 branch with gcc 8.2.0 Date: Sat, 11 Aug 2018 12:23:28 -0700 Organization: UCLA Computer Science Department Message-ID: References: <86a7q0ai2z.fsf@gmail.com> <6d36dc4c-1e14-b6c8-e2f0-911d08f759e1@cs.ucla.edu> <8636vsxxjv.fsf@gmail.com> <880f6c74-daae-819d-c503-a52973b3f9d2@cs.ucla.edu> <861sbblwws.fsf@gmail.com> <1c65cdb5-f3a9-bfe1-c687-5cfce52c3945@cs.ucla.edu> <86pnyvjhxq.fsf@gmail.com> <7cfe570f-2c34-c55e-05b0-34ffdc6e4ee0@cs.ucla.edu> <86zhxtq6xa.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1534015327 25164 195.159.176.226 (11 Aug 2018 19:22:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 11 Aug 2018 19:22:07 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 To: Andy Moreton , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 11 21:22:03 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1foZSd-0006Q7-8H for ged-emacs-devel@m.gmane.org; Sat, 11 Aug 2018 21:22:03 +0200 Original-Received: from localhost ([::1]:32959 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1foZUj-0005vW-LI for ged-emacs-devel@m.gmane.org; Sat, 11 Aug 2018 15:24:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36188) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1foZU7-0005vP-St for emacs-devel@gnu.org; Sat, 11 Aug 2018 15:23:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1foZU2-0003n6-Uv for emacs-devel@gnu.org; Sat, 11 Aug 2018 15:23:35 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:33218) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1foZU2-0003mk-O2 for emacs-devel@gnu.org; Sat, 11 Aug 2018 15:23:30 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id C055816072A; Sat, 11 Aug 2018 12:23:29 -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 2m4NtoW3i3Ay; Sat, 11 Aug 2018 12:23:29 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 06E15160D70; Sat, 11 Aug 2018 12:23:29 -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 4atb9p5-V06v; Sat, 11 Aug 2018 12:23:28 -0700 (PDT) Original-Received: from [192.168.1.9] (unknown [47.154.30.119]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 9FCDB16072A; Sat, 11 Aug 2018 12:23:28 -0700 (PDT) In-Reply-To: <86zhxtq6xa.fsf@gmail.com> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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:228428 Archived-At: Andy Moreton wrote: > Using the manywarnings module still requires emacs to add new warnings to > the nw list every time gcc is upgraded, so I don't think that is less > work. That work is automated by the admin/merge-gnulib script. So it is less work. > It woudl surely be simpler to use _Wall -Wextra and a limited number of > additional warnings that know to be useful That's how we did things originally, and it was more work that way, because it meant each project had to track every new GCC warning that might be useful for that project. It's less work overall if we rely on Gnulib's module, which grabs almost all GCC warnings (except those that don't seem to be useful in any GNU project), and then let each project filter out the relatively few ones that it doesn't want. There is no perfect solution here, but we tried it the way you're suggesting and it was more work than what we're doing now.