<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 14, 2015 at 5:11 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
  Jed suggested just passing requests for zero length malloc to malloc() and free() (claim is standards require them to behave properly  now a days) and remove all zero length checking from the macros. Will this resolve everything? Note that we need to pass a flag to --analyze telling it that zero length mallocs are ok otherwise it will generate some messages about them.<br></blockquote><div><br></div><div>I really do not want that. I am especially unwilling to do that just to appease static analysis.</div><div><br></div><div>  Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  Barry<br>
<br>
> On Apr 14, 2015, at 3:33 AM, Lisandro Dalcin <<a href="mailto:dalcinl@gmail.com">dalcinl@gmail.com</a>> wrote:<br>
><br>
> On 14 April 2015 at 02:46, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
>> On Mon, Apr 13, 2015 at 5:48 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
>>><br>
>>><br>
>>> When I run clang --analyze on PETSc on getting warnings of the type below,<br>
>>> any idea how to deal with them? Clearly these things are usually not null<br>
>>> pointers or PETSc would crash everywhere.<br>
>><br>
>><br>
>> Lisandro brought this up.<br>
>><br>
>> This is a problem with the analyzer. Anything that uses PetscMallocK() will<br>
>> be wrong since it can<br>
>> possibly be NULL. The limitations of static analysis are stark.<br>
>><br>
><br>
> There is a way to silent many of these false positives:<br>
><br>
> 1) First we need to solve the differences between PetscMalloc() and<br>
> PetscMallocK() regarding zero-size allocations.<br>
> 2) PetscMalloc1() is by far the most used of all the PetscMallocK()<br>
> routines. So we should make PetscMalloc1() a direct call to<br>
> PetscMalloc() (no checks for zero-sized allocs) and modify<br>
> PetscMalloc() to handle zero-sized allocations by setting the pointer<br>
> to NULL.<br>
><br>
> These simple changes will remove tons of "null pointer dereference"<br>
> false positives, and also fix the inconsistent behavior between<br>
> PetscMalloc() and PetscMallocK().<br>
><br>
><br>
> --<br>
> Lisandro Dalcin<br>
> ============<br>
> Research Scientist<br>
> Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)<br>
> Numerical Porous Media Center (NumPor)<br>
> King Abdullah University of Science and Technology (KAUST)<br>
> <a href="http://numpor.kaust.edu.sa/" target="_blank">http://numpor.kaust.edu.sa/</a><br>
><br>
> 4700 King Abdullah University of Science and Technology<br>
> al-Khawarizmi Bldg (Bldg 1), Office # 4332<br>
> Thuwal 23955-6900, Kingdom of Saudi Arabia<br>
> <a href="http://www.kaust.edu.sa" target="_blank">http://www.kaust.edu.sa</a><br>
><br>
> Office Phone: <a href="tel:%2B966%2012%20808-0459" value="+966128080459">+966 12 808-0459</a><br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</div></div>