Re: MSVC: Improve warning options set - Mailing list pgsql-hackers

On Tue, Nov 4, 2025 at 7:56 AM Peter Eisentraut <peter@eisentraut.org> wrote:
> On 31.10.25 14:31, Bryan Green wrote:
> > The real question is MinGW. If we still support MinGW builds targeting
> > the old MSVCRT, those need the environ declaration. If we require MinGW
> > with UCRT, we don't. You'd need something like "#if defined(MINGW32)
> > && !defined(_UCRT)" to distinguish them, if it matters.
>
> As of commit 1758d424461 (PG18) we require UCRT if using MinGW.
>
> I don't know if we still support MSVCRT if using MSVC, or how long we
> still need to support it.  (Or, for example, how to tell which variant
> CI or the buildfarm uses.)

The main CI task and build farm animal fairywren use UCRT, so there is
no automated test coverage for the old runtime and hasn't been for
some time, and that's also the default with that toolchain these day.
There is still one place that builds (without running) against MSVCRT
in CI: the CompilerWarnings mingw cross-compilation task that runs on
Debian.  In commit 1758d424461, we officially  stopped thinking about
the implications for MSVCRT builds and allowed ourselves to begin
ripping out the long tail of weird distortions in our code due to that
historical train wreck, but we were unsure when exactly PostgreSQL
would become actually unbuildable with MSVCRT and I for one was not
aware that the cross-build was doing that at the time.  Unfortunately
it didn't ever seem to become unbuildable, but apparently things break
in undiagnosed ways at runtime (at a guess it might have some API
calls that are stubbed out with empty implementations or something
like that, but there is zero reason to investigate that, it's dead).
What we should do to make this clearer and avoid spurious problem
reports is error out unless you're on UCRT, but a patch for that got
stuck waiting for the Debian images used on CI to be upgraded to
Debian trixie, because that shipped the necessary newer
MinGW/headers/etc in its cross-build packages.  That has now happened,
so we should probably go ahead with something like the patch I posted
here:


https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BQJv-g7C2APVV7O_jEJkxH1AmvgAe8X2vDR8mRdSKn3A%40mail.gmail.com#e6d0c91e2f59e6e39eb61095da4cc598

In theory we could even back-patch that to 18, since we already know
it won't fully work and we already declared that we don't support it.
Or we could just let sleeping dogs lie and do that for 19.