Re: Avoid a possible out-of-bounds access (src/backend/optimizer/util/relnode.c)

Поиск
Список
Период
Сортировка
От Ranier Vilela
Тема Re: Avoid a possible out-of-bounds access (src/backend/optimizer/util/relnode.c)
Дата
Msg-id CAEudQAoDFONwejH8ZSBBq5jeQnweNDWFcCdH=Z94MntH6pdsTg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Avoid a possible out-of-bounds access (src/backend/optimizer/util/relnode.c)  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: Avoid a possible out-of-bounds access (src/backend/optimizer/util/relnode.c)  (Abhijit Menon-Sen <ams@toroid.org>)
Re: Avoid a possible out-of-bounds access (src/backend/optimizer/util/relnode.c)  (David Rowley <dgrowleyml@gmail.com>)
Список pgsql-hackers
Em qua., 27 de set. de 2023 às 04:35, David Rowley <dgrowleyml@gmail.com> escreveu:
On Wed, 27 Sept 2023 at 06:10, Ranier Vilela <ranier.vf@gmail.com> wrote:
> As suggested, casting is the best option that does not add any overhead and improves the robustness of the find_base_rel function.
> I propose patch v1, with the additional addition of fixing the find_base_rel_ignore_join function,
> which despite not appearing in Coverity reports, suffers from the same problem.

Can you confirm that this silences the Converity warning?
CID#1518088
This is a historical version of the file displaying the issue before it was in the Fixed state.


I think it probably warrants a comment to mention why we cast to uint32.

e.g. /* perform an unsigned comparison so that we also catch negative
relid values */
I'm ok.
 

> Taking advantage, I also propose a scope reduction,
>  as well as the const of the root parameter, which is very appropriate.

Can you explain why adding the const qualifier is "very appropriate"
to catching negative relids?
Of course that has nothing to do with it.


Please check [1] for the mention of:

"The fastest way to get your patch rejected is to make unrelated
changes. Reformatting lines that haven't changed, changing unrelated
comments you felt were poorly worded, touching code not necessary to
your change, etc. Each patch should have the minimum set of changes
required to work robustly. If you do not follow the code formatting
suggestions above, expect your patch to be returned to you with the
feedback of "follow the code conventions", quite likely without any
other review."
Forgive my impulsiveness, anyone who loves perfect, well written code, would understand.

Do you have an objection to fixing the function find_base_rel_ignore_join?
Or is it included in unrelated changes?

Ranier Vilela

В списке pgsql-hackers по дате отправления:

Предыдущее
От: tender wang
Дата:
Сообщение: Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()
Следующее
От: Tom Lane
Дата:
Сообщение: Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)