>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 hidden danger. > 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
