From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 10F1624103 for ; Sat, 13 Apr 2024 18:00:52 +0200 (CEST) Received: (qmail 2012 invoked by uid 550); 13 Apr 2024 16:00:45 -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 1976 invoked from network); 13 Apr 2024 16:00:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= ridiculousfish.com; h=cc:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1713024035; x=1713110435; bh=YilGw3amo2F+IVpXHRqgIdZgEcPqgv5MKLkOj6uDn2Q=; b= AyPRa75/vcDyrkFZlT1lWagn9vRry5OjzfXTVr+UpvDeKdx1ZEU7OUx3q9hp5XGi woe2FE/tBvnrpAWZE/05CV9b6ZLMMNm+HTGmLVHYfwwIA3GM4fAjBRuPMJirW0dK zmIvrVgluPrz7Hhck8Yziian+ABjElsidErw6+5lpKib3kG5ylIvnBpvQ75RPlp6 J1orksiqBhb0oJdBmyiEDcBSqEXWmxAoNx3dQR8eRM3QnNSZ3MojDTiqNqsLXQQ9 Ot/1KC/nUUM8LCtNuqGMCdd2yGQCwYFbfWnPlBlGxjYBY7HEL5Lk+Ut6Sdbnf6GY pyxLe5cYVNuUIwE55OXrRQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1713024035; x=1713110435; bh=YilGw3amo2F+IVpXHRqgIdZgEcPq gv5MKLkOj6uDn2Q=; b=GrLCKMc0Ai32fbuBPBZVBm245Lmyu3k2DxLVg3hBTaqD afXo27Ko4irhI7Mjnp7IcX651+JMgAXRHOmuys9IVMPJEe1oDcp6XdW44//OmOxd dyWyF1wsqt5wbqlF51lWGxv74+U9DOiyZ8VfuOqxFz16bnqbG+b787Cy8B+o1yOs 3ktLv0lSZdyw86xsGX4dOfMpkMTNb3x7HqsGhD5UesMjiTDinjo+UF1zTwUD6G23 lsCk/k0JDDcrIbVCxkILxWAlUDw16NcjK/X437DV9T7Oye/MkyruGgBA6tAWXouH lGVb185xfSwtkWq4pmjzNHwNsdoUcsRel4BzvHMtWA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudeiiedgleekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhtggguffffhfvjgfkofesrgdtmh erhhdtjeenucfhrhhomheprfgvthgvrhcutehmmhhonhcuoegtohhrhiguohhrrghssehr ihguihgtuhhlohhushhfihhshhdrtghomheqnecuggftrfgrthhtvghrnhepvddugfeufe eguddvtdeffedvueelueejffevjeduvddujefgjeejleffveefheegnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheptghorhihughorhgrshesrh hiughitghulhhouhhsfhhishhhrdgtohhm X-ME-Proxy: Feedback-ID: i0ec14495:Fastmail From: Peter Ammon Content-Type: multipart/alternative; boundary="Apple-Mail=_6C4038A0-10A5-4857-928B-85B310A2E635" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Date: Sat, 13 Apr 2024 09:00:19 -0700 References: <20240412195728.GE4163@brightrain.aerifal.cx> <20240412233310.GF4163@brightrain.aerifal.cx> To: musl@lists.openwall.com In-Reply-To: <20240412233310.GF4163@brightrain.aerifal.cx> Message-Id: <07FBEE99-778B-4A8C-B968-077B4515E000@ridiculousfish.com> X-Mailer: Apple Mail (2.3774.400.31) Subject: Re: [musl] [PATCH] Fix printf hex float formatting with precision --Apple-Mail=_6C4038A0-10A5-4857-928B-85B310A2E635 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Good catch on the overflow. Yes, that patch looks correct to me and I confirmed it fixes the issue on ARMv7. > On Apr 12, 2024, at 4:33=E2=80=AFPM, Rich Felker = wrote: >=20 > On Fri, Apr 12, 2024 at 03:57:28PM -0400, Rich Felker wrote: >> On Thu, Apr 11, 2024 at 06:17:25PM -0700, Peter Ammon wrote: >>> if (p>=3D0 && p<(LDBL_MANT_DIG-1+3)/4) { >>> int re =3D LDBL_MANT_DIG-1-(p*4); >>> long double round =3D 1ULL<>=20 >> This expression overflows. re can be as large as 108 but 1ULL has >> 64-bit type. >>=20 >> There's probably some reasonable way to write it that works for >> reasonable sizes of long double (I think it's safe to assume IEEE = quad >> is the max that will ever be supported), but I presume I wrote it = with >> the original inefficient loop to be fully general to arbitrary >> precision. >>=20 >> It could just be written to use scalbn, I think. At the time I >> probably was trying to avoid dependency on a libm that could have = been >> separate from libc (bad historical thing). IIRC there was a time when >> frexp was not used either. >=20 > Does the attached look ok? >=20 > Rich > --Apple-Mail=_6C4038A0-10A5-4857-928B-85B310A2E635 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Good catch on = the overflow. Yes, that patch looks correct to me and I
confirmed it = fixes the issue on ARMv7.

On Apr 12, 2024, at 4:33=E2=80=AFPM, Rich Felker = <dalias@libc.org> wrote:

On Fri, Apr 12, 2024 at 03:57:28PM -0400, = Rich Felker wrote:
On Thu, Apr 11, 2024 at 06:17:25PM -0700, Peter = Ammon wrote:
if (p>=3D0 && = p<(LDBL_MANT_DIG-1+3)/4) {
   int re =3D = LDBL_MANT_DIG-1-(p*4);
   long double round =3D = 1ULL<<re;

This expression overflows. re can be = as large as 108 but 1ULL has
64-bit type.

There's probably = some reasonable way to write it that works for
reasonable sizes of = long double (I think it's safe to assume IEEE quad
is the max that = will ever be supported), but I presume I wrote it with
the original = inefficient loop to be fully general to = arbitrary
precision.

It could just be written to use scalbn, I = think. At the time I
probably was trying to avoid dependency on a = libm that could have been
separate from libc (bad historical thing). = IIRC there was a time when
frexp was not used = either.

Does = the attached look ok?

Rich
<pct_a.diff><= /div>

= --Apple-Mail=_6C4038A0-10A5-4857-928B-85B310A2E635--