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: Benjamin Wolsey
Subject: Re: [Gnash-commit] gnash ChangeLog libbase/utility.h server/charac...
Date: Fri, 13 Jun 2008 17:59:12 +0200

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

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


reply via email to

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