Decimal values rounded on save

[Linus Torvalds]

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?

                     Linus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.diff
Type: application/octet-stream
Size: 839 bytes
Desc: not available
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20120903/9f586404/attachment.obj>