RE: [PATCH][BUG_FIX] Potential null pointer dereferencing.

Hi,
The condition is :
74. if (TupIsNull(slot)) is true
85. if (TupIsNull(resultTupleSlot)) is true too.

If resultTupleSlot is not can be NULL, why test if (TupIsNull(resultTupleSlot))?
Occurring these two conditions ExecClearTuple is called, but, don't check by NULL arg.

There are at least 2 more possible cases, envolving ExecClearTuple:
nodeFunctionscan.c and nodeWindowAgg.c

Best regards,
Ranier Vilela

________________________________________
De: Daniel Gustafsson <daniel(at)yesql(dot)se>
Enviado: terça-feira, 12 de novembro de 2019 13:43
Para: Ranier Vilela
Cc: PostgreSQL Hackers
Assunto: Re: [PATCH][BUG_FIX] Potential null pointer dereferencing.

> On 12 Nov 2019, at 14:07, Ranier Vilela <ranier_gyn(at)hotmail(dot)com> wrote:

> ExecClearTuple don't check por NULL pointer arg and according
> TupIsNull slot can be NULL.

I assume you are referring to the TupIsNull(resultTupleSlot) check a few lines
down in the same loop? If resultTupleSlot was indeed NULL and not empty, the
subsequent call to ExecCopySlot would be a NULL pointer dereference too. I
might be missing something obvious, but in which case can resultTupleSlot be
NULL when calling ExecUnique?

cheers ./daniel