Re: [NBTREE] Possible NULL pointer dereference (backend/access/nbtree/nbutils.c)

On Wed, Sep 2, 2020 at 3:16 PM Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> wrote:
> Oh, I'm sorry, I thought that "hard crash" was a bad thing.

I think that you are being sarcastic here, but just in case I'm wrong
I'll clarify what I meant: a good sign that a static analysis tool has
produced a useless complaint is that it appears to prove something far
stronger than you first thought possible. You should look out for
that. This is just a heuristic, but in practice it is a good one.
Perhaps you recall our discussion of a similar false positive in
nbtsplitloc.c; that had a similar feel to it. For example, if your
static analysis tool says that code that has been around for many
years is riddled with bugs, then the problem is almost certainly with
the tool (or with how the tool has been used).

High performance C code very often relies on representational
invariants that may not be readily apparent to a compiler --
especially when dealing with on-disk state. Barring some obvious
problem like a hard crash, you have to do the work of assessing if the
code is correct based on the actual assumptions/context of the code. A
static analysis tool is of very little use if you're not going to put
the work in. I went to a lot of trouble to clearly document the code
in question here (the heap TID stuff in _bt_truncate()) -- did you
even bother to read those comments once?

--
Peter Geoghegan