[petsc-dev] clang --analyze messages on PETSc

[Barry Smith]

> On Apr 14, 2015, at 5:13 PM, Matthew Knepley <knepley at gmail.com> wrote:
> 
> On Tue, Apr 14, 2015 at 5:11 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> 
>   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.
> 
> I really do not want that. I am especially unwilling to do that just to appease static analysis.

  It is not to appease static analysis. It simplifies the code base so zero length mallocs are no longer a special case. What is the drawback?

  Barry

It was just a fluke of history that malloc(0) generated an error on some systems so we had to have special code to avoid it, but if we no longer need that special code why have it? Even if we do not ourselves call malloc() with zero length why not at least hide the special 0 case away inside the malloc() wrappers instead of making it visible by having the macros handle it?

> 
>   Matt
>  
>   Barry
> 
> > On Apr 14, 2015, at 3:33 AM, Lisandro Dalcin <dalcinl at gmail.com> wrote:
> >
> > On 14 April 2015 at 02:46, Matthew Knepley <knepley at gmail.com> wrote:
> >> On Mon, Apr 13, 2015 at 5:48 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> >>>
> >>>
> >>> When I run clang --analyze on PETSc on getting warnings of the type below,
> >>> any idea how to deal with them? Clearly these things are usually not null
> >>> pointers or PETSc would crash everywhere.
> >>
> >>
> >> Lisandro brought this up.
> >>
> >> This is a problem with the analyzer. Anything that uses PetscMallocK() will
> >> be wrong since it can
> >> possibly be NULL. The limitations of static analysis are stark.
> >>
> >
> > There is a way to silent many of these false positives:
> >
> > 1) First we need to solve the differences between PetscMalloc() and
> > PetscMallocK() regarding zero-size allocations.
> > 2) PetscMalloc1() is by far the most used of all the PetscMallocK()
> > routines. So we should make PetscMalloc1() a direct call to
> > PetscMalloc() (no checks for zero-sized allocs) and modify
> > PetscMalloc() to handle zero-sized allocations by setting the pointer
> > to NULL.
> >
> > These simple changes will remove tons of "null pointer dereference"
> > false positives, and also fix the inconsistent behavior between
> > PetscMalloc() and PetscMallocK().
> >
> >
> > --
> > Lisandro Dalcin
> > ============
> > Research Scientist
> > Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
> > Numerical Porous Media Center (NumPor)
> > King Abdullah University of Science and Technology (KAUST)
> > http://numpor.kaust.edu.sa/
> >
> > 4700 King Abdullah University of Science and Technology
> > al-Khawarizmi Bldg (Bldg 1), Office # 4332
> > Thuwal 23955-6900, Kingdom of Saudi Arabia
> > http://www.kaust.edu.sa
> >
> > Office Phone: +966 12 808-0459
> 
> 
> 
> 
> -- 
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
> -- Norbert Wiener