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 788087 - g-ir-compiler mis-parses double constant in locales with different decimal separator
g-ir-compiler mis-parses double constant in locales with different decimal se...
Status: RESOLVED FIXED
Product: gobject-introspection
Classification: Platform
Component: g-ir-compiler
unspecified
Other All
: Normal major
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2017-09-24 08:04 UTC by Uli Schlachter
Modified: 2017-09-24 13:35 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Use locale-independent functions to parse numbers (1017 bytes, patch)
2017-09-24 13:34 UTC, Emmanuele Bassi (:ebassi)
committed Details | Review

Description Uli Schlachter 2017-09-24 08:04:55 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.
Comment 1 Emmanuele Bassi (:ebassi) 2017-09-24 13:31:08 UTC
Right, we should be using locale-independent functions for parsing numbers — e.g. g_ascii_strtod().
Comment 2 Emmanuele Bassi (:ebassi) 2017-09-24 13:34:58 UTC
Created attachment 360318 [details] [review]
Use locale-independent functions to parse numbers
Comment 3 Emmanuele Bassi (:ebassi) 2017-09-24 13:35:33 UTC
Attachment 360318 [details] pushed as 66c0828 - Use locale-independent functions to parse numbers