Re: PRI?64 vs Visual Studio (2022)

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: PRI?64 vs Visual Studio (2022)
Date: 2025-11-23 03:10:15
Message-ID: CA+hUKGJ0J-H8C51HK8pEGdbD7tVuut5igkRhFt0byWm_CezeoQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 19, 2025 at 3:13 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> I was also curious to know if the nearby floating point formatting
> kludge added by commit f1885386 was still needed today. CI passes
> without it, and the standard is pretty clear: "The exponent always
> contains at least two digits, and only as many more digits as
> necessary to represent the exponent". I didn't look too closely at
> the fine print, but that text was already present in C89 so I guess
> MSVCRT just failed to conform on that point.

We can also drop HAVE_BUGGY_STRTOF for MinGW. This passes on CI.

That'd leave only Cygwin with HAVE BUGGY_STRTOF. Perhaps they have
fixed their implementation[1]? Here's an experimental patch to drop
all remnants, which could be used to find out. No Windows/Cygwin
here. Hmm, what if we just commit it anyway? If their strtof() is
still broken and someone out there is running the tests and sees this
test fail, why shouldn't they take that up with libc at this stage?

[1] https://github.com/cygwin/cygwin/commit/fb01286fab9b370c86323f84a46285cfbebfe4ff

Attachment Content-Type Size
0001-Drop-HAVE_BUGGY_STRTOF-for-MinGW.patch text/x-patch 4.4 KB
0002-Drop-HAVE_BUGGY_STRTOF-for-Cygwin.patch text/x-patch 44.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-11-23 03:25:56 Re: PRI?64 vs Visual Studio (2022)
Previous Message ocean_li_996 2025-11-23 02:15:24 Re:[BUG] Incorrect historic snapshot may be serialized to disk during fast-forwarding