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.
