Return-Path: MIME-Version: 1.0 In-Reply-To: References: <1339761848-7472-1-git-send-email-hdante@profusion.mobi> From: Lucas De Marchi Date: Tue, 19 Jun 2012 18:41:16 -0300 Message-ID: Subject: Re: [PATCH RFC] gdbus: Rename variables named "signal" (so that it can be compiled with -Wshadow) To: Joao Paulo Rechi Vita Cc: Henrique Dante , Anderson Lizardo , linux-bluetooth@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-bluetooth-owner@vger.kernel.org List-ID: On Tue, Jun 19, 2012 at 3:29 PM, Joao Paulo Rechi Vita wrote: > On Fri, Jun 15, 2012 at 9:45 AM, Henrique Dante wrote: >> On Fri, Jun 15, 2012 at 9:43 AM, Henrique Dante wrote: >>> On Fri, Jun 15, 2012 at 9:29 AM, Anderson Lizardo >>> wrote: >>>> Hi Henrique, >>>> >>>> On Fri, Jun 15, 2012 at 8:04 AM, Henrique Dante de Almeida >>>> wrote: >>>>> --- >>>>> ?gdbus/object.c | ? 39 +++++++++++++++++++++------------------ >>>>> ?gdbus/watch.c ?| ? ?4 ++-- >>>>> ?2 files changed, 23 insertions(+), 20 deletions(-) >>>> >>>> Would it be interesting to add this option to acinclude.m4? Or does it >>>> generate too much noise? >>> >>> ?It generates few warnings. Depending on the acceptance of this patch, >>> I could fix bluez as a whole and add -Wshadow to acinclude.m4. >> >> ?Actually, I had a partial build here. Ignore the previous answer, it >> generates a lot of warnings. >> > > If we're not going to enable -Wshadow by default, does it make sense > to apply this patch? Who is going to check if no new shadow warnings > are being inserted in new commits? I'm all for doing the following: 1) Fix all the places with shadow variables 2) Add -Wshadow to the warning flags There are lots of them. Lucas De Marchi