On 12/19/15, Ganesh Ajjanagadde <gajja...@mit.edu> wrote: > On Sat, Dec 19, 2015 at 12:33 PM, Ronald S. Bultje <rsbul...@gmail.com> > wrote: >> Hi, >> >> On Sat, Dec 19, 2015 at 2:25 PM, Ganesh Ajjanagadde <gajja...@mit.edu> >> wrote: >> >>> On Sat, Dec 19, 2015 at 11:05 AM, Hendrik Leppkes <h.lepp...@gmail.com> >>> wrote: >>> > On Sat, Dec 19, 2015 at 6:54 PM, Ganesh Ajjanagadde >>> > <gajjanaga...@gmail.com> wrote: >>> >> On Sat, Dec 19, 2015 at 8:06 AM, Ganesh Ajjanagadde >>> >> <gajjanaga...@gmail.com> wrote: >>> >>> On Sat, Dec 19, 2015 at 6:26 AM, Ronald S. Bultje >>> >>> <rsbul...@gmail.com> >>> wrote: >>> >>>> Hi, >>> >>>> >>> >>>> On Fri, Dec 18, 2015 at 3:47 PM, Ganesh Ajjanagadde < >>> gajjanaga...@gmail.com> >>> >>>> wrote: >>> >>>>> >>> >>>>> On Fri, Dec 18, 2015 at 12:41 PM, Ronald S. Bultje < >>> rsbul...@gmail.com> >>> >>>>> wrote: >>> >>>>> > Hi, >>> >>>>> > >>> >>>>> > On Fri, Dec 18, 2015 at 2:18 PM, Ganesh Ajjanagadde >>> >>>>> > <gajjanaga...@gmail.com> >>> >>>>> > wrote: >>> >>>>> >> >>> >>>>> >> For systems with broken libms. >>> >>>>> >> Tested with NAN, -NAN, INFINITY, -INFINITY, +/-x for regular >>> double x >>> >>>>> >> and >>> >>>>> >> combinations of these. >>> >>>>> >> >>> >>>>> >> Signed-off-by: Ganesh Ajjanagadde <gajjanaga...@gmail.com> >>> >>>>> >> --- >>> >>>>> >> configure | 2 +- >>> >>>>> >> libavutil/libm.h | 9 +++++++++ >>> >>>>> >> 2 files changed, 10 insertions(+), 1 deletion(-) >>> >>>>> >> >>> >>>>> >> diff --git a/configure b/configure >>> >>>>> >> index 123d1df..7917386 100755 >>> >>>>> >> --- a/configure >>> >>>>> >> +++ b/configure >>> >>>>> >> @@ -2852,7 +2852,7 @@ cropdetect_filter_deps="gpl" >>> >>>>> >> delogo_filter_deps="gpl" >>> >>>>> >> deshake_filter_select="pixelutils" >>> >>>>> >> drawtext_filter_deps="libfreetype" >>> >>>>> >> -dynaudnorm_filter_deps="copysign erf" >>> >>>>> >> +dynaudnorm_filter_deps="erf" >>> >>>>> >> ebur128_filter_deps="gpl" >>> >>>>> >> eq_filter_deps="gpl" >>> >>>>> >> fftfilt_filter_deps="avcodec" >>> >>>>> >> diff --git a/libavutil/libm.h b/libavutil/libm.h >>> >>>>> >> index 6d8bd68..637de19 100644 >>> >>>>> >> --- a/libavutil/libm.h >>> >>>>> >> +++ b/libavutil/libm.h >>> >>>>> >> @@ -62,6 +62,15 @@ static av_always_inline float cbrtf(float x) >>> >>>>> >> } >>> >>>>> >> #endif >>> >>>>> >> >>> >>>>> >> +#if !HAVE_COPYSIGN >>> >>>>> >> +static av_always_inline double copysign(double x, double y) >>> >>>>> >> +{ >>> >>>>> >> + uint64_t vx = av_double2int(x); >>> >>>>> >> + uint64_t vy = av_double2int(y); >>> >>>>> >> + return av_int2double((vx & 0x7fffffffffffffff) | (vy & >>> >>>>> >> 0x8000000000000000)); >>> >>>>> >> +} >>> >>>>> >> +#endif >>> >>>>> > >>> >>>>> > >>> >>>>> > Don't these need type suffixes (e.g. UINT64_C(val)) on some >>> systems? >>> >>>>> >>> >>>>> I believe not, see >>> >>>>> http://en.cppreference.com/w/cpp/language/integer_literal >>> >>>> >>> >>>> >>> >>>> That document confirms that it is indeed legal for a compiler to >>> >>>> read >>> the >>> >>>> given literal on a 32bit or windows 64bit system as a 32bit max >>> value, and >>> >>>> your literals don't fit in 32bit. >>> >>> >>> >>> How, the standard clearly says that the literal will be in the type >>> >>> int < unsigned int < long int < unsigned long int < long long int < >>> >>> unsigned long long int, wherever it first fits, and this is also >>> >>> clear >>> >>> from the link I sent. >>> >>> >>> >>> long long is at least 64 bits. I can't speak about broken >>> >>> compilers/environments that lack long long. >>> >> >>> >> This turns out to be the heart of the matter; as usual, Microsoft's >>> >> toolchain is fundamentally broken: >>> >> >>> https://stackoverflow.com/questions/25626022/how-should-a-64-bit-integer-literal-be-represented-in-c >>> . >>> >> >>> > >>> > Its behavior would appear to be valid C90 on Windows, since long int >>> > is 32-bit on that platform (which C90 calls for using, not long long) >>> >>> Yes, I meant broken wrt C99 (as seen in the link), which most of our >>> platforms have and use. Basically, I meant that their C99 support is >>> half-baked and broken (of course not news). >> >> >> But FFmpeg isn't C99, see >> https://ffmpeg.org/developer.html#C-language-features >> >> "FFmpeg is programmed in the ISO C90 language with a few additional >> features from ISO C99 [..]" > > A last comment to show the ridiculousness of it all: UINT64_C is > defined only in stdint.h, a C99 feature. Thus, if you want a "strict > C90" solution to this, there is none. In particular, using UINT64_C is > not "valid C90" on any platform. > > It is just a happy accident that MSVC has UINT64_C. >
C90 is more than 20 years old. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel