Re: [PATCH] Improve geometric types

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: Emre Hasegeli <emre(at)hasegeli(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Subject: Re: [PATCH] Improve geometric types
Date: 2018-07-09 21:38:00
Message-ID: CAEepm=3dE0w=_dOcELpPum6suze2NZwc=AV4T_xYrDUoHbZJvA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 10, 2018 at 7:21 AM, Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> On 06/05/2018 06:32 PM, Emre Hasegeli wrote:
>>> Those underscore-prefixed names are defined in Microsoft's
>>> <float.h>[3][4]. So now I'm wondering if win32_port.h needs to
>>> #include <float.h> if (_MSC_VER < 1800).
>>
>> I don't have the C experience to decide the correct way. There are
>> currently many .c files that are including float.h conditionally or
>> unconditionally. The condition they use is "#ifdef _MSC_VER" without
>> a version.
>>
>> One idea is to include float.h from the new utils/float.h file
>> together with math.h, and remove those includes from the .c files
>> which would include utils/float.h. We can do this only, or together
>> with what you suggest, or by also keeping the includes on the .c
>> files. Which way do you think is the proper?
>>
>
> Do we have any solution to the float.h include issues on Windows? I
> don't have any Windows box at hand so I can't verify it, but just using
> "#ifdef _MSC_VER" seems OK to me (and it's used elsewhere). Thomas, why
> do you think the version number restriction is needed here? I don't see
> the version mentioned in the MS docs you linked either.

The version number restriction isn't strictly needed. I only
suggested it because it'd match the #if that wraps the code that's
actually using those macros, introduced by commit cec8394b5ccd. That
was presumably done because versions >= 1800 (= Visual Studio 2013)
have their own definitions of isinf() and isnan(), and I guess that
our definitions were probably breaking stuff on that compiler.

> Once this gets resolved, I'd like to get this committed ... so if you
> have other objections, please speak now.

+1, no objections.

--
Thomas Munro
http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-07-09 21:41:12 Re: pgsql: Add wait event for fsync of WAL segments
Previous Message Konstantin Knizhnik 2018-07-09 21:35:31 Re: WAL prefetch