On Tue, Jun 19, 2012 at 6:41 PM, Lucas De Marchi <lucas.demarchi@xxxxxxxxxxxxxx> wrote: > On Tue, Jun 19, 2012 at 3:29 PM, Joao Paulo Rechi Vita > <jprvita@xxxxxxxxxxxxx> wrote: >> On Fri, Jun 15, 2012 at 9:45 AM, Henrique Dante <hdante@xxxxxxxxxxxxxx> wrote: >>> On Fri, Jun 15, 2012 at 9:43 AM, Henrique Dante <hdante@xxxxxxxxxxxxxx> wrote: >>>> On Fri, Jun 15, 2012 at 9:29 AM, Anderson Lizardo >>>> <anderson.lizardo@xxxxxxxxxxxxx> wrote: >>>>> Hi Henrique, >>>>> >>>>> On Fri, Jun 15, 2012 at 8:04 AM, Henrique Dante de Almeida >>>>> <hdante@xxxxxxxxxxxxxx> 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. > Yes, that makes sense. -- João Paulo Rechi Vita Openbossa Labs - INdT -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
