Re: [9fans] compiler double bug.

[Charles Forsyth <forsyth@terzarima.net>]

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.