| 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 |
| 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 |