Re: src/include/utils/float.h comment one link stable
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Daniel Gustafsson <daniel@yesql.se>,
jian he <jian.universality@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-10-07T23:11:55Z
Lists: pgsql-hackers
On Tue, 7 Oct 2025 at 04:24, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > David Rowley <dgrowleyml@gmail.com> writes: > > Going by the draft C11 standard in [3], on page 230 it looks like > > INFINITY is always defined now, so maybe we can get rid of the other > > code and just always "return (float4) INFINITY;"? I did try that with > > VS2022 just to make sure and I don't get a warning. > > +1, let's give that a try. However, INFINITY has been required since > C99, so please don't change that comment. I got a clean bill of health from CI [1] for this patch, so went ahead and pushed it after putting the C99 comments back. The VS2019 CI instance seems happy and free from any new warnings. > 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. 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. David [1] https://cirrus-ci.com/build/5341920676806656
Commits
-
Cleanup NAN code in float.h, too.
- 14ad0d7bf2b8 19 (unreleased) landed
-
Cleanup INFINITY code in float.h
- 3bf905692c9d 19 (unreleased) landed
-
Enable MSVC conforming preprocessor
- 8fd9bb1d9654 19 (unreleased) cited