From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1OSqt0-000715-0o for garchives@archives.gentoo.org; Sun, 27 Jun 2010 12:22:58 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6F4E2E09A8; Sun, 27 Jun 2010 12:22:55 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 36FDEE0948 for ; Sun, 27 Jun 2010 12:22:49 +0000 (UTC) Received: from gentoo.org (cp1107341-a.dbsch1.nb.home.nl [84.31.115.1]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPSA id 6D1CA1B4085 for ; Sun, 27 Jun 2010 12:22:48 +0000 (UTC) Date: Sun, 27 Jun 2010 14:23:11 +0200 From: Harald van =?utf-8?Q?D=C4=B3k?= To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: FYI: Rules for distro-friendly packages Message-ID: <20100627122258.GA8754@boostbox> References: <20100625201738.GA4789@nibiru.local> <4C252C8E.8020408@gentoo.org> <20100626193915.GD4789@nibiru.local> <20100626205001.365b51cb@snowcone> <20100626195733.GF4789@nibiru.local> <20100626211254.002784d4@snowcone> <20100627104724.GC23460@nibiru.local> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: c6bc0568-a79f-48a1-ae96-e2f710ee4b41 X-Archives-Hash: 29b4472c2b54e35da4031de040faf282 On Sun, Jun 27, 2010 at 02:56:33PM +0300, Nikos Chantziaras wrote: > On 06/27/2010 01:47 PM, Enrico Weigelt wrote: > > * Nikos Chantziaras schrieb: > > > >> Did it actually occur to anyone that warnings are not errors? You can > >> have them for correct code. A warning means you might want to look at > >> the code to check whether there's some real error there. It doesn't > >> mean the code is broken. > > > > In my personal experience, most times a warning comes it, the > > code *is* broken (but *might* work in most situations). > > That's the key to it: most times. Granted, without -Wall (or any other > options that tweaks the default warning level) we can be very sure that > the warning is the result of a mistake by the developer. But with > -Wall, many warnings are totally not interesting ("unused parameter") > and some even try to outsmart the programmer even though he/she knows > better ("taking address of variable declared register"). In that last > example, fixing it would even be wrong when you consider the optimizer > and the fuzzy meaning of "register" which the compiler is totally free > to ignore. The compiler is not totally free to ignore the register keyword. Both the C and the C++ standards require that the compiler complain when taking the address of a register variable. Other compilers will issue a hard error for it. Fixing the code to not declare the variable as register would be the correct thing to do. Make sure you *understand* warnings, and then you can decide whether to fix the code, if there is anything to fix, or to ignore.