A slow-but-working trick for proper local decimal separator handling (tickets 4020 and possibly 4631)

[atrosinenko]

Supposing reading JSON is a slow path only executed during an initialization of an FMU that can crash the entire process loading an FMU while decimal separator is not a ., this kludge (learned from a colleague of mine, and probably reinvented hundreds of time :) ) that although being slow is quite simple and does not introduce any new external dependencies.

[atrosinenko]

Could this be merged or maybe it should be somehow improved? Sure, it is quite hackish solution, on the other hand, it does not introduce any new external dependencies.

This issue is quite cruel, because, being in a hurry, it is quite misleading to see your "host" application silently closing. Normally this would suggest that some crash occurred.

[sjoelund]

There exists much nicer versions of this functionality, for example in ModelicaIO.c using strtol_l. I would suggest creating something like strtol_c_locale based on that instead. And then updating the configure script for the FMUs to look for the required headers (locale, etc). The only problem is for source-code FMUs the configure script is not required to run, so you need a fallback function in that case (and possibly using #if defined(__has_include) #if __has_include(<locale.h>) or something to do a compile-time check in newer compilers).

We used to have a complete copy of a locale-independent strtod (807bc6f f6c5956), but it was removed due to hanging a lot. A version using strtod_l as found in the OS should work rather well though, and if we fail to find the required headers, the FMU can use a workaround similar to yours above.

[sjoelund]

Note that if we implement this, we should have it in one of the util/ headers and use this function elsewhere in the compiler (so maybe we don't need the workarounds for forcing the . as comma separator in the init functions)...