Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c) - Mailing list pgsql-hackers

From Ranier Vilela
Subject Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)
Date
Msg-id CAEudQAr_K3hfgRue++aR6xL5DCwd161mefkWUw--=2hFsFH-_w@mail.gmail.com
Whole thread Raw
In response to Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)
Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)
List pgsql-hackers
Em sex., 9 de out. de 2020 às 17:47, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
Ranier Vilela <ranier.vf@gmail.com> writes:
> The trap is not on the second part of expression. Is in the first.
> If the pointer is NULL, ExecCopySlot will be called.

Your initial comment indicated that you were worried about
IncrementalSortState's group_pivot slot, but that is never going
to be null in any execution function of nodeIncrementalSort.c,
because ExecInitIncrementalSort always creates it.

(The test whether it's NULL in ExecReScanIncrementalSort therefore
seems rather useless and misleading, but it's not actually a bug.)

The places that use TupIsNull are just doing so because that's
the standard way to check whether a slot is empty.  The null
test inside the macro is pointless in this context (and in a lot
of its other use-cases, too) but we don't worry about that.
So I said that TupIsNull was not the most appropriate.

Doesn't it look better?
(node->group_pivot != NULL && TTS_EMPTY(node->group_pivot))

regards,
Ranier Vilela

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)
Next
From: Peter Geoghegan
Date:
Subject: Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)