GNOME Bugzilla – Bug 712225
Implement a C99-capable version of strtod() for Windows/MSVC
Last modified: 2018-05-24 16:03:31 UTC
Hi, From Dan's comments in Bug 711047, comment #64: --- Hm... we don't g_ascii_strtod() to behave differently in MSC than with unix/mingw though... so maybe we need to implement support for hex strings and nan/inf by hand there (the same way we don't use the system sprintf() under MSC). I'm not sure how much work that would take; if you want to get the tests passing now, feel free to just commit this patch for now, and file a bug to fix g_ascii_strtod() later. --- This is a bug opened for fixing g_ascii_strtod() on Visual C++ (and quite possibly other C89 compilers) as strtod() does not support the use of NAN/+-INF/Hex strings for conversion, and it returns 0.0 instead of NAN (as on C99) when a NAN is input to it. This is meant to keep track of the work needed for implementing a C99-capable strtod() on C89 compilers for proper consumption for g_ascii_strtod(). With blessings, thank you!
Created attachment 276220 [details] [review] Add a C99-compatible implementation for strtod() Hi, This adapts the implementation of strtod() from gnulib, that can be used for Visual C++ builds at least (I'm not sure about other platforms that need this, though, as I don't have access to them, so I can't say anything about them). The code for strtod.c was pulled from the gnulib git repos today, and I have adapted the code a bit in order to simplify its includes and for use on Visual Studio, as the ctypes.h functions as provided by Visual C++ 2008 and later seem to be sufficient.
Created attachment 276221 [details] [review] glib/gstrfuncs.c: Use gnulib's strtod() when necessary Hi, This updates glib/gstrfuncs.c to make use of gnulib's strtod() when necessary (such as being on Visual C++). As I am not sure whether other systems/compilers that GLib supports would be using this code (as I don't have access to them), I have made this for Visual C++ builds only at the moment. This allows g_strtod() and g_ascii_strtod() to be able to handle items that are required by the C99 specifications for strtod(), that they call, on Visual C++ builds.
Created attachment 276222 [details] [review] tests: Re-enable the C99 strtod() tests for Visual C++ Hi, This re-enables the strfuncs tests that check g_strtod() for C99 capabilities for Visual C++ builds, as these tests can succeed after using adapting gnulib's implementation for strtod(). I will update the Visual Studio projects to build gnulib strtod() as soon as these patches are deemed acceptable. With blessings, thank you!
Hi, Any comments about this patchset? pinging here... With blessings, thank you!
Created attachment 288718 [details] [review] Use gnulib's strtod() implementation for MSVC Bulids Hi, As the strtod() that's not being compliant with C99 specs is regarding Visual Studio builds, perhaps the code (derived from gnulib) ought to be residing in build/win32, like what is now being done in GDir for dirent. This updates glib/gstrfuncs.c to include the strtod() implementation for Visual Studio builds so that g_strtod() on such builds can be more compliant with C99 strtod(). With blessings, thank you!
Created attachment 289494 [details] [review] Use gnulib's strtod() implementation for MSVC Bulids (re-post) Hi, As the original patch for strtod() was posted some time ago, and it turns out that there are both c-strtod (GPL) and strtod (LGPL3+/GPL3+) modules in gnulib, to avoid accidently using GPL code in GLib, I have re-adpated strtod() from the strtod module from gnulib. Please let me know if using this for Visual Studio builds of GLib would be good here. With blessings, thank you!
ping...
GLib is under LGPL2+ ... this file appears to be under 3.
Hello Ryan, Thanks for the heads up about the licensing part (The license part did confuse me a bit, but this clears it up for me... :|). Will need to look at getting this done in another way then... With blessings, thank you!
mingw-w64 has strtod() implementation under what appears to be MIT license.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/790.