Re: Clang 3.3 Analyzer Results
От | Jeffrey Walton |
---|---|
Тема | Re: Clang 3.3 Analyzer Results |
Дата | |
Msg-id | CAH8yC8knrbE2r=g=oEri739SQnuMnZjWhoY09-Pz40Nu+8pWXw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Clang 3.3 Analyzer Results (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Clang 3.3 Analyzer Results
|
Список | pgsql-hackers |
On Tue, Nov 12, 2013 at 9:38 AM, Tom Lane <tgl@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. If you are certain that a parameter cannot be NULL, then pass the knowledge onto Clang: assert(param != NULL). Clang will stop analyzing that path for NULL-ness. 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. Jeff
В списке pgsql-hackers по дате отправления: