[Top][All Lists]

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

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

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

BTW, I know there still are many other "float convert to in" warning
messages, please leave  them alone for a while. I mean they can't be
fixed by simply C/C++ style casting. Those warnings remind me there
are unfinished work for the code refactory(see related work below). We
are not going to push the next release recently, right? So I guess
it's not a big problem to have some warning at this moment.

Related work are:

task #8223: Matrix accuracy improvement.

task #8299 rect class refactory>

bug#23290 cxform accuracy problem


On 7/3/08, zou lunkai <address@hidden> wrote:
> 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

reply via email to

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