GNOME Bugzilla – Bug 666887
[0.11]gstinterpolationcontrolsource uses FP_NAN
Last modified: 2012-09-24 18:27:50 UTC
It uses FP_NAN constant for NAN, but FP_NAN is a result code from fpclassify. This is wrong. Also please keep in mind that there isn't a NAN constant that's not C99 and MSVC doesn't support C99.
Possible way to define NAN so that it works in visual c++ #define INFINITY (DBL_MAX+DBL_MAX) #define NAN (INFINITY-INFINITY)
Also gstcontrobinding.c uses isnan, which is C99. msvc would need _isnan
Thanks, I'll think about how to fix the API here. Most likely the controller will use a 0.0 - 1.0 value range (or -1.0 - 1.0) and then I can just use a large value. Or change the api to use a out-var and a gboolean return and tell that if the return value is FALSE the content of the out-var is undefined.
Well, NAN and isnan are slowly creeping into gstreamer in different places as well, maybe it wouldn't be a bad idea to have GST_NAN and gst_isnan...
Yep, its a good fit for ./gst/math-compat.h. I have found a coupld of isnan calls in gst-ffmpeg, but nowhere else so far. For linux I found a define for NAN in bits/nan.h (included from math.h). It is essentially: # if __BYTE_ORDER == __BIG_ENDIAN # define __nan_bytes { 0x7f, 0xc0, 0, 0 } # endif # if __BYTE_ORDER == __LITTLE_ENDIAN # define __nan_bytes { 0, 0, 0xc0, 0x7f } # endif static union { unsigned char __c[4]; float __d; } __nan_union __attribute_used__ = { __nan_bytes }; # define NAN (__nan_union.__d)
commit eba636cc8320f0eef860cda70577dc5257dd7ac7 Author: Stefan Sauer <ensonic@users.sf.net> Date: Fri Dec 30 13:32:18 2011 +0100 controller: use NAN instead of FP_NAN (which is the class) Also add a fallback define to math-compat.h. Fixes #666887
Matej, would this be sufficient for isnan? #ifndef isnan #define isnan(f) _isnan(f) #endif
Are you sure that isnan is a macro on all platforms? from man page: In C90 mode, the isnan() function tests whether x is NaN. In C99 mode, the isnan() macro determines whether its argu- ment value is NaN. First, an argument represented in a for- mat wider than its semantic type is converted to its seman- tic type. The determination is then based on the type of the argument. perhaps we could have #ifdef _MSC_VER #define isnan(f) _isnan(f) #endif and similar checks for other platform that don't have native isnan.
Maybe this could also be done via __STDC_VERSION__ and/or _POSIX_VERSION checks like we do for rint etc.?