Le decadi 10 frimaire, an CCXXIV, Michael Niedermayer a écrit :
> > ISO/IEC 9899:TC3
> >     5.2.4.2.2 Characteristics of floating types <float.h>
> > 
> >     8 Except for assignment and cast (which remove all extra range and 
> > precision), the values
> >     of operations with floating operands and values subject to the usual 
> > arithmetic
> >     conversions and of floating constants are evaluated to a format whose 
> > range and precision
> >     may be greater than required by the type. The use of evaluation formats 
> > is characterized
> >     by the implementation-defined value of FLT_EVAL_METHOD:19)
> >         -1       indeterminable;
> >         0       evaluate all operations and constants just to the range and 
> > precision of the
> >                 type;
> >         1       evaluate operations and constants of type float and double 
> > to the
> >                 range and precision of the double type, evaluate long double
> >                 operations and constants to the range and precision of the 
> > long double
> >                 type;
> >         2       evaluate all operations and constants to the range and 
> > precision of the
> >                 long double type.
> >     All other negative values for FLT_EVAL_METHOD characterize 
> > implementation-defined
> >     behavior.
> 
> a few more related parts:
>     5 The accuracy of the floating-point operations (+, -, *, /) and of the 
> library functions in
>     <math.h> and <complex.h> that return floating-point results is 
> implementation-
>     defined, as is the accuracy of the conversion between floating-point 
> internal
>     representations and string representations performed by the library 
> functions in
>     <stdio.h>, <stdlib.h>, and <wchar.h>. The implementation may state that 
> the
>     accuracy is unknown.
> 
> 6.4.4.2 Floating constants
>     7 The translation-time conversion of floating constants should match the 
> execution-time
>     conversion of character strings by library functions, such as strtod, 
> given matching
>     inputs suitable for both conversions, the same result format, and default 
> execution-time
>     rounding.64)

I am not sure why you quoting this. Are you implying this is not a compiler
bug, the compiler is actually allowed to do that? Possible. But still, I do
not think we should apply this unless we actually understand what is going
on here, why a cast that should not change anything does change the result.
Otherwise, it could just be a coincidence, and break in a different way on a
different compiler.

Regards,

-- 
  Nicolas George

Attachment: signature.asc
Description: Digital signature

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to