Re: valgrind problems

[Rich Felker <dalias@aerifal.cx>]

On Sun, Jun 16, 2013 at 05:58:52PM +0200, Jens Gustedt wrote:
> 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 not an indeterminate value. It's simply a value. Because malloc
is not special here. It's just like any other function defined in C
code on a freestanding implementation.

> > 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.

No, the only special knowledge musl is using is that it's part of a
hosted implementation written to be used on a freestanding
implementation (gcc -ffreestanding); in particular, the fact that
"malloc" is not the malloc function of a hosted implementation.

Rich