Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrey Smirnov <andrew.smirnov@gmail.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH 18/348] Fix -Wsahdow warnings
Date: Fri, 25 Nov 2011 00:48:00 -0000	[thread overview]
Message-ID: <CAHQ1cqGEctu8NQ6hHAbz1oC5x_M0Uc_gp-FZr3Fav_LEZrHwaQ@mail.gmail.com> (raw)
In-Reply-To: <20111124220057.GU13809@adacore.com>

On Fri, Nov 25, 2011 at 5:00 AM, Joel Brobecker <brobecker@adacore.com> wrote:
> Andrey,
>
> I understand your fustration towards the tone of some of the messages.
> Hopefully things will be better from now on.
>
> And I agree that not enabling -Wshadow by default will let the number
> of such conflict increase again over time. But at the same time, now
> that I am seeing the changes that are required to fix these, I am not
> very happy either.  I mean, I understand that "index" might be part of
> a system's include.

> But "block_found" (or was it "found_block") seems
> quite surprising.

Thanks for bringing that up, that is, IMHO, an excellent example.
The `block_found' in function conflicts with global variable declared
in symtab.c and it is not that just their names match, types are very
similar too one is `struct block **' another is `const struct *block'.

But for the sake of argument let's assume that this will never cause
any bugs. I say this shadowing still should be resolved because it
makes source code, at least in my experience, harder to understand: on
one hand in `ada_lookup_encoded_symbol' `block_found' is function
parameter used to return result, on the other hand in
`standard_lookup' it is a global variable from symtab.c, rather confusing.

I say the whole situation is exactly why -Wshadow should be enabled.

> Add the fact that includes and compiler vary from
> system to system, and we're not sure that once clean on one machine,
> it'll be clean everywhere else. All of this to fix warnings that,
> as far as I could tell for the most part, did not indicate an actual
> bug in the code.

I've been humbled by the compiler and the machine too many times to
think my bug spotting capabilities for all intents and purposes are
any greater than zero, so my perspective at this is buggy until
formally proven to be bug-free. And from my view your argument sounds
really different: It means that we potentially can have a bug that is
only reproducible on a certain mix of a compiler and the platform, now
I don't mind fixing very well reproducible bugs, it this kind of
once-in-a-blue-moon kind of bugs that I hate very passionately.

> This is why I am left wondering (meaning I haven't decided yet)
> whether the idea of enabling -Wshadow was such a good idea after
> all. I know that looking at the warnings allowed you to spot some
> areas where there definitely is a mistake, and so that's useful.
> I'm not disputing that.

But that tool is only available if the source tree in question can be
compiled with -Wshadow, otherwise it is "checking for possible mistakes
up until, in the order of source file compilation, the first
legitimate shadowing".

> But I'm not convinced by a good number of the patches I've seen, and
> I still haven't decided whether to accept the situation and approve
> them, or not. For that, I asked everyone else' opinion.

Well, now that I made my case, I hope you reserve negative judgment
until the whole patchset is presented.

Andrey Smirnov.


  reply	other threads:[~2011-11-25  0:48 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-22 13:01 Andrey Smirnov
2011-11-22 18:03 ` Tom Tromey
2011-11-23 16:36 ` Mark Kettenis
2011-11-23 16:41   ` Ulrich Weigand
2011-11-23 18:21     ` Pedro Alves
2011-11-23 18:42       ` Joel Brobecker
2011-11-23 20:24       ` Mark Kettenis
2011-11-24  4:16         ` Andrey Smirnov
2011-11-24 11:36           ` Eli Zaretskii
2011-11-24 22:01           ` Joel Brobecker
2011-11-25  0:48             ` Andrey Smirnov [this message]
2011-11-25 14:26               ` Joel Brobecker
2011-11-25 15:52                 ` About adding -Wshadow option by default (was Re: [PATCH 18/348] Fix -Wsahdow warnings) Pierre Muller
2011-11-25 16:36                   ` Mark Kettenis
2011-11-29 19:18                 ` [PATCH 18/348] Fix -Wsahdow warnings Tom Tromey
2011-11-30  3:48                   ` Andrey Smirnov
2011-11-30 14:59                     ` Tom Tromey
2011-12-01  4:15                       ` Andrey Smirnov
2011-12-02 17:08                         ` Tom Tromey
2011-11-25 12:03             ` Eli Zaretskii
2011-11-25 15:11               ` Mark Kettenis
2011-11-25 15:41                 ` Eli Zaretskii
2011-11-25 16:26                   ` Mark Kettenis
2011-11-25 18:20                     ` Eli Zaretskii
2011-11-27 13:53                       ` Mark Kettenis
2011-11-27 14:55                         ` Pedro Alves
2011-11-27 16:35                         ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAHQ1cqGEctu8NQ6hHAbz1oC5x_M0Uc_gp-FZr3Fav_LEZrHwaQ@mail.gmail.com \
    --to=andrew.smirnov@gmail.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox