[FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double
Nicolas George
george at nsup.org
Mon Nov 30 19:02:47 CET 2015
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20151130/c77cdf4a/attachment.sig>
More information about the ffmpeg-devel
mailing list