From: Andrey Smirnov <andrew.smirnov@gmail.com>
To: Tom Tromey <tromey@redhat.com>
Cc: Joel Brobecker <brobecker@adacore.com>,
gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH 18/348] Fix -Wsahdow warnings
Date: Thu, 01 Dec 2011 04:15:00 -0000 [thread overview]
Message-ID: <CAHQ1cqG3zZRhgCsar4Q4EUrQDG2hZ5v-W7=RWcgz_TE45Y8EMQ@mail.gmail.com> (raw)
In-Reply-To: <m3ty5lirlh.fsf@fleche.redhat.com>
On Wed, Nov 30, 2011 at 9:59 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Andrey" == Andrey Smirnov <andrew.smirnov@gmail.com> writes:
>
> Andrey> I hope that kinds of shadowing would still be detectable even with this
> Andrey> patch applied.
>
> Why is that?
Because when somebody decides to modify such a code and rename/remove
local variables, compiler will not warn them about any leftover pieces
of code referencing now renamed/non-existent variable. And on some
occasions that would lead to introduction of weird, not so easy to
reproduce bugs.
Although generally I think functionality introduced by that patch
should have been optional. In my opinion C gives one enough of an
arsenal to shoot their own foot, so while Mark is adamant that scalar
variables will never be the cause of a bug, I remain unconvinced and
still think that even such unlikely cause is still a cause. But then
again it is just my opinion, I do not have real world examples, and it
looks like my synthetic ones are not very persuasive.
> Andrey> It would pretty much solve that problem, yes, but still it would
> Andrey> divide patch submitters into two groups those who have newest gcc and
> Andrey> -Wshadow enabled by default, and those who don't. And the people
> Andrey> without -Wshadow enabled compilers would be, on occasion, breaking the
> Andrey> build because they have no means to check for -Wshadow caused errors.
> Andrey> I hope I missing something and it is not the case, but that how the
> Andrey> things seems to me now.
>
> Yes, I think it would result in some periodic breakage until the newer
> GCC is widely distributed. I'm willing to put up with that. We already
> put up with it, in a way, due to other GCC differences... see the
> uninitialized variable patches or FORTIFY_SOURCE patches that go in from
> time to time.
>
But those are pretty much the results we would get with enabling
-Wshadow on all versions of gcc but on a per-platform basis.
BTW I'm just playing Devil's advocate here, IMHO, your solution is
still better than no -Wshadow at all.
> If the configury part is set up properly, then this warning will simply
> auto-enable for people when they upgrade GCC. So, it isn't like we'll
> just forget about it; more like at some point we'll all be joining in :)
I wish this world would have less small, city-local companies, doing
embedded development whose version of GCC is fixed in stone because
the whole building system is so obscure to anyone that no one dares to
introduce any changes to it, and usually no one even cares. I used to
work in such a place, so I know that some people will be left behind.
:-)
Andrey Smirnov
next prev parent reply other threads:[~2011-12-01 4:15 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
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 [this message]
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='CAHQ1cqG3zZRhgCsar4Q4EUrQDG2hZ5v-W7=RWcgz_TE45Y8EMQ@mail.gmail.com' \
--to=andrew.smirnov@gmail.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.com \
/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