Re: Cleaning up historical portability baggage

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

In response to

Responses

Browse pgsql-hackers by date

  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