Re: Cleaning up historical portability baggage
От | Andres Freund |
---|---|
Тема | Re: Cleaning up historical portability baggage |
Дата | |
Msg-id | 20220807024623.v62stodeyondbpvc@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Cleaning up historical portability baggage (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: Cleaning up historical portability baggage
|
Список | 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
В списке pgsql-hackers по дате отправления: