In <[EMAIL PROTECTED]>, Kelly Yancey wrote:
> >
> > #include <stdio.h>
> > #include <limits.h>
> > #include <floatingpoint.h>
> >
> > int main(void)
> > {
> > double bla;
> > int foo;
> >
> > fpsetmask(0);
> > bla = (double)INT_MAX + 1.0;
> > foo = bla;
> >
> > printf("Result: %d\n", foo);
> >
> > return 0;
> > }
> >
> > Result: -2147483648
> >
> >
>
> Actually, this the same value (INT_MIN = -2147483648) you would get if
> you just said foo = INT_MAX + 1 since in 2's complement notation INT_MIN =
> INT_MAX + 1.
Try
bla = (double)INT_MAX * 13.0;
>It definately isn't garbage.
No, you're mislead by my example that happens to choose a value
combination that *looks* explainable. It in reality the results of
float->int conversions without range check are neither explainable nor
can you depend on them. They are just garbage when you disabled
exceptions.
You can draw some conclusions what happens on integer aritmetic
overflows (when you know the size of the operands). That is very
different from the float->int conversion results, which do not behave
in the usual integer overflow manner (although my first example looked
like they would).
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <[EMAIL PROTECTED]> http://www.cons.org/cracauer/
Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
