Re: Cleaning up historical portability baggage - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Cleaning up historical portability baggage
Date
Msg-id CA+hUKGLyGrqbC_YgW_+Fa1mLKev-WGmta1cDC5nVp+iuQ3bE0A@mail.gmail.com
Whole thread Raw
In response to Re: Cleaning up historical portability baggage  (Andres Freund <andres@anarazel.de>)
Responses Re: Cleaning up historical portability baggage
Re: Cleaning up historical portability baggage
List pgsql-hackers
On Sat, Aug 6, 2022 at 9:08 AM Andres Freund <andres@anarazel.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

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Cleaning up historical portability baggage
Next
From: Andres Freund
Date:
Subject: Re: failing to build preproc.c on solaris with sun studio