[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: zou lunkai
Subject: [Gnash-commit] Question about fmod() on OS X
Date: Thu, 3 Jul 2008 09:18:11 +0800

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,

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

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)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]