>I think that you're being far too optimistic about your ability to
>detect and report valid issues using these static analysis tools. It's
>not possible to apply the information they provide without a high
l>evel understanding of the design of the code. There are already quite
>a few full time Postgres hackers that use tools like Coverity all the
>time.
I've been programming in C for a long time, and I'm getting better every day, I believe.
I'll arrive there.
>While it's certainly true that PageGetMaxOffsetNumber cannot in
>general be trusted to be > 0, we're talking about code that exists to
>deal with pages that are already full, and need to be split. It is
>impossible for "maxoff" to underflow, even if you deliberately corrupt
>a page image using a tool like pg_hexedit. Even if we failed to be
>sufficiently defensive about such a case (which is not the case), it
>wouldn't make any sense to fix it in this specific esoteric function,
>which is called when we've already decided to split the page (but only
>sometimes).
At this point you are right. I hope that in the future anyone who will use _bt_afternewitemoff will remember this
hiddendanger.
> Sanitization needs to happen at some central choke point.
Surely that would be the best solution. But this is not a function of a static analysis tool.
>I strongly suggest confining all of this to a single thread, and
>stating your reasoning upfront.
I don't know what that means.
Best regards.
Ranier Vilela