On 19 February 2017 at 21:01, Geoffrey Hutchison <geoff.hutchi...@gmail.com> wrote: >> Does anyone know exactly what problem the locale stuff is fixing? And >> a follow-on, is there another way to fix it? > > The problem is that we parse things like decimals for coordinates (0.0000) > which exist in the C locale. So we need to make sure the parsing code works > in C locale not any other locale.
Gotcha. It does make me wonder whether we could avoid some of these problems by parsing with C-style functions rather than C++ stream based ones. I don't know the answer to that, nor whether it would be feasible to change the existing codebase. On the other hand, such problems might be easy to test/detect by setting the locale and seeing whether the various formats give different results. BTW, there's an additional complexitiy to consider with get/set locale. By default (at least with MSVC on Win) it's per-process, so if one thread get/sets the locale, it will affect the locale on the other threads. However, there are commands to change this behaviour to make it thread-locale (if you pardon the pun). >> Windows-specific API). After all of the changes on the pull request, >> it can now take quite a while before segfaulting (mostly in locale, >> but worryingly once in NewAtom). Progress of sorts, I guess :-) > > I'll take a look this week. Using Clang or g++, you should be able to use > ThreadSanitizer to check: > https://clang.llvm.org/docs/ThreadSanitizer.html > https://github.com/google/sanitizers/wiki That's looks neat. I've already become a convert to AddressSanitizer (not that I've ever needed it of course). > Hope that helps, > -Geoff ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ OpenBabel-Devel mailing list OpenBabel-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-devel
