Exception when casting doubles to ints

Nick Burrett nick at sqrt.co.uk
Fri Jan 7 02:51:08 PST 2005


alan buckley said:
>>John Tytgat wrote:
>>
>>In message <BAY101-F254E3ED3F8DDFE11900C51F0930 at phx.gbl> you wrote:
>>
>> > It appears that when a double that is larger than the maximum
>> > int is cast to an int a floating point exception occurs. On cygwin
>> > you do not get an exception, and as the code where I found the
>> > problem was in lua I suspect other linux/unix variations also do not
>> > raise an exception. Can anyone confirm the unix behaviour?
>> >
>> > If this is the case should the RISC OS gcc match what unix does?

On x86/Linux, no error is reported and k = -2147483648.

>>Actually I don't mind this being the default behaviour because it is
>>something pretty undefined what int value you would have if no exception
>>would be raised.
>
> The default behaviour does make sense to me as well. However it does
> appear that it may be different from the behaviour generated by GCC on
> other machines.

True, but I think this it is a misconception to assume that the
environment of RISC OS should exactly match that of Unix.  Though we try
to achieve it, simulating a floating-point environment is not necessarily
so easy.

Perhaps UnixLib should be setting the FPA co-processor state flags on
startup correctly, but this needs to be investigated in more detail to
ensure we conform with the C standards rather than the Unix environment.

>>
>>But I think your question is around the header fenv.h
> Have I misread the documentation? If so, can you show me the code I
> need to add to a program?

I think John's referring to the 'fesetenv' function.  However our
implementation only sets the flags to their default, which isn't really
helpful here.

> If not, is there any other routine I can add to the program to modify how
> casting from double to int is handled.

Does this problem not actually point at a bug ? The idea of overflowing an
integer sounds problematic and reminds me of the Ariane 5 spacecraft
disaster. :)

Regards,

Nick.







More information about the gcc mailing list