GNOME Bugzilla – Bug 788087
g-ir-compiler mis-parses double constant in locales with different decimal separator
Last modified: 2017-09-24 13:35:37 UTC
I just figured out https://github.com/pavouk/lgi/issues/173. This is lgi, the Lua GObject-introspection bindings, failing to handle Regress correctly. The following XML <constant name="DOUBLE_CONSTANT" value="44.220000" c:type="REGRESS_DOUBLE_CONSTANT"> <type name="gdouble" c:type="gdouble"/> </constant> is turned by g-ir-compiler into a constant with value 44. This happens with LC_ALL=de_DE, but does not happen with LC_ALL=C, so is likely due to the different decimal separator in Germany. With some more digging, I found out that the code since always used strtod() to parse these constants (function parse_float_value() in girepository/girnode.c). This does not explain why things suddenly broke... However, recently-ish all main() functions where changed to call setlocale(): https://github.com/GNOME/gobject-introspection/commit/74e4542739df792d4a1f42eecd756506140703b0#diff-03258a1fcced22a7eb876058d39e9118 Thus, after this commit, strtod() expects 44,22 instead off 44.22 and aborts at the unexpected ".". There might be other, similar locale-related problems in this code, I don't know.
Right, we should be using locale-independent functions for parsing numbers — e.g. g_ascii_strtod().
Created attachment 360318 [details] [review] Use locale-independent functions to parse numbers
Attachment 360318 [details] pushed as 66c0828 - Use locale-independent functions to parse numbers