From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4781 Path: news.gmane.org!not-for-mail From: Morten Welinder Newsgroups: gmane.linux.lib.musl.general Subject: Re: printf issues Date: Fri, 4 Apr 2014 10:35:00 -0400 Message-ID: References: <20140404141515.GD3034@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1396622119 19464 80.91.229.3 (4 Apr 2014 14:35:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Apr 2014 14:35:19 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4785-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 04 16:35:14 2014 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 1WW5D7-00057c-Em for gllmg-musl@plane.gmane.org; Fri, 04 Apr 2014 16:35:13 +0200 Original-Received: (qmail 7549 invoked by uid 550); 4 Apr 2014 14:35:12 -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 7539 invoked from network); 4 Apr 2014 14:35:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=VVtuP9m6S9sm9p3zzjQQ8LYZeQN+VIL1dt5mu+8sLSM=; b=paly+EdlbfB6GfsJSLpKvAZ7PYaHEcF3wcSLmpt+jyV11BGoioX6eb857O+5X5wkaD 97QVqUUrnQJTVHSDNxPQSbUUYeUdDcuCOAA5HAeKL+igRaJ0SlLZf67OkjPEV8nQ705h VuLvxjm8pO1zNj9sV62ATh9Eo1N60auvb3LeUUCCE4A1mP1aGOiAIzE7Atf03ezYudzh GbS4D3Ka4C7BnZ74c20I/lPownNHS15JCKm+sFK7Vl98gdepTlcpehHd6qwnPL5IMNJJ H3ne1e0aXHakiqsMeO5TR+BY9uNRBh+uoUsWYjb4hrRok0tY8AXueaa+e2A378nbHzl4 Fe+g== X-Received: by 10.194.241.132 with SMTP id wi4mr20742550wjc.14.1396622100901; Fri, 04 Apr 2014 07:35:00 -0700 (PDT) In-Reply-To: <20140404141515.GD3034@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:4781 Archived-At: > before you can mock libc code you need to educate yourself I did and that's why I called the code "cute", not "wrong". But if you read the porting documentation http://brightrain.aerifal.cx/~niklata/PORTING http://www.openwall.com/lists/musl/2012/07/08/1 you will notice that nowhere does it warn that defining LDBL_MANT_DIG as anything but a base-10 constant may cause printf-rounding to fail. > Do you have any ideas for a clean way to avoid this > assumption without having to compute the value at runtime? I don't know if ldexpl will get constant folded by the compiler, but if not, I think (2.0L/LDBL_EPSILON) ought to work as a replacement. It's not as likely to get prices at the obfuscated C contents, though. Morten On Fri, Apr 4, 2014 at 10:15 AM, Szabolcs Nagy wrote: > * Morten Welinder [2014-04-04 09:32:18 -0400]: >> Unrelatedly, from function fmt_fp: >> >> #define CONCAT2(x,y) x ## y >> #define CONCAT(x,y) CONCAT2(x,y) >> [...] >> long double round = CONCAT(0x1p,LDBL_MANT_DIG); >> >> That code is cute as a Hello Kitty door knocker, but really? Let's hope nobody >> gets the urge to define LDBL_MANT_DIG as 0100 or (80-16) or some such. > > before you can mock libc code you need to educate yourself > > LDBL_MANT_DIG is an identifier (macro definition) that is > defined by the libc itself (in arch/$ARCH/bits/float.h), > not by the application, nor by the compiler > > the libc can internally rely on a different contract about > the identifiers it defines, than application code that has > to rely on the external contracts specified by ISO C > > so outside the implementation you shouldn't use such a code > because there is no guarantee how LDBL_MANT_DIG is defined, > but internally the libc knows how it defined its symbols and > thus the code is perfectly reasonable > > (this distinction between public interface contracts and > implementation internal interface contracts is often > misunderstood: so don't copy-paste code between libc and > application code without thinking and don't try to reason > about APIs/ABIs used inside the libc based on the public > specification of those APIs/ABIs)