On Thu, Jul 16, 2009 at 7:47 PM, Nicholas
Nethercote wrote:
> On Fri, Jul 17, 2009 at 2:16 AM, Zachary Turner
> wrote:
>> --track-origins=yes I find that the memory it's claiming is
>> uninitialized comes from sbrk(). As far as I can tell (please correct
>> me if I'm wrong) this function is guara
On Fri, Jul 17, 2009 at 2:16 AM, Zachary Turner wrote:
> --track-origins=yes I find that the memory it's claiming is
> uninitialized comes from sbrk(). As far as I can tell (please correct
> me if I'm wrong) this function is guaranteed to return 0-filled
> memory
I'm not at all certain this is th
On 16/07/09 19:23, Tim Post wrote:
> Then there's the corner case, when you are provided only with static
> libs to link with. In that case, do what you can. However, that remains
> a corner case :)
There is no problem linking with static libraries in general, so long as
you don't make the progr
On Thu, 2009-07-16 at 11:16 -0500, Zachary Turner wrote:
> Assuming this assessment is accurate, is it best to deal with this by
> adding appropriate suppressions to the default suppressions file, or
> by modifying valgrind to be smarter and know that sbrk memory is
> always 0-filled?
Its best to
On 16/07/09 17:16, Zachary Turner wrote:
> When I build any program (including an empty main function) using gcc
> -static I get enormous amounts of errors in valgrind. After some
> investigation and asking around I think that at least a large portion
> of them are incorrect. In particular, I ge
When I build any program (including an empty main function) using gcc
-static I get enormous amounts of errors in valgrind. After some
investigation and asking around I think that at least a large portion
of them are incorrect. In particular, I get many errors about
uninitialized memory and condi
