Am Sonntag, den 16.06.2013, 11:31 -0400 schrieb Rich Felker:
> > > > Also for calloc I am not sure that when we switch off the false
> > > > positive (where musl assumes a certain gcc behavior for what in
> > > > general is UB)
> > > 
> > > musl is not assuming any gcc behavior.
> > 
> > unfortunately it does. as an optimization shortcut it reads the newly
> > allocated bytes and if they are already 0, it doesn't write to
> > them.
> 
> This is not gcc behavior.

yes, I think it is gcc+platform behavior. the C standard makes no
guarantee that this

   if (*z) *z=0;

guarantees that *z is observably 0 afterwards. And the problem is not
that *z could be UB (if size_t had traps) but that there is no
guarantee that an undetermined value is stable between two reads (the
first with that "if" and the second from the application that receives
this).

> It's behavior of it's own implementation of
> malloc. From the implementation's standpoint, the object returned by
> malloc does not have indeterminate value; otherwise it would be
> impossible to link it with its bookkeeping information, contained in
> the header of the object, and to later free it. In other words, if you
> required the implementation to treat malloc as a black box, it would
> be impossible to implement free.

I agree with all of this, if you can guarantee that the memory *is*
effectively zero'ed after calloc. With the current implementation in
musl you can only do that with additional knowledge about the
platform.

Jens

-- 
:: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/   ::
:: AlGorille ::::::::::::::: office Nancy : +33 383593090   ::
:: ICube :::::::::::::: office Strasbourg : +33 368854536   ::
:: ::::::::::::::::::::::::::: gsm France : +33 651400183   ::
:: :::::::::::::::::::: gsm international : +49 15737185122 ::