The sdcc compiler contains many casts from double to unsigned int/long, and assumes that the value won't be clamped to a positive value.
Constructs like this, is used in many places:
... = (unsigned long) floatFromVal(...);
On MacOS (intel, and possible on other platforms using gcc and sse) this won't work since gcc will clamp the returned float to a value valid for an unsigned long.
I believe that its compiler specific what happens when casting a negative float/double to an unsigned integer.
Logged In: YES
user_id=1378
Originator: YES
Sorry, I should have added this in the bug (from the Ansi C Programming Language book, 2nd rev, page 159):
A.6.3 Integer and Floating
When a value of floating type is converted to integral type, the fractional part is discarded; if
the resulting value cannot be represented in the integral type, the behavior is undefined. In
particular, the result of converting negative floating values to unsigned integral types is not
specified.
Logged In: YES
user_id=888171
Originator: NO
I do not fully grasp why this is a bug. Whenever a construct like this is used I think the compiler already knows the value is in the expected range. The double float is just used as the smallest common bigger type to hold all possible values in float/long/short/char/...
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 30 days (the time period specified by
the administrator of this Tracker).
Logged In: YES
user_id=531281
Originator: NO
I have encountered this very bug in tracker id #1777758. Yasir, you are correct: this operation is undefined whenever floatFromVal() returns a number less than -1.
Logged In: YES
user_id=568035
Originator: NO
This is a bug and affects the sdcc on i386 Mac OS X 10.4.5 & gcc 4.0.1 dramatically: a lot of regression tests fail. It is interesting that on OS X 10.4.1 & gcc 4.0.0 the regression tests are executed without errors...
Borut
Logged In: YES
user_id=568035
Originator: NO
fixed in svn revision #4921.
Borut