On Tue, Mar 24, 2015 at 10:37 PM, Tom Lane wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
>> For example by passing 2.5, we would get 3.0, and not 2.0 (nearest
>> even number). So isn't the problem here?
>
> Hmm ... why are we using src/port's version? rint() has been required
> by POSIX for decades, surely MSVC has got it?
>
> (IOW, I'd rather fix this by removing src/port's version than by
> trying to upgrade it to full IEEE spec.)
rint() has been added in MSVC 2013, per se for example this thing
introduced by cec8394:
src/tools/msvc/Mkvcbuild.pm: push(@pgportfiles, 'rint.c') if
($vsVersion < '12.00');
So I would imagine that in a majority of cases the version of rint()
used by an MSVC build on Windows is src/port/rint.c, not to mention
that on platforms where rint() is not available (the world is full of
surprises), the behavior would be incorrect. It is possible to blame
Redmond's folks about missing rint() from MSVC for more than 10 years,
but the blame could be put on PG-side as well.
Hence I'd rather think that patching src/port is the way to go, with
for example something like the patch attached. That's a behavioral
change, so maybe a backpatch is not welcome. See for example Rich's
email meaning that 9.4 behavior is broken as I understand it, but
that's actually the other way around, and I suspect that the version
of 9.4 Rich has used was built with at least MSVC 2013, while the
version of 9.3 he used was built with src/port/rint.c.
--
Michael