Decimal values rounded on save

[Jef Driesen]

On 03-09-12 19:37, Linus Torvalds wrote:
> On Mon, Sep 3, 2012 at 10:20 AM, Linus Torvalds
> <torvalds at linux-foundation.org> wrote:
>>
>> Anyway, none of this explains the crazy windows "truncate to integer"
>> problem. The above obviously *does* create an integer depth, but it's
>> an integer depth in *mm*, not in meters.
>
> Hmm. Looking at the parsing functions, if "strtol()" is broken, and
> accepts periods at the end of the number, I can see this happening.
>
> At the same time, that sounds like some rather odd breakage in a very
> central library function. I can see it happening if some stupid person
> shares code between strtol() and strtod(), though, and gets it wrong.
> Maybe whatever Windows compatibility library is in use is just
> terminally broken.
>
> We should just parse things as scaled integers, and never use FP at
> all - that would work fine for subsurface itself. However, I have seen
> some crazy stuff from jdivelog in particular, where it actually uses
> exponential notation for things, and it would just be too painful to
> try to parse crap like that by hand.
>
> So I'll try to massage things into a form that still uses the FP
> functions, but doesn't rely on the exact error behavior of some of
> these functions quite as much. Hopefully avoiding any subtle C library
> bugs in the process. Using "sscanf()" might be the
> least-likely-to-break-anywhere option.
>
> Lubomir - do you think you could try to re-build the windows binaries
> with the attached patch, just to see if that fixes it?
>
> Ivan - I assume you can't rebuild subsurface on your own?

Could this be related to differences in the locale settings? Subsurface looks 
for a dot, but there are also locales where a comma is used as the decimal point 
symbol.

Jef