From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3418 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: valgrind problems Date: Sun, 16 Jun 2013 13:39:16 +0200 Message-ID: <20130616113916.GC6548@port70.net> References: <1371333657.16425.350.camel@eris.loria.fr> <20130615221627.GB6548@port70.net> <20130616054006.GJ29800@brightrain.aerifal.cx> <1371367371.16425.363.camel@eris.loria.fr> <1371375118.16425.368.camel@eris.loria.fr> <1371379388.16425.372.camel@eris.loria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1371382768 22767 80.91.229.3 (16 Jun 2013 11:39:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Jun 2013 11:39:28 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3422-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jun 16 13:39:29 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UoBIu-0007XH-3F for gllmg-musl@plane.gmane.org; Sun, 16 Jun 2013 13:39:28 +0200 Original-Received: (qmail 17488 invoked by uid 550); 16 Jun 2013 11:39:27 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 17477 invoked from network); 16 Jun 2013 11:39:27 -0000 Content-Disposition: inline In-Reply-To: <1371379388.16425.372.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3418 Archived-At: * 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