From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12692 Path: news.gmane.org!.POSTED!not-for-mail From: "dgutson ." Newsgroups: gmane.linux.lib.musl.general Subject: Re: catan errors Date: Tue, 10 Apr 2018 17:23:12 -0300 Message-ID: References: <20180410195007.GI3094@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a114c5194b4853a0569844a44" X-Trace: blaine.gmane.org 1523391684 28013 195.159.176.226 (10 Apr 2018 20:21:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 10 Apr 2018 20:21:24 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12708-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 10 22:21:20 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1f5zlX-0007Au-An for gllmg-musl@m.gmane.org; Tue, 10 Apr 2018 22:21:19 +0200 Original-Received: (qmail 26313 invoked by uid 550); 10 Apr 2018 20:23:26 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 26291 invoked from network); 10 Apr 2018 20:23:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=JxrMSoyZg7X6qZVuqzqxlQD3aVJnRhBZsBDRW2wkslg=; b=J7BLORywwkUyEQZSdYNLpk0LlT5mzCdNpoUj8nEJkNDDNZiFDbzl7GdSH0N721A54o PSTxWTBdBGl8G+K9idlF8gt5ip4reIXrcyQrmO4CBzJDcdm2locG35IaS4QTSW7HLKB5 A8+5nXLlD+MX/sEmZNSjIegFmrA9f8QH1IMljm7uDNN+mOpTP1p5CPfYaTniLx+nNuZV xjGEJ5oFDxWaVD2qlxJRZwb8O9L0UGYhA5d+huX+IEbeNiUxjNMK8JxbcO0V9obuKcNO syMsE9ZUaTnfWf5zkdsK3CsvmGU4cRDXC7mwRnNXnggTmftuCwcJUoxNQn5gqzKxdgNq nXRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=JxrMSoyZg7X6qZVuqzqxlQD3aVJnRhBZsBDRW2wkslg=; b=sfacmn+7O9jifA7dmiZljfD/s7R7FklhWNvHrx6Qcbi2itxYEm7KbfwA5n+GyKzTJ6 siV8YiNmHqomqY56XwujqCrMW4llD9VAF9wVnOFdOekTEBJBEeK5d2C+4c9MfVoh231I LeL/ECdTlAEJg6LdfzNd/0PsK4Uvf43CcJqMORvfo9mMDEzKaDqfEFObYG+A2VF5Suxc p4yVzRJ/MMYWAOUc831nzPDYdA7mr9iSwOL0qGOwk37gcn5K5Aiypbup25AjfzhCgG6V TffysYmRdu2c6XPwKdt9f/w1CFwTBqBrHhS90qvJnZfNDxj4dpuO2gZmvapb8ZIsv1yK PjdQ== X-Gm-Message-State: ALQs6tBBNFeWpEvPcKhpNw/v8jkrTCc5SS0LaitAJhaxuYoobg5ne8yb v+xSj2MBGZHuvehd/HdwA+Ma0446fUxl0lReGoj57A== X-Google-Smtp-Source: AIpwx4/Z5ja9wDyKhKakJF3ji9zvke6esXL4RrGOtcx9DKeQzg0LF+RzATdX+vhipgSKdNjGhm1x31nN298nuSxHz94= X-Received: by 10.55.6.140 with SMTP id 134mr2727652qkg.232.1523391793495; Tue, 10 Apr 2018 13:23:13 -0700 (PDT) In-Reply-To: <20180410195007.GI3094@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:12692 Archived-At: --001a114c5194b4853a0569844a44 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 10, 2018 at 4:50 PM, Rich Felker wrote: > The OpenBSD catan implementation we're using has a number of > nonsensical "overflow" (goto ovrf) conditions that aren't errors, > reported by mepholic on irc. I think the attached patch fixes them > without introducing new problems, but I'm not sure if any other > problems remain. > > Note that, of the three cases removed: > > 1. Is not an exceptional case at all, and made no sense to begin with. > > 2. Is only exceptional if x and a are both zero; atan(2x,0) is > perfectly well-defined. > > 3. Is only possible if y=3D=3D1.0 and x=3D=3D0.0, which is the only real > exceptional case for atan: z=3D=3DI. > Besides the trigonometric case, are you considering de-normalized numbers, such as 4.94066e-324 as divisor? For example: double x =3D 1.0; double y =3D 5E-324; x / y is inf, and y !=3D 0.0. Shouldn't 'a' be checked against that number or its absolute value >=3D minimum? > > I opted to replace the non-obvious (3) with an explicit check for z=3D=3D= I > but this isn't necessary. > > As written the patch does not address raising exception flags; that > should be fixed before it's committed but right now I'm just > submitting this for comments. > > Prior to the patch, at least the following (utterly dumb -- the first > is a very real input!) cases are broken: > > - catan(1.0) > - catan(2*I) > - catan(I) > > Rich > --=20 Who=E2=80=99s got the sweetest disposition? One guess, that=E2=80=99s who? Who=E2=80=99d never, ever start an argument? Who never shows a bit of temperament? Who's never wrong but always right? Who'd never dream of starting a fight? Who get stuck with all the bad luck? --001a114c5194b4853a0569844a44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Apr 10, 2018 at 4:50 PM, Rich Felker <dalias@libc.org> wrote:
The OpenBS= D catan implementation we're using has a number of
nonsensical "overflow" (goto ovrf) conditions that aren't err= ors,
reported by mepholic on irc. I think the attached patch fixes them
without introducing new problems, but I'm not sure if any other
problems remain.

Note that, of the three cases removed:

1. Is not an exceptional case at all, and made no sense to begin with.

2. Is only exceptional if x and a are both zero; atan(2x,0) is
=C2=A0 =C2=A0perfectly well-defined.

3. Is only possible if y=3D=3D1.0 and x=3D=3D0.0, which is the only real =C2=A0 =C2=A0exceptional case for atan: z=3D=3DI.

=

Besides the trigonometric case, are you consideri= ng de-normalized numbers, such as=C2=A04.94066e-324 as divisor?
F= or example:
=C2=A0 =C2=A0 double x =3D 1.0;
=C2=A0= =C2=A0 double y =3D 5E-324;
x / y is inf, and y !=3D 0.0.<= /div>
Shouldn't 'a' be checked against that number or its a= bsolute value >=3D minimum?
=C2=A0

I opted to replace the non-obvious (3) with an explicit check for z=3D=3DI<= br> but this isn't necessary.

As written the patch does not address raising exception flags; that
should be fixed before it's committed but right now I'm just
submitting this for comments.

Prior to the patch, at least the following (utterly dumb -- the first
is a very real input!) cases are broken:

- catan(1.0)
- catan(2*I)
- catan(I)

Rich



--
Who=E2=80=99s got the sweetest disposition= ?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an a= rgument?
Who never shows a bit of temperament?
Who's never wrong = but always right?
Who'd never dream of starting a fight?
Who get = stuck with all the bad luck?
--001a114c5194b4853a0569844a44--