From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Cleaning up historical portability baggage |
Date: | 2022-08-06 23:47:31 |
Message-ID: | CA+hUKGLyGrqbC_YgW_+Fa1mLKev-WGmta1cDC5nVp+iuQ3bE0A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Aug 6, 2022 at 9:08 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> [stuff about strtoll, strtoull]
So what about strtof? That's gotta be dead code too. I gather we
still need commit 72880ac1's HAVE_BUGGY_STRTOF. From a cursory glance
at MinGW's implementation, it still has the complained-about
behaviour, if I've understood the complaint, and if I'm looking at the
right C runtime[1]. But then our code says:
* Test results on Mingw suggest that it has the same problem, though looking
* at the code I can't figure out why.
... so which code was that referring to then? I'm not up to speed on
how many C runtime libraries there are and how they are selected on
MSYS (I mean, the closest I've ever got to this system is flinging
patches at it on CI using Melih's patch, which, incidentally, I just
tested the attached with and it passed[2]).
[1] https://github.com/mirror/mingw-w64/blob/master/mingw-w64-crt/stdio/strtof.c
[2] https://github.com/macdice/postgres/runs/7708082971
Attachment | Content-Type | Size |
---|---|---|
0001-Simplify-replacement-code-for-strtof.patch | text/x-patch | 4.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-08-06 23:52:16 | Re: failing to build preproc.c on solaris with sun studio |
Previous Message | Thomas Munro | 2022-08-06 23:29:55 | Re: Cleaning up historical portability baggage |