| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| 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-07 02:46:23 |
| Message-ID: | 20220807024623.v62stodeyondbpvc@awork3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2022-08-07 11:47:31 +1200, Thomas Munro wrote:
> 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].
Well, right now we don't refuse to build against the "wrong" runtimes, so it's
hard to say whether you're looking at the right runtime. I don't think we need
this if we're (as we should imo) only using the ucrt - that's microsoft's,
which IIUC is ok?
> -/*
> - * strtof() is part of C99; this version is only for the benefit of obsolete
> - * platforms. As such, it is known to return incorrect values for edge cases,
> - * which have to be allowed for in variant files for regression test results
> - * for any such platform.
> - */
We can't remove the result files referenced here yet, due to the double
rounding behaviour?
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-08-07 02:55:14 | Re: failing to build preproc.c on solaris with sun studio |
| Previous Message | Thomas Munro | 2022-08-07 02:29:20 | Re: Cleaning up historical portability baggage |