[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 16 Jun 2013 12:04:36 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: valgrind problems
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
