gnash-commit
[Top][All Lists]
Advanced

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

Re: [Gnash-commit] gnash ChangeLog libbase/utility.h server/charac...


From: zou lunkai
Subject: Re: [Gnash-commit] gnash ChangeLog libbase/utility.h server/charac...
Date: Sat, 14 Jun 2008 00:33:38 +0800

>
> An rvalue of a floating point type can be converted to an rvalue of an
> integer type. The conversion truncates; that is, the fractional part is
> discarded. The behavior is undefined if the truncated value cannot be
> represented in the destination type.
>

clear enough. what about 'double' to 'float' conversion? Is it also undefined?

> I should say I think the matrix changes are good and necessary, but
> these functions are dangerous.
>

FloatToFixed16() and DoubleToFixed16() are only used for matrix at the
moment, and they are mainly for converting cos() and sin() values to
integers, so shouldn't be a problem(all in valid ranges). I may move
them inside the matrix class later.

PIXEL_TO_TWIPS() then need to be inspected if it is really unsafe.

--zou


On 6/13/08, Benjamin Wolsey <address@hidden> wrote:
> Am Freitag, den 13.06.2008, 23:44 +0800 schrieb zou lunkai:
> > >
> > > > All of these rely on undefined behaviour. Conversion from float to an
> > > > integer is undefined behaviour if the float value cannot be represented
> > > > in the integral value after truncation (i.e. when the fractional value
> > > > has been removed).
> > > >
> > >
> >
> > 'undefined behaviour' only occurs when the 'double' number is out of
> > an integer's range in theory.  In practice, they are all 'defined' to
> > MSVC6, GCC3.4 and GCC4.1. I planed to add some tests to
> > testsuite/server for these simple functions. It's easy to test if any
> > compiler gives unexpected results.
> >
>
> Undefined behaviour *always* occurs, because it's explicitly not defined
> in the C++ standard. Whether it's consistent on a particular
> implementation is irrelevant. What about Comeau, Intel or Mipspro
> compilers? Or other platforms and processors? In any case, it doesn't
> matter how many compilers you test it on: it's still a bug, because the
> next compiler might do something different.
>
> The section is 4.9.1:
>
> An rvalue of a floating point type can be converted to an rvalue of an
> integer type. The conversion truncates; that is, the fractional part is
> discarded. The behavior is undefined if the truncated value cannot be
> represented in the destination type.
>
> I should say I think the matrix changes are good and necessary, but
> these functions are dangerous.
>
> -bwy
>
>




reply via email to

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