From owner-freebsd-standards@FreeBSD.ORG Mon Dec 1 00:54:29 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06A4016A4CE for ; Mon, 1 Dec 2003 00:54:29 -0800 (PST) Received: from VARK.homeunix.com (adsl-68-121-163-164.dsl.pltn13.pacbell.net [68.121.163.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9383243FD7 for ; Mon, 1 Dec 2003 00:54:26 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.12.9/8.12.9) with ESMTP id hB18pten074675; Mon, 1 Dec 2003 00:51:55 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.9/8.12.9/Submit) id hB18psWn074674; Mon, 1 Dec 2003 00:51:54 -0800 (PST) (envelope-from das@FreeBSD.ORG) Date: Mon, 1 Dec 2003 00:51:54 -0800 From: David Schultz To: Bruce Evans Message-ID: <20031201085154.GA74618@VARK.homeunix.com> Mail-Followup-To: Bruce Evans , Steve Kargl , freebsd-standards@FreeBSD.ORG References: <20031129000133.GA30662@troutmask.apl.washington.edu> <20031129080911.GA25448@VARK.homeunix.com> <20031129163105.GA32651@troutmask.apl.washington.edu> <20031130213951.GA37082@VARK.homeunix.com> <20031201182219.O4431@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031201182219.O4431@gamplex.bde.org> cc: freebsd-standards@FreeBSD.ORG cc: Steve Kargl Subject: Re: Implementing C99's roundf(), round(), and roundl() X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2003 08:54:29 -0000 On Mon, Dec 01, 2003, Bruce Evans wrote: > And we really shouldn't do arithmetic on the NaNs. ceilf() should return > its arg for a NaN, but it's not clear what happens for -x. Well, I checked > what happens starting with the QNaN x= 0.0 / 0.0. Almost everything is > broken: > - gcc miscomputes 0.0 / 0.0 at compile time. It gives a positive NaN, but > the npx would give a negative NaN ("Real Indefinite" = the same one except > with the opposite sign). > - gcc invalidly optimizes -x by ORing in the sign bit (even without -O). > It should do the same as the npx (which is to not change anything). > - printf() doesn't print the sign bit for NaNs. > - C99 requires printf() to misspell "NaN" as "nan" I thought about that, but I didn't know that the distinction between positive and negative NaN mattered to anyone. If you ignore these distinctions, then any amount of arithmetic on a NaN does nothing, save the possibility of raising an exception. In this case, swapping the sense of the 'if' ought to fix the problem, although an isnan() check could be added instead to be on the safe side. > All the other corner cases need to be checked. It's possibly to check > all 2^32 cases for floats (once you know the correct results). If I had a better way to compute the correct results, I'd commit that instead. ;-P (Okay, actually, I could just use the npx.) > Other things to check: setting of exception flags. I'm not sure if the > settings by ceil() are the right ones and the only ones. What little POSIX says about flags seems to be identical for ceil() and round().