Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 16 Jun 2013 13:39:16 +0200
From: Szabolcs Nagy <>
Subject: Re: valgrind problems

* Jens Gustedt <> [2013-06-16 12:43:08 +0200]:
> Am Sonntag, den 16.06.2013, 11:18 +0100 schrieb Justin Cormack:
> > It would be nice to ship a valgrind suppressions file shipped with
> > Musl to ignore these, I have always found it very helpful to have as a
> yes, I know about that possibility and already used this in the
> past. What would bother me more is that by switching of the check for
> strlen, e.g., valgrind wouldn't find real user code errors when I pass
> an uninitialized char[] to it. Switching off all the checks for the
> str*** functions would somehow be counter productive in the context of
> valgrind.

note that valgrind cannot emulate 80bit long double arithmetics
(uses 64bit arithmetics instead) which breaks floating-point
printf and strtod functions in musl (and most math code on x86
take slightly different code paths, some break badly)

so valgrind has issues with floating-point code and there were
limitations with threading as well

if the address sanitizer support works in gcc or clang that
might be a better option for catching memory errors

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.