Heikki Linnakangas <[email protected]> writes:
> Pushed 0001 as commit 6f5ad00ab7.
This commit has caused Coverity to start complaining that
most of ginExtractEntries() is unreachable:
*** CID 1691468: Control flow issues (DEADCODE)
/srv/coverity/git/pgsql-git/postgresql/src/backend/access/gin/ginutil.c: 495
in ginExtractEntries()
489 /*
490 * Scan the items for any NULLs. All NULLs are considered
equal, so we
491 * just need to check and remember if there are any. We remove
them from
492 * the array here, and after deduplication, put back one NULL
entry to
493 * represent them all.
494 */
>>> CID 1691468: Control flow issues (DEADCODE)
>>> Execution cannot reach this statement: "hasNull = false;".
495 hasNull = false;
496 if (nullFlags)
497 {
498 int32 numNonNulls = 0;
499
500 for (int32 i = 0; i < nentries; i++)
Evidently, it does not realize that the extractValueFn() can change
nentries from its initial value of zero. I wouldn't be too surprised
if that's related to our casting of the pointer to uintptr_t --- that
may cause it to not see the passed pointer as a potential reference
mechanism.
I would just write that off as Coverity not being smart enough, except
that I'm worried that some compiler might make a similar deduction and
break the function completely. Was the switch to a local variable
for nentries really a useful win performance-wise?
regards, tom lane
