Re: MSVC: Improve warning options set

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

In response to

Browse pgsql-hackers by date

  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