From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
Cc: | Peter Geoghegan <pg(at)heroku(dot)com>, "noloader(at)gmail(dot)com" <noloader(at)gmail(dot)com>, Tomas Vondra <tv(at)fuzzy(dot)cz>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Clang 3.3 Analyzer Results |
Date: | 2013-11-12 14:38:22 |
Message-ID: | 5170.1384267102@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Kevin Grittner <kgrittn(at)ymail(dot)com> writes:
> Does anything stand out as something that is particularly worth
> looking into? Does anything here seem worth assuming is completely
> bogus because of the Coverity and Valgrind passes?
I thought most of it was obvious junk: if there were actually
uninitialized-variable bugs in the bison grammar, for instance, not only
we but half the programs on the planet would be coredumping all the time.
Not to mention that valgrind testing would certainly have caught it.
I'd suggest looking only at the reports that pertain to seldom-exercised
code paths, as those would be the places where actual bugs might possibly
have escaped notice.
One thought for the Clang people is that most of the reports such as "null
pointer dereference" presumably mean "I think I see an execution path
whereby we could get here with a null pointer". If so, it'd be awfully
helpful if the complaint included some description of what that path is.
I think Coverity does that, or at least I've seen output from some tool
that does it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2013-11-12 14:54:46 | Re: Clang 3.3 Analyzer Results |
Previous Message | Stephen Frost | 2013-11-12 14:33:51 | Re: Clang 3.3 Analyzer Results |
From | Date | Subject | |
---|---|---|---|
Next Message | Kohei KaiGai | 2013-11-12 14:45:43 | What's needed for cache-only table scan? |
Previous Message | Robert Haas | 2013-11-12 14:35:21 | Re: Row-security writer-side checks proposal |