Re: [PATCH] Redudant initilization
| От | Ranier Vilela |
|---|---|
| Тема | Re: [PATCH] Redudant initilization |
| Дата | |
| Msg-id | CAEudQAqypX7SNG3t0YfofoOnQkgz0f+Aj8fCSrYX=5ymSgVBJg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [PATCH] Redudant initilization (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: [PATCH] Redudant initilization
Re: [PATCH] Redudant initilization |
| Список | pgsql-hackers |
Em sex., 4 de set. de 2020 às 14:40, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
Bruce Momjian <bruce@momjian.us> writes:
> I have to say, I am kind of stumped why compilers do not warn of such
> cases, and why we haven't gotten reports about these cases before.
I was just experimenting with clang's "scan-build" tool. It finds
all of the cases you just fixed, and several dozen more beside.
Quite a few are things that, as a matter of style, we should *not*
change, for instance
rewriteHandler.c:2807:5: warning: Value stored to 'outer_reloids' is never read
outer_reloids = list_delete_last(outer_reloids);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There are some like this, in the analyzes that I did.
Even when it is the last action of the function.
Even when it is the last action of the function.
Failing to update the list pointer here would just be asking for bugs.
However, I see some that look like genuine oversights; will go fix.
Thanks for fixing this.
(I'm not sure how much I trust scan-build overall. It produces a
whole bunch of complaints about null pointer dereferences, for instance.
If those aren't 99% false positives, we'd be crashing constantly.
It's also dog-slow. But it might be something to try occasionally.)
I believe it would be very beneficial.
it was sent but did not make the list.
Would you mind taking a look?
Certainly, if accepted, rebasing would have to be done.
Would you mind taking a look?
Certainly, if accepted, rebasing would have to be done.
regards,
Ranier Vilela
Вложения
В списке pgsql-hackers по дате отправления: