[Gnash-commit] Question about fmod() on OS X

[zou lunkai]

Hi, Markus

May I ask what is the problem of fmod() and related stuff on OS X?
(Question based on your commits yestoday)


old code: return (boost::int32_t)static_cast<boost::uint32_t>(a * 65536.0f);

new code: return static_cast<boost::int32_t>(a * 65536.0f);

Does the old code compile on OS X? The new code is wrong with GCC and
MSVC8 on most systems(already tested) in logic.

old code:   b = (boost::uint32_t)(std::fmod(a*65536.0, 4294967296.0));

new code:   b = static_cast<boost::int32_t>(std::fmod(a * 65536.0,
4294967296.0));

Does the old code compile on OS X? Also the new code is completely
wrong and undefined.

eg. (int32)((uint32)(4294967295.0)) == -1
//what we want and it has a defined behaviour.

(int32)(4294967295.0) == ????
// it's undefined according to the C++ standard, and even we can get a
constant result
// with GCC and MSVC8 compiler, the result is wrong(unexpected), it's
-2147483648.

you can undefine  "TRUST_FLOAT_TO_UINT32_CONVERSION" in utility.h to
use the fmod() version to avoid potential undefined behaviour on OS X.
If the old compiles but get annoying warnings, you also use C++ style
casts to get rid of them for these few functions, but please don't
change the semantics. I believe the new code would fail on our
testsuites(tests in misc-swfc.all).

old code:
 inline boost::int32_t FloatToFixed16(float a)
{
      b = (boost::uint32_t)(std::fmod(a*65536.0, 4294967296.0));
      ....
}

I know the old code looks a little bit wired, but that's exactly what
I want. I'v done a hard work on the conversion, it's not a careless
mistake and the behaviour is DEFINED. (bwy and I have discussed the
related code on IRC in the past)


--zou