_isnan() on Windows

On 2018-Jul-10, Emre Hasegeli wrote:

isnan() function is evidently not present on <math.h> on Windows
before Visual Studio 2013. We define it on win32_port.h using
_isnan(). However _isnan() is also not present. It is on <float.h>.
The patch is attached to include this from win32_port.h.

Thanks to Thomas Munro for point this out to me [1]. It is hard to
notice this issue without testing the changes on Windows.

Oh, it looks like commits 33a7101281c6, 8e211f539146, 86dbbf20d849
(probably others) papered over this by the expedient of adding #include
<float.h> to random .c files rather than your patch, which seems the
proper fix.

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

On 2018-Jul-10, Emre Hasegeli wrote:

isnan() function is evidently not present on <math.h> on Windows
before Visual Studio 2013. We define it on win32_port.h using
_isnan(). However _isnan() is also not present. It is on <float.h>.
The patch is attached to include this from win32_port.h.

Thanks to Thomas Munro for point this out to me [1]. It is hard to
notice this issue without testing the changes on Windows.

Oh, it looks like commits 33a7101281c6, 8e211f539146, 86dbbf20d849
(probably others) papered over this by the expedient of adding #include
<float.h> to random .c files rather than your patch, which seems the
proper fix.

I disagree --- including <float.h> in c.h, as this would have us do,
seems like a huge expansion of the visibility of that header. Moreover,
doing that only on Windows seems certain to lead to missing-header
problems in the reverse direction, ie patches developed on Windows
will fail elsewhere.

I think we should stick with the existing coding convention of including
that only in the specific .c files that need it.

regards, tom lane

On 2018-Jul-10, Tom Lane wrote:

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Oh, it looks like commits 33a7101281c6, 8e211f539146, 86dbbf20d849
(probably others) papered over this by the expedient of adding #include
<float.h> to random .c files rather than your patch, which seems the
proper fix.

I disagree --- including <float.h> in c.h, as this would have us do,
seems like a huge expansion of the visibility of that header. Moreover,
doing that only on Windows seems certain to lead to missing-header
problems in the reverse direction, ie patches developed on Windows
will fail elsewhere.

I don't think so, because that's only done for MSVC older than 2013.
Nobody uses that for new development anymore. Downloading versions
prior to 2017 is difficult enough already.

I think we should stick with the existing coding convention of including
that only in the specific .c files that need it.

It seems saner to contain the ugliness to a port-specific file, where it
won't pollute two dozen files for no reason.

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

On 2018-Jul-10, Tom Lane wrote:

I disagree --- including <float.h> in c.h, as this would have us do,
seems like a huge expansion of the visibility of that header. Moreover,
doing that only on Windows seems certain to lead to missing-header
problems in the reverse direction, ie patches developed on Windows
will fail elsewhere.

I don't think so, because that's only done for MSVC older than 2013.
Nobody uses that for new development anymore.

Hm. OK, maybe it's all right given that. I'm still a bit worried
about downsides, but no doubt the buildfarm will tell us.

regards, tom lane

On Tue, Jul 10, 2018 at 04:23:42PM -0400, Tom Lane wrote:

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

On 2018-Jul-10, Tom Lane wrote:

I disagree --- including <float.h> in c.h, as this would have us do,
seems like a huge expansion of the visibility of that header. Moreover,
doing that only on Windows seems certain to lead to missing-header
problems in the reverse direction, ie patches developed on Windows
will fail elsewhere.

I don't think so, because that's only done for MSVC older than 2013.
Nobody uses that for new development anymore.

Hm. OK, maybe it's all right given that. I'm still a bit worried
about downsides, but no doubt the buildfarm will tell us.

It seems to me that this patch is a good idea. Any objections if I take
care of it? I have a Windows VM with only MSVC 2015 if I recall
correctly though...
--
Michael

On 2018-Jul-11, Michael Paquier wrote:

On Tue, Jul 10, 2018 at 04:23:42PM -0400, Tom Lane wrote:

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

On 2018-Jul-10, Tom Lane wrote:

I disagree --- including <float.h> in c.h, as this would have us do,
seems like a huge expansion of the visibility of that header. Moreover,
doing that only on Windows seems certain to lead to missing-header
problems in the reverse direction, ie patches developed on Windows
will fail elsewhere.

I don't think so, because that's only done for MSVC older than 2013.
Nobody uses that for new development anymore.

Hm. OK, maybe it's all right given that. I'm still a bit worried
about downsides, but no doubt the buildfarm will tell us.

It seems to me that this patch is a good idea. Any objections if I take
care of it? I have a Windows VM with only MSVC 2015 if I recall
correctly though...

I just pushed it before seeing your message.

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Wed, Jul 11, 2018 at 09:13:40AM -0400, Alvaro Herrera wrote:

I just pushed it before seeing your message.

Fine as well, thanks for picking this up. The buildfarm shows no
failures about this patch.
--
Michael

Michael Paquier <michael@paquier.xyz> writes:

On Wed, Jul 11, 2018 at 09:13:40AM -0400, Alvaro Herrera wrote:

I just pushed it before seeing your message.

Fine as well, thanks for picking this up. The buildfarm shows no
failures about this patch.

I scraped all the compiler warnings from the buildfarm this morning,
and I see no new ones that could be blamed on this change, so I think
we're good.

bowerbird and hamerkop have some gripes like this:

bowerbird | c:\perl64\lib\core\win32.h(218): warning C4005: 'isnan' : macro redefinition (src/pl/plperl/SPI.c) [G:\prog\bf\root\HEAD\pgsql.build\plperl.vcxproj]
bowerbird | c:\perl64\lib\core\win32.h(218): warning C4005: 'isnan' : macro redefinition (src/pl/plperl/Util.c) [G:\prog\bf\root\HEAD\pgsql.build\plperl.vcxproj]
bowerbird | c:\perl64\lib\core\win32.h(218): warning C4005: 'isnan' : macro redefinition (src/pl/plperl/plperl.c) [G:\prog\bf\root\HEAD\pgsql.build\plperl.vcxproj]
bowerbird | c:\perl64\lib\core\win32.h(218): warning C4005: 'isnan' : macro redefinition [G:\prog\bf\root\HEAD\pgsql.build\hstore_plperl.vcxproj]
bowerbird | c:\perl64\lib\core\win32.h(218): warning C4005: 'isnan' : macro redefinition [G:\prog\bf\root\HEAD\pgsql.build\jsonb_plperl.vcxproj]
bowerbird | c:\perl64\lib\core\win32.h(218): warning C4005: 'isnan' : macro redefinition (src/pl/plperl/SPI.c) [G:\prog\bf\root\HEAD\pgsql.build\plperl.vcxproj]
bowerbird | c:\perl64\lib\core\win32.h(218): warning C4005: 'isnan' : macro redefinition (src/pl/plperl/Util.c) [G:\prog\bf\root\HEAD\pgsql.build\plperl.vcxproj]
bowerbird | c:\perl64\lib\core\win32.h(218): warning C4005: 'isnan' : macro redefinition (src/pl/plperl/plperl.c) [G:\prog\bf\root\HEAD\pgsql.build\plperl.vcxproj]
bowerbird | c:\perl64\lib\core\win32.h(218): warning C4005: 'isnan' : macro redefinition [G:\prog\bf\root\HEAD\pgsql.build\hstore_plperl.vcxproj]
bowerbird | c:\perl64\lib\core\win32.h(218): warning C4005: 'isnan' : macro redefinition [G:\prog\bf\root\HEAD\pgsql.build\jsonb_plperl.vcxproj]

but those were there before too. Not sure if there's anything
we can/should try to do about that.

regards, tom lane

On 07/12/2018 10:20 AM, Tom Lane wrote:

Michael Paquier <michael@paquier.xyz> writes:

On Wed, Jul 11, 2018 at 09:13:40AM -0400, Alvaro Herrera wrote:

I just pushed it before seeing your message.

Fine as well, thanks for picking this up. The buildfarm shows no
failures about this patch.

I scraped all the compiler warnings from the buildfarm this morning,
and I see no new ones that could be blamed on this change, so I think
we're good.

bowerbird and hamerkop have some gripes like this:

bowerbird | c:\perl64\lib\core\win32.h(218): warning C4005: 'isnan' : macro redefinition (src/pl/plperl/SPI.c) [G:\prog\bf\root\HEAD\pgsql.build\plperl.vcxproj]
bowerbird | c:\perl64\lib\core\win32.h(218): warning C4005: 'isnan' : macro redefinition (src/pl/plperl/Util.c) [G:\prog\bf\root\HEAD\pgsql.build\plperl.vcxproj]
bowerbird | c:\perl64\lib\core\win32.h(218): warning C4005: 'isnan' : macro redefinition (src/pl/plperl/plperl.c) [G:\prog\bf\root\HEAD\pgsql.build\plperl.vcxproj]
bowerbird | c:\perl64\lib\core\win32.h(218): warning C4005: 'isnan' : macro redefinition [G:\prog\bf\root\HEAD\pgsql.build\hstore_plperl.vcxproj]
bowerbird | c:\perl64\lib\core\win32.h(218): warning C4005: 'isnan' : macro redefinition [G:\prog\bf\root\HEAD\pgsql.build\jsonb_plperl.vcxproj]
bowerbird | c:\perl64\lib\core\win32.h(218): warning C4005: 'isnan' : macro redefinition (src/pl/plperl/SPI.c) [G:\prog\bf\root\HEAD\pgsql.build\plperl.vcxproj]
bowerbird | c:\perl64\lib\core\win32.h(218): warning C4005: 'isnan' : macro redefinition (src/pl/plperl/Util.c) [G:\prog\bf\root\HEAD\pgsql.build\plperl.vcxproj]
bowerbird | c:\perl64\lib\core\win32.h(218): warning C4005: 'isnan' : macro redefinition (src/pl/plperl/plperl.c) [G:\prog\bf\root\HEAD\pgsql.build\plperl.vcxproj]
bowerbird | c:\perl64\lib\core\win32.h(218): warning C4005: 'isnan' : macro redefinition [G:\prog\bf\root\HEAD\pgsql.build\hstore_plperl.vcxproj]
bowerbird | c:\perl64\lib\core\win32.h(218): warning C4005: 'isnan' : macro redefinition [G:\prog\bf\root\HEAD\pgsql.build\jsonb_plperl.vcxproj]

but those were there before too. Not sure if there's anything
we can/should try to do about that.

We actually undef a bunch of things in plperl.h to keep the compiler
quiet. Maybe we need to add this to the list?

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:

On 07/12/2018 10:20 AM, Tom Lane wrote:

bowerbird and hamerkop have some gripes like this:

bowerbird | c:\perl64\lib\core\win32.h(218): warning C4005: 'isnan' : macro redefinition (src/pl/plperl/SPI.c) [G:\prog\bf\root\HEAD\pgsql.build\plperl.vcxproj]

We actually undef a bunch of things in plperl.h to keep the compiler
quiet. Maybe we need to add this to the list?

Perhaps. But how do we tell the platforms where we should do that
from the ones where we shouldn't?

regards, tom lane

On 07/12/2018 10:38 AM, Tom Lane wrote:

Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:

On 07/12/2018 10:20 AM, Tom Lane wrote:

bowerbird and hamerkop have some gripes like this:

bowerbird | c:\perl64\lib\core\win32.h(218): warning C4005: 'isnan' : macro redefinition (src/pl/plperl/SPI.c) [G:\prog\bf\root\HEAD\pgsql.build\plperl.vcxproj]

We actually undef a bunch of things in plperl.h to keep the compiler
quiet. Maybe we need to add this to the list?

Perhaps. But how do we tell the platforms where we should do that
from the ones where we shouldn't?

In the _MSCVER section:

#ifdef isnan
#undef isnan
#endif

By inspection the perl header is just defining it to _isnan, for every
MSC version.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Hi,

On 2018-07-12 11:28:46 -0400, Andrew Dunstan wrote:

On 07/12/2018 10:38 AM, Tom Lane wrote:

Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:

On 07/12/2018 10:20 AM, Tom Lane wrote:

bowerbird and hamerkop have some gripes like this:

bowerbird | c:\perl64\lib\core\win32.h(218): warning C4005: 'isnan' : macro redefinition (src/pl/plperl/SPI.c) [G:\prog\bf\root\HEAD\pgsql.build\plperl.vcxproj]

We actually undef a bunch of things in plperl.h to keep the compiler
quiet. Maybe we need to add this to the list?

Perhaps. But how do we tell the platforms where we should do that
from the ones where we shouldn't?

In the _MSCVER section:

#ifdef isnan
#undef isnan
#endif

By inspection the perl header is just defining it to _isnan, for every MSC
version.

Let's try undefining it before plperl.h then? It'd be nice to get rid
of those warnings...

Greetings,

Andres Freund

On 11/17/18 2:46 PM, Andres Freund wrote:

Hi,

On 2018-07-12 11:28:46 -0400, Andrew Dunstan wrote:

On 07/12/2018 10:38 AM, Tom Lane wrote:

Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:

On 07/12/2018 10:20 AM, Tom Lane wrote:

bowerbird and hamerkop have some gripes like this:

bowerbird | c:\perl64\lib\core\win32.h(218): warning C4005: 'isnan' : macro redefinition (src/pl/plperl/SPI.c) [G:\prog\bf\root\HEAD\pgsql.build\plperl.vcxproj]

We actually undef a bunch of things in plperl.h to keep the compiler
quiet. Maybe we need to add this to the list?

Perhaps. But how do we tell the platforms where we should do that
from the ones where we shouldn't?

In the _MSCVER section:

#ifdef isnan
#undef isnan
#endif

By inspection the perl header is just defining it to _isnan, for every MSC
version.

Let's try undefining it before plperl.h then? It'd be nice to get rid
of those warnings...

done.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Hi,

On 2018-11-18 12:46:14 -0500, Andrew Dunstan wrote:

On 11/17/18 2:46 PM, Andres Freund wrote:

On 2018-07-12 11:28:46 -0400, Andrew Dunstan wrote:

By inspection the perl header is just defining it to _isnan, for every MSC
version.

Let's try undefining it before plperl.h then? It'd be nice to get rid
of those warnings...

done.

Thanks!

Greetings,

Andres Freund