http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007
--- Comment #20 from Tobias Burnus <burnus at gcc dot gnu.org> --- And yet another possibility: Some systems (like Darwin) have strtod_l (etc.) which takes a locale argument. GLIBC seems to have it only as weak symbol but offers __strtod_l. Looking againt at GCC's C++ compiler, one finds in libstdc++-v3/config/locale/gnu/c_locale.cc: __v = __strtof_l(__s, &__sanity, __cloc); #if __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ > 2) // Prefer strtold_l, as __strtold_l isn't prototyped in more recent // glibc versions. __v = strtold_l(__s, &__sanity, __cloc); #else __v = __strtold_l(__s, &__sanity, __cloc); #endif libstdc++ uses locale::facet::_S_get_c_locale() to get the locale. The argument __cloc is in glibc/Darwin (->xlocate.h) __locale_t. However, the symbol became official in POSIX 2008 and is now locale_t. Seemingly, one has to obtain the locale with newlocale(..., "C",...) - and later should free it with freelocale. * * * To summarize: It is probably best to use __strtold_l as C++ does, if it is available. That should be the fastest, but requires that one caches the locale_t var (e.g. get it at startup, free it at the end). If it is not available, one presumably should use comment 19's method of swapping the locale. For libquadmath's strtoflt128, one either has to add an "_l" version - or one has to always use the second method.