search

HRI-EU / Rcs

Rcs is a set of C and C++ libraries for robot control and simulation
BSD 3-Clause "New" or "Revised" License
37 stars 14 forks source link

Mesh parsing breaks on different locale #5

Closed Xfel closed 5 years ago

Xfel commented 6 years ago

The parser for .tri files uses sscanf to read floating point values. On other locales like ie german, the decimal separator is a , instaed of a . which breaks parsing the mesh files whose format is fixed.

Xfel commented 6 years ago

So, it seems that the locale switch was actually caused by another library I'm using. According to the C++ documentation, the locale is initialized in a deterministic state. Unless you change it, it works.

Xfel commented 6 years ago

This issue does not only affect mesh parsing, but parsing of floating point numbers in general, including the graph files and the physics config files for vortex. All of these are locale independent formats, so parsing them should be locale independent as well. One solution would be to reset the locale in every parsing function.

mgienger commented 6 years ago

I just found this discussion which is very similar to this issue: https://github.com/robotology/idyntree/issues/288

mgienger commented 5 years ago

Now there is a function String_toDouble_l() that does the conversion with the C locale (dot separator independent of applications's locale). It is based on the strtod_l() function, which seems to be about an order of magnitude faster than the imbued stringstream. This is now being used in the parsing functions for meshes and Rcs-related xml files. It works fine for a few tests I did, and can be tested with a "-locale" option in the Rcs program.

Here are a few points I'm currently not sure about:

  1. I guess for printing out stuff (printf, sprintf etc.) we stick to the program's locale, and accept a comma instead of a dot. This however has implications when writing out a xml file, since that will also contain commas for some locales. This means that when writing a file with a "comma" locale, it will wrongly be parsed in. Or should we make a difference for writing out xml files?

  2. How to deal with arrays of numbers, e.g. in matrices, BVH trajectories etc. Should these follow the application's locale, or should we also enforce the C locale? In the latter case, the same issue as in 1) applies

Any ideas / suggestions welcome

Xfel commented 5 years ago

I think that we should use the system locale when printing to console (it's easier), but the C locale when writing a file.

mgienger commented 5 years ago

Sounds reasonable, should be all in place now.