| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, Bryan Green <dbryan(dot)green(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: MSVC: Improve warning options set |
| Date: | 2025-11-09 00:29:36 |
| Message-ID: | CA+hUKGKXPhcpym_9PDDrXCCdAtuiWaa42msGmdJooMy2PduBZg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Nov 9, 2025 at 10:58 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I don't quite understand how 1758d4244 didn't break building with
> MSVCRT? But if it builds yet doesn't in fact work, that's likely to
> draw complaints from people who didn't spot the documentation change.
I think it links against MinGW shims that at least in some cases can
be replaced at runtime with something looked up by dlsym(), but are
otherwise no-op/fail implementations. I expect it was a moving target
over the decades, because the shims were added with potentially long
lag, ie when someone cared enough to write the patch because their
program was affected. In that problem report we had 'The operating
system could not find any locale data for the locale name "en-US"',
but it beats me whether that was "dummy _create_locale() always
returns NULL[1]" or "found MSVCRT's version of _create_locale() but it
expects locale data files installed at a different location than
UCRT's and they aren't there because MSVCRT is dead and we're chasing
ghosts" :-)
> So I'd lean towards back-patching.
Cool. Will do that after the freeze, unless someone show up with a
concrete reason not to.
[1] https://github.com/mingw-w64/mingw-w64/blob/master/mingw-w64-crt/misc/_create_locale.c#L13
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2025-11-09 01:55:21 | Re: Use bsearch() instead of a manual binary search in syscache.c |
| Previous Message | Michael Paquier | 2025-11-08 23:35:55 | Re: Extend injection_points_attach() to accept a user-defined function |