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) || \
(errorType), \
__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.


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:

Reply via email to