From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8562 invoked by alias); 20 Feb 2014 17:55:29 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 8550 invoked by uid 89); 20 Feb 2014 17:55:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wi0-f177.google.com Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com) (209.85.212.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 20 Feb 2014 17:55:28 +0000 Received: by mail-wi0-f177.google.com with SMTP id e4so2080566wiv.10 for ; Thu, 20 Feb 2014 09:55:24 -0800 (PST) X-Received: by 10.194.234.106 with SMTP id ud10mr3439625wjc.0.1392918924239; Thu, 20 Feb 2014 09:55:24 -0800 (PST) Received: from localhost ([2.28.235.12]) by mx.google.com with ESMTPSA id d6sm440933wiz.4.2014.02.20.09.55.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Feb 2014 09:55:23 -0800 (PST) From: Richard Sandiford To: Patrick Palka Mail-Followup-To: Patrick Palka ,Jonathan Wakely , "gcc\@gcc.gnu.org" , rdsandiford@googlemail.com Cc: Jonathan Wakely , "gcc\@gcc.gnu.org" Subject: Re: Building GCC with -Wmissing-declarations and addressing its warnings References: Date: Thu, 20 Feb 2014 17:55:00 -0000 In-Reply-To: (Patrick Palka's message of "Thu, 20 Feb 2014 10:31:26 -0500") Message-ID: <87mwhlbred.fsf@talisman.default> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2014-02/txt/msg00390.txt.bz2 Patrick Palka writes: >> Maybe others will disagree and will think enabling >> -Wmissing-declarations would be a useful change, but I don't see the >> point. > > In my novice opinion, I think the flag helps keep source files tidy > and modular, and their interfaces well-defined. Its biggest benefit > is having the compiler inform you when a function should have been > marked static: marking a function static facilitates better > optimization and static analysis, and it helps convey the intent of > the function to the reader. +1 FWIW, though only for the compiler proper, since I wouldn't know either way about libstdc++. If GCC does become used as JIT in future then we might need to start worrying about ABI stability and so check the public symbols against a whitelist, like libstdc++ does. That's a stronger test, but probably too strong for GCC ATM. I think the other case you mentioned -- .c(c)s not including their own .hs -- is important too, especially since there's ongoing work to refactor the header files. In both cases, the option forces you to think about whether the routine really is public and so should be declared in a .h, or whether it's internal to the TU. Thanks, Richard