From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <d893fc0b1d0b52a1dd610d7eb14279d3@terzarima.net>
From: Charles Forsyth <forsyth@terzarima.net>
Date: Tue,  1 Dec 2009 22:19:24 +0000
To: 9fans@9fans.net
In-Reply-To: <dc10137c2661c11595d2aa2ca370ba45@brasstown.quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: Re: [9fans] compiler double bug.
Topicbox-Message-UUID: a67b58ca-ead5-11e9-9d60-3106f5b1d025

oh! getival is yours? but it's in the changes on the - lines not the + lines.
the diffs have crossed the equator!
i think i understand now.

so the original had statements such as:
		wc = (int)getfval(x);
and for excessive values in x (that couldn't be represented as an int)
there was a trap. that seems consistent with the behaviour defined below:

6.3.1.4 Real floating and integer

When a finite value of real floating type is converted to integer type other than _Bool,
the fractional part is discarded (i.e., the value is truncated toward zero). If the value of
the integral part cannot be represented by the integer type, the behavior is undefined.[footnote 41]

[41] The remaindering operation performed when a value of integer type is converted to unsigned type
   need not be performed when a value of real floating type is converted to unsigned type. Thus, the
   range of portable real floating values is (−1, Utype_MAX+1).


so getival returning uint or ulong (or unsigned something-big-enough) avoids
the problem and seems fine to me.

there is, however, a bug in the compiler elsewhere, in that a suitable (uint) cast in a
direct assignment
	int x = (uint)doubleval;
is (apparently) discarded by the compiler, and it shouldn't be.
that shouldn't affect your getival cases, though.