[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130616113916.GC6548@port70.net>
Date: Sun, 16 Jun 2013 13:39:16 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: valgrind problems
* Jens Gustedt <jens.gustedt@...ia.fr> [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.
