David Rowley <dgrowleyml@gmail.com> writes:
> On Tue, 7 Oct 2025 at 04:24, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I wonder if we couldn't also remove the NAN hacks in the same file.
>> NAN's been required since C99 as well, and it's equally hard to
>> believe that we still need to support compilers that don't conform.
>>
>> (Strictly speaking, NAN is required only if the underlying float
>> implementation has it. But we desupported non-IEEE float arithmetic
>> years ago.)
> I saw the "The macro NAN is defined if and only if the implementation
> supports quiet NaNs for the float type." in the standard and that
> causes me to stop at INFINITY.
Well, we know that all supported platforms have quiet NaNs, because
otherwise they'd not be passing our regression tests. The problem
was just old non-C99-compliant C compilers. It's *really* hard to
believe that anything supporting C11-or-later doesn't have the NAN
macro.
Given the wording of the spec, I'm slightly tempted to put in
#ifndef NAN
#error "Postgres requires support for IEEE quiet NaNs"
#endif
but it's probably just a waste of effort.
> I'd be happy for someone else to
> continue. I'm a bit hesitant due to the "#if defined(NAN) &&
> !(defined(__NetBSD__) && defined(__mips__))", which are systems I have
> little knowledge of.
Fair enough, I'll take responsibility for that bit. Might as well
wait to see how the BF likes the INFINITY change, though.
regards, tom lane
