Re: Results of static analysis with clang static analyser

[Jens Gustedt <jens.gustedt@inria.fr>]

[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]

Am Mittwoch, den 23.09.2015, 15:38 -0400 schrieb Rich Felker:
> On Tue, Sep 22, 2015 at 10:58:55PM -0700, Khem Raj wrote:
> > Hi All
> > 
> > I have run scan-build on musl-git and here are results
> > 
> > http://busybox.net/~kraj/scan-build-2015-09-22-224330-15962-1/
> 
> At a quick glance, most of these seem to be cases of assuming system
> calls do not store to the objects they receive pointers to.

Some of them, yes. But the one in __memalign seems to have secret
knowledge that it may access header information preceeding the pointer
that was received from malloc. I have no idea what a compiler in a
freestanding environment is allowed (or not) to assume in that case.

Perhaps it would be cleaner to have a malloc_helper function that
returns the veritable start of the reserved chunk and then the user
interface wrappers such as malloc and friends return that address plus
the necessary offset.

> This makes
> them false positives, but if llvm is actually making that same
> assumption when optimizing that could be a bug in itself. Hopefully
> it's just treating it as "unknown" whether the object is stored to,
> rather than "definitely not accessed".

The one in pthread_create I always struggle with. I remember that I
had myself once convinced (or was it you?) that the bad case can't
happen, but I was not able to reproduce the argument spontaneously.

Jens

-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::





[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]