[WinSDK] Numeric#** C99 impl breaks build

[jonforums]

With WinSDK 7.1 with cl 16.00.30319.01 I get the following failure because numeric.c:num_pow uses C99 isfinite which the msvc math.h header doesn't provide.

...
mruby_static.lib(numeric.c.obj) : error LNK2019: unresolved external symbol _isfinite referenced in function _num_pow
mrbc.exe : fatal error LNK1120: 1 unresolved externals
LINK Pass 1 failed. with 2
NMAKE : fatal error U1077: 'C:\Apps\cmake\bin\cmake.exe' : return code '0xffffffff'
Stop.

If isfinite and other C99-isms are needed, the mingw and mingw-w64 math.h provides public domain impls. For example, line 281+ from the mingw-w64 math.h impl

[matz]

VC again? When can I expect MS to stop ignoring more-than 10 years old standard? I'm getting sick of it.
Are isinf and isnan available on VC?

[jonforums]

This quote from an InfoQ article on MS C++ vs. C99 just about sums it up "This failure to support C99 has frustrated developers requesting Visual Studio compatibility with the long time standard. If VS supported C99 natively, it would be easier for users to develop and port existing cross-platform applications."

re: VC isinf and isnan, here's a quick scan

C:\Program Files\Microsoft Visual Studio 10.0\VC>\gnuwin32\grep\bin\grep.exe -PRin isnan include
include/complex:81:     static bool _Isnan(_Ty _Left)
include/complex:169:    static bool _Isnan(_Ty _Left)
include/complex:256:    static bool _Isnan(_Ty _Left)
include/complex:343:    static bool _Isnan(_Ty _Left)
include/complex:484:            if (_Myctraits::_Isnan(_Rightreal) || _Myctraits::_Isnan(_Rightimag))
include/complex:495:                    if (_Myctraits::_Isnan(_Wd) || _Wd == 0)
include/complex:519:                    if (_Myctraits::_Isnan(_Wd) || _Wd == 0)
include/float.h:220:_Check_return_ _CRTIMP int    __cdecl _isnan(_In_ double _X);
include/intrin.h:283:__MACHINECE(int _isnan(double))
include/intrin.h:284:__MACHINECE(int _isnanf(float))
include/math.h:257:_CRTIMP int    __cdecl _isnanf(_In_ float _X);
include/xcomplex:198:   else if (_CTR(_Ty)::_Isnan(_Av))
include/xcomplex:200:   else if (_CTR(_Ty)::_Isnan(_Bv))
include/xcomplex:286:   if (_CTR(_Ty)::_Isnan(_Theta))

C:\Program Files\Microsoft Visual Studio 10.0\VC>\gnuwin32\grep\bin\grep.exe -PRin isinf include
include/complex:75:     static bool _Isinf(_Ty _Left)
include/complex:164:    static bool _Isinf(_Ty _Left)
include/complex:251:    static bool _Isinf(_Ty _Left)
include/complex:338:    static bool _Isinf(_Ty _Left)
include/xcomplex:196:   if (_CTR(_Ty)::_Isinf(_Av) || _CTR(_Ty)::_Isinf(_Bv))
include/xcomplex:299:                   : _CTR(_Ty)::_Isinf(_Rho) ? _Rho        // log(INF) == INF
include/xcomplex:400:   if (_CTR(_Ty)::_Isinf(_Dv))

compare that with a quick check from a recent mingw-w64 release:

C:\mingw-rvb\i686-w64-mingw32>\gnuwin32\grep\bin\grep.exe -PRin isnan include
include/float.h:286:_CRTIMP int __cdecl __MINGW_NOTHROW _isnan (double);
include/intrin.h:302:    __MACHINECE(int _isnan(double))
include/intrin.h:303:    __MACHINECE(int _isnanf(float))
include/math.h:197:  _CRTIMP int __cdecl _isnan (double);
include/math.h:336:  extern int __cdecl __isnan (double);
include/math.h:337:  extern int __cdecl __isnanf (float);
include/math.h:338:  extern int __cdecl __isnanl (long double);
include/math.h:341:  __CRT_INLINE int __cdecl __isnan (double _x)
include/math.h:350:  __CRT_INLINE int __cdecl __isnanf (float _x)
include/math.h:359:  __CRT_INLINE int __cdecl __isnanl (long double _x)
include/math.h:369:#define isnan(x) (sizeof (x) == sizeof (float) ? __isnanf (x)        \
include/math.h:370:  : sizeof (x) == sizeof (double) ? __isnan (x)      \
include/math.h:371:  : __isnanl (x))
include/math.h:877:   _CRTIMP int __cdecl _isnanf(float _X);

C:\mingw-rvb\i686-w64-mingw32>\gnuwin32\grep\bin\grep.exe -PRin isinf include
...irrelevant stuff elided...
include/math.h:330:#define isinf(x) (fpclassify(x) == FP_INFINITE)

[matz]

Sigh. I am almost giving up VC.
Without extensive help from VC users, it's almost impossible to support VC.

[jonforums]

Yes, it's ugly. But don't give up just yet.

Once we give VC users (cmd line and IDE) an easy way to build with their favorite tool (makefile or project file) via CMake I think/hope you'll get more VC dev participation.

The good news is that devs like @nkshigeru are able to build mruby on VC IDE using the CMake generated project file :)

Even though the CMake proto is still in early shape, I'd like to see more people tweet about it to get the word out to the VC devs. How many people know that the CMake proto can build mruby on OSX, Linux, and Windows mingw or VC? https://github.com/thecodeshop/mruby/wiki/CMake-compatible

No bikeshedding here, but if we have to spackle a bunch more VC/Win32-specific workaround code, the #include "mrb-internal/win32.h and #ifdef HAVE_XXX idea may start to look more attractive even if there's never any platform specific *.c impl files ;)

[matz]

I drop isfinite() from num_pow() in 74e531e.

[nkshigeru]

I hope mruby support VC, and I would like to help.

VC does not have isfinite but provide _finite in <float.h>.

[matz]

Thank you. When you see any problem compiling mruby on VC, submit the issue.
If you could provide pull-request, that would be awesome, but report itself is valuable.