From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Peter Smith <smithpb2250(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Remove shadowed declaration warnings |
Date: | 2024-09-12 00:58:19 |
Message-ID: | CAApHDvpkr2TdZss4amJGXh0cxVzU+DHpphnmgE89Qazb58Vc6w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 12 Sept 2024 at 12:33, Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> I normally build the code with warnings enabled (specifically,
> -Wshadow) which exposes many "shadowed" declarations.
>
> It would be better to reduce warnings wherever it's easy to do so,
> because if we always see/ignore lots of warnings then sooner or later
> something important may escape attention. In any case, just removing
> these warnings sometimes makes the code more readable by removing any
> ambiguity.
0fe954c28 did add -Wshadow=compatible-local to the standard set of
complication flags. I felt it was diminishing returns after that, but
-Wshadow=local would be the next step before going full -Wshadow.
There was justification for -Wshadow=compatible-local because there
has been > 1 bug (see af7d270dd) fixed that would have been found if
we'd had that sooner. Have we ever had any bugs that would have been
highlighted by -Wshadow but not -Wshadow=compatible-local? I'd be
curious to know if you do go through this process of weeding these out
if you do find any bugs as a result.
I also wonder if we could ever get this to a stable point. I didn't
take the time to understand what 388e80132 did. Is that going to
protect us from getting warnings where fixing them is beyond our
control for full -Wshadow?
David
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2024-09-12 01:05:25 | Re: Incremental Sort Cost Estimation Instability |
Previous Message | Peter Smith | 2024-09-12 00:32:50 | Remove shadowed declaration warnings |