From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1HTQng-0000ZK-NB
	for qemu-devel@nongnu.org; Mon, 19 Mar 2007 18:58:00 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1HTQne-0000SA-6E
	for qemu-devel@nongnu.org; Mon, 19 Mar 2007 18:57:59 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1HTQnd-0000S3-QV
	for qemu-devel@nongnu.org; Mon, 19 Mar 2007 17:57:57 -0500
Received: from mtaout02-winn.ispmail.ntl.com ([81.103.221.48])
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <jseward@acm.org>) id 1HTQm8-0004yS-7P
	for qemu-devel@nongnu.org; Mon, 19 Mar 2007 18:56:24 -0400
From: Julian Seward <jseward@acm.org>
Subject: Re: [Qemu-devel] [PATCH] softfloat missing functions
Date: Mon, 19 Mar 2007 22:53:40 +0000
References: <1174291106.24702.9.camel@rapid>
	<200703192037.55757.jseward@acm.org>
	<1174338614.24702.23.camel@rapid>
In-Reply-To: <1174338614.24702.23.camel@rapid>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200703192253.40834.jseward@acm.org>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "J. Mayer" <l_indien@magic.fr>
Cc: qemu-devel@nongnu.org


Thinking about this more, you ask "is this correct", but that
is only meaningful if you say what the specification is.  
Correct relative to what?

> Yes, it seems to be the correct way, but thinking more about the
> problem, it appeared to me that the implementation could be even easier
> than yours. It seems to me that this may be sufficient:
> uint64_t float64_to_uint64 (float64 a STATUS_PARAM)
> {
>     int64_t v;
>
>     v = llrint(a + (float64)INT64_MIN);
>
>     return v - INT64_MIN;
> }

If a is NaN then so is the argument to llrint.  'man llrint' says:

  If x is infinite or NaN, or if the rounded value is
  outside  the  range  of  the  return type, the numeric result
  is unspecified. 

So then float64_to_uint64 produces an unspecified result.

It seems to me much safer to test and handle NaN, Inf and
out-of-range values specially.  However, even that does not help
unless you say what the specification is.

J