Re: Patch: make behavior of all versions of the "isinf" function be similar

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch: make behavior of all versions of the "isinf" function be similar
Date: 2016-02-01 07:04:45
Message-ID: 68333.1454310285@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> On Mon, Feb 1, 2016 at 2:38 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> Actually, is there actually a reason to keep this file in the code
>> tree? Are there platforms that do not have isinf()? Even for Windows
>> environments using MSVC < 1800 this is emulated using _fpclass.

> Looking at what is in the buildfarm, I noticed that isinf is provided
> everywhere. Attached is a patch. Thoughts?

Two comments:

1. I don't think the buildfarm is sufficient evidence to conclude that
isinf.c is required nowhere. It was in use as late as 2004, judging
by the git history, and I don't know of good reason to assume we do not
need it now.

2. POSIX:2008 only requires that "The isinf() macro shall return a
non-zero value if and only if its argument has an infinite value."
Therefore, any assumption about the sign of the result is wrong anyway,
and any patch that depends on it will be rejected, regardless of what
isinf.c does. Or else, if you can convince us that such an assumption
is really valuable, we'd need isinf.c more not less so that we can
replace isinf() on platforms where it doesn't meet the stronger spec.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2016-02-01 07:26:18 Re: [PATCH] Refactoring of LWLock tranches
Previous Message Michael Paquier 2016-02-01 06:42:14 Re: extend pgbench expressions with functions