Several float to int potential rounding errors/inconsistencies
Dirk Hohndel
dirk at hohndel.org
Sat Mar 11 07:24:42 PST 2017
On Sat, Mar 11, 2017 at 03:41:53PM +0200, Lubomir I. Ivanov wrote:
> On 11 March 2017 at 07:21, Jérémie Guichard <djeBrest at gmail.com> wrote:
> > Hey guys,
> >
> > I've added the flag conditionally as discussed in previous mail, and updated
> > the pull request.
>
> i've tested the changes locally on Windows and it builds fine.
> llrint() is also available.
>
> 4.9.0 seems to be the version they've added "float-conversation", so
> this is correct:
>
> + if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS "4.9.0")
> + set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wfloat-conversion")
> + endif()
>
> of course, there is no need of lrint() in a lot of locations and
> rint() can be used instead, like here:
>
> - sample->depth.mm = depth * FEET * 1000;
> + sample->depth.mm = lrint(depth * FEET * 1000);
I find changes like this not only unnecessary but also potentially
confusing.
> here, t1 is of type int as well:
> + int t1 = lrint(max_d / slope);
> but that's not a big issue as long as numbers are not truncated for
> 64bit builds.
> our main Windows build is 32bit, so this is pretty much in effect:
> sizeof(long) == sizeof(int).
I keep wondering at which point it would make sense to switch to 64bit
builds for Windows as well. Our stats still show a small but fairly stable
share of 32bit systems running Subsurface. But then again, we also have a
few people on 4.5 running Windows XP :-)
> i haven't tested if the changes break functionality in some way, hopefully not.
If we had better tests, we could use those to test that nothing breaks...
/D
More information about the subsurface
mailing list