On 2013-11-12 15:17:18 -0500, Jeffrey Walton wrote:
> On Tue, Nov 12, 2013 at 9:38 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> > ...
> >
> > 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.
> Clang can be trained with asserts.
It might not recognize our Assert() because it expands as:
#define TrapMacro(condition, errorType) \
((bool) ((! assert_enabled) || ! (condition) || \
(ExceptionalCondition(CppAsString(condition),
(errorType), \
__FILE__,
__LINE__), 0)))
#define Assert(condition) \
Trap(!(condition), "FailedAssertion")
Kevin, perhaps it reports less errors if you remove the assert_enabled
check from TrapMacro? I guess you already compiled with --enable-cassert?
> Or, you could check it for NULL and fail the function if the param is
> NULL. If its a spurious test, then the optimizer will remove it.
Only in the case it can prove that it's redundant - and in that case the
analyzer presumably wouldn't have reported the error in the first place.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
