From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32048 invoked from network); 23 Aug 2022 17:01:10 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 23 Aug 2022 17:01:10 -0000 Received: (qmail 32349 invoked by uid 550); 23 Aug 2022 17:01:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 32314 invoked from network); 23 Aug 2022 17:01:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc; bh=K2+XRtgjlQSD0yxoCm05MwHYUlEin0q1DwKm0F1sS8Q=; b=oEWK7BuQxhM5GxCh8a8Xg47/ixiNcIWIwXa/yrXaAV3AFnWZr11eHr0dqoZlTD/9Vg X6aL+DyXrBqT9a7If9WbhqvFYKtAO3luT32qRONU+1w0/QQuV8lWgCVR6aFizxW27UuE arq3AS9omigcw1+r5WPAsWl7iFxwa+PdVDx+cGsEULJXUK2AKs1pGZbBJw7ttjYXfzVC Vafe3r3y6WKyVoP5XO50lrEuPofGwobJbV+B0L9yRUsov4741SlGUqpQEExNDhNT9Ecd RZ/TlvI1GwqlOoo8GfaTBU6IdXVHRDWX/ZreFLf2EqN5LhcH0v5BjLGrdL36gnjQJMgJ r78w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc; bh=K2+XRtgjlQSD0yxoCm05MwHYUlEin0q1DwKm0F1sS8Q=; b=fREm/+b1N4yPmL9W3kbFdjfMcYyt7drYeXmuyp9fkGXaKENletysuZ46Y5wPpQawGV gN8DcfAc8IJjIZUBeQFNqmkOav4Pq/fmIr81xsNqt5BA9k3GNE+1CNLiVQFdUKNMp3Ms 6Vl0tUeGsff/q7H3Lj4xRihBD7isnav/Ztpbzxxe/KpJVksc9tRiMjGsEWZdxrt75V7M 9vYLA2PU4mumqG3HZNgbgDr24IZAGAnkyLHZJnrBgeQ2OeYblLVPKmxmIWi8z2sI0kjy dtAKKG2RiUUeKpE9MiPIC+sqd0ICb+5ZAGrqd7Z1X7JVP6QFsEShIy78oE+hKvJ+4dpE Fvhg== X-Gm-Message-State: ACgBeo07NqATL0aIjW9diwvuhXVYfNhpXS1qYYD+lgATFP2TqpGcgoqH TL6xZGLJdQBDtJRlpPT6AJLz5ayt6/FMx8JA3PQ= X-Google-Smtp-Source: AA6agR6HOB9CTsnlPHEz0fFMUOwvQ1zBEGYFVS9swpGQqaHd2X7zx1pmPcU790mdvAI4tWvodbsRBw4YIAYUT8mNUE0= X-Received: by 2002:a05:6638:12c9:b0:343:5dee:27dc with SMTP id v9-20020a05663812c900b003435dee27dcmr12727358jas.309.1661274052015; Tue, 23 Aug 2022 10:00:52 -0700 (PDT) MIME-Version: 1.0 References: <20220819031934.GH7074@brightrain.aerifal.cx> In-Reply-To: <20220819031934.GH7074@brightrain.aerifal.cx> From: ardi Date: Tue, 23 Aug 2022 19:00:41 +0200 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Do you recommend using fmt_fp() and On Fri, Aug 19, 2022 at 5:19 AM Rich Felker wrote: > > On Thu, Aug 18, 2022 at 05:51:26PM +0200, ardi wrote: > > Hi, > > > > I'm looking for a small and robust dtoa-like implementation for quad > > floats (IEEE binary128) [...] > > > I think the fmt_fp code is a very good choice for this. It's basically > the minimal, dependency-free, most straightforward way of doing > exact/correctly-rounded binary floating point to decimal conversion, > and it doess not depend in any way on the format of the long double > type, just knowing the parameters (MANT_DIG, MAX_EXP), and being able > to do a very minimal amount of math on the floating point type to > extract the mantissa and to determine rounding behavior to match the > floating point type's. > > If you don't have the equivalent of frexpl you can even do that part > with portable arithmetic on the floating point type. At one point long > ago I think I even had a version of the code that did that, but it > doesn't seem to have ever been in musl proper. It probably predated > musl. > > The same should apply to the floatscan.c code if you need the other > direction conversion too. It's just a direct dependency-free version > of the minimal bignum logic needed to do it. Thanks a lot. I'm working on adapting it at the moment! One question, though, because I don't know the musl internals, and I'm defining a custom FILE struct that has only the fields used by the shgetc.c source file: Can the __uflow() invocation at line 23 of shgetc.c be called for string pseudo-FILEs, or is it guaranteed that it will be called for real FILE objects only? I ask the question because __uflow() drives into the stdio internals, and I'd prefer to avoid that (I'm implementing the fp<>string code for strings only). Kind regards and thanks a lot! C=C3=A9sar