gnash-commit
[Top][All Lists]
Advanced

[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
http://savannah.gnu.org/task/?8299>

bug#23290 cxform accuracy problem
https://savannah.gnu.org/bugs/index.php?23290


--zou



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]