After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 666887 - [0.11]gstinterpolationcontrolsource uses FP_NAN
[0.11]gstinterpolationcontrolsource uses FP_NAN
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.11.x
Other Mac OS
: Normal normal
: 0.11.x
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-12-27 02:40 UTC by Matej Knopp
Modified: 2012-09-24 18:27 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Matej Knopp 2011-12-27 02:40:06 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.
Comment 1 Matej Knopp 2011-12-27 02:51:19 UTC
Possible way to define NAN so that it works in visual c++
#define INFINITY (DBL_MAX+DBL_MAX)
#define NAN (INFINITY-INFINITY)
Comment 2 Matej Knopp 2011-12-27 02:54:18 UTC
Also gstcontrobinding.c uses isnan, which is C99. msvc would need _isnan
Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2011-12-27 16:28:50 UTC
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.
Comment 4 Matej Knopp 2011-12-27 17:11:47 UTC
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...
Comment 5 Stefan Sauer (gstreamer, gtkdoc dev) 2011-12-29 10:46:44 UTC
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)
Comment 6 Stefan Sauer (gstreamer, gtkdoc dev) 2011-12-30 12:35:17 UTC
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
Comment 7 Stefan Sauer (gstreamer, gtkdoc dev) 2011-12-30 12:39:56 UTC
Matej, would this be sufficient for isnan?

#ifndef isnan
#define isnan(f) _isnan(f)
#endif
Comment 8 Matej Knopp 2011-12-30 14:07:54 UTC
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.
Comment 9 Tim-Philipp Müller 2011-12-30 14:17:12 UTC
Maybe this could also be done via __STDC_VERSION__ and/or _POSIX_VERSION checks like we do for rint etc.?