OK.
On Sun, Oct 30, 2016 at 3:53 PM, Mark Wielaard wrote:
> On Tue, Oct 25, 2016 at 01:57:09AM +0200, Mark Wielaard wrote:
>> I think the only thing "blocking" the patch from going in is that
>> nobody made a decission on how the actual warning option should be
>> named. I think
when -Wshadow was given.
The documentation and code comments were updated to refer to the
new -Wshadow=... variants.
OK to commit the attached patch?
Thanks,
Mark
>From 390697e924926d7f8e451d39114de4903db07325 Mon Sep 17 00:00:00 2001
From: Mark Wielaard <m...@redhat.com>
Date: Sun, 1
On Mon, Oct 24, 2016 at 04:26:49PM -0700, Jim Meyering wrote:
> I have been using these new options (locally patched) to good effect.
> While the vast majority of warning-triggering code has been
> technically correct, using these has uncovered at least 4 or 5 real
> bugs in code I care about.
On Wed, Sep 14, 2016 at 5:49 AM, Mark Wielaard wrote:
> On Wed, 2016-09-14 at 05:39 -0700, Ian Lance Taylor wrote:
>> On Wed, Sep 14, 2016 at 1:30 AM, Mark Wielaard wrote:
>> > On Wed, 2016-09-14 at 00:00 -0400, Jason Merrill wrote:
>> >> I wonder about spelling
On Wed, 2016-09-14 at 05:39 -0700, Ian Lance Taylor wrote:
> On Wed, Sep 14, 2016 at 1:30 AM, Mark Wielaard wrote:
> > On Wed, 2016-09-14 at 00:00 -0400, Jason Merrill wrote:
> >> I wonder about spelling the options as
> >> -Wshadow={local,compatible-local} rather than with a
On Wed, Sep 14, 2016 at 1:30 AM, Mark Wielaard wrote:
> On Wed, 2016-09-14 at 00:00 -0400, Jason Merrill wrote:
>> I wonder about spelling the options as
>> -Wshadow={local,compatible-local} rather than with a dash, but
>> otherwise the patch looks fine.
>
> That is a much nicer
On 9/14/16, Jason Merrill wrote:
> On Mon, Sep 12, 2016 at 1:38 PM, Jim Meyering wrote:
>> On Mon, Sep 12, 2016 at 7:05 AM, Eric Gallager
>> wrote:
>>> On 9/11/16, Manuel López-Ibáñez wrote:
On 11/09/16
On Wed, 2016-09-14 at 00:00 -0400, Jason Merrill wrote:
> I wonder about spelling the options as
> -Wshadow={local,compatible-local} rather than with a dash, but
> otherwise the patch looks fine.
That is a much nicer way to write the option. But if I do that I would
like to keep the old names as
On Mon, Sep 12, 2016 at 1:38 PM, Jim Meyering wrote:
> On Mon, Sep 12, 2016 at 7:05 AM, Eric Gallager wrote:
>> On 9/11/16, Manuel López-Ibáñez wrote:
>>> On 11/09/16 14:02, Mark Wielaard wrote:
-Wshadow-local which warns if
On Mon, Sep 12, 2016 at 7:05 AM, Eric Gallager wrote:
> On 9/11/16, Manuel López-Ibáñez wrote:
>> On 11/09/16 14:02, Mark Wielaard wrote:
>>> -Wshadow-local which warns if a local variable shadows another local
>>> variable or parameter,
>>>
>>>
On 9/11/16, Manuel López-Ibáñez wrote:
> On 11/09/16 14:02, Mark Wielaard wrote:
>> -Wshadow-local which warns if a local variable shadows another local
>> variable or parameter,
>>
>> -Wshadow-compatible-local which warns if a local variable shadows
>> another
he rate of false positive
is (plus maybe some examples to show whether one might or might not want
to fix them anyway) then we can see if it makes sense. But I believe that
should be done independent from introducing the new warnings themselves.
Thanks,
Mark
Attached v2 of the patch with the sugge
On 11/09/16 14:02, Mark Wielaard wrote:
-Wshadow-local which warns if a local variable shadows another local
variable or parameter,
-Wshadow-compatible-local which warns if a local variable shadows
another local variable or parameter whose type is compatible with that
of the shadowing
On Sat, Sep 10, 2016 at 09:51:57AM -0400, Eric Gallager wrote:
> On 9/10/16, Ian Lance Taylor wrote:
> > I'm not sure about the patch to configure.ac/configure. The last I
> > looked -Wshadow would warn if a local variable shadows a global
> > variable. That can cause a
14 matches
Mail list logo