C11 / VS 2019
I propose that we raise the baseline C standard for PostgreSQL to C11
for PostgreSQL 19. This will allow us to make use of some new features,
clear away a bunch of backward compatibility cruft, unify use of
compiler-specific extensions, and narrow the range of compatibility
concerns for some efforts like improved threads support. Most compilers
other than older versions of MSVC (about which see below) have supported
C11 for quite some time and most use it by default, so for most
developers and packagers this wouldn't effectively change anything
except removing some restrictions about what features they can use.
(I mentioned some of this in my presentation at pgconf.dev; I will
repeat the relevant points here. You can see my presentation at [0]https://www.pgevents.ca/events/pgconfdev2025/schedule/session/271-what-is-new-in-c-and-posix/.)
[0]: https://www.pgevents.ca/events/pgconfdev2025/schedule/session/271-what-is-new-in-c-and-posix/
https://www.pgevents.ca/events/pgconfdev2025/schedule/session/271-what-is-new-in-c-and-posix/
Here are some of the features we could use. This is just for
inspiration right now, these would all be separate proposals:
- alignas specifier to allow specifying larger alignments more portably,
e.g., for direct I/O
- noreturn, already in use but would allow removing
backwards-compatibility code
- static assertions, we currently have 12(!) different implementations
for this, could maybe cut down to 2
- allow typedef redefinitions, to untangle header files (see for example
recent discussion [1]/messages/by-id/f36c0a45-98cd-40b2-a7cc-f2bf02b12890@eisentraut.org)
- anonymous unions, mostly aesthetic
- generic selection, for some more type safety in certain cases
- threads library (needs separate consideration, see [2]/messages/by-id/CA+hUKGLtmexrpMtxBRLCVePqV_dtWG-ZsEbyPrYc+NBB2TkNsw@mail.gmail.com)
- atomic types, to maybe simplify some of our atomics support
[1]: /messages/by-id/f36c0a45-98cd-40b2-a7cc-f2bf02b12890@eisentraut.org
/messages/by-id/f36c0a45-98cd-40b2-a7cc-f2bf02b12890@eisentraut.org
[2]: /messages/by-id/CA+hUKGLtmexrpMtxBRLCVePqV_dtWG-ZsEbyPrYc+NBB2TkNsw@mail.gmail.com
/messages/by-id/CA+hUKGLtmexrpMtxBRLCVePqV_dtWG-ZsEbyPrYc+NBB2TkNsw@mail.gmail.com
(Note: While the term "threads" appears here, this is independent of any
work on a multithreaded server. It probably wouldn't hurt, but it's not
a hard prerequisite as far as I know.)
The minimum required compiler versions for C11 support among the most
common compilers are:
- gcc 4.6/4.7/4.9 (depending on what feature)
- clang 3.1/3.2/3.3 (depending on what feature)
- Visual Studio (VS) 2019 (2022 for threads)
I have also checked the following less common compilers:
- Oracle Developer Studio 12.6, which is in the buildfarm, supports C11
ok (manually tested)
- Intel ICC 17.0.0 is ok (not in the buildfarm, tested on godbolt)
- AIX xlclang, which is currently not supported but might come back,
also supports C11
I think this covers all relevant compilers.
Visual Studio details: As shown above, C11 would require VS 2019. The
current minimum version required by PostgreSQL 18 is VS 2015. Can we
move forward from that? There isn't much data to extrapolate a VS
version support policy from. When MSVC support was initially added in
PG8.3, it required VS 2005, which was just the latest at the time. Then
it was not changed for a long time, until PG12 required VS 2013, which
was exactly for the C99 support. Then it was changed once more for
PG16, requiring VS 2015; AFAICT, this was just to be able to clean away
some conditional C code. I don't recall any complaints about any of
that. Note that PG12/VS2013 corresponds arithmetically to PG18/VS2019,
so making a move in PG19 would be less restrictive than that previous
change. I'll also note that we haven't had any test coverage for
anything older than VS 2019 for quite some time. I also remember commit
f9f31aa91f8, where we discovered that the code didn't build with VS 2015
after one year, and that was two years ago, so it seems like there isn't
too much interest in trailing edge VS versions in general. So I feel
comfortable moving this forward.
GCC details: The oldest gcc version that we currently need to support is
gcc 4.8, which comes with RHEL 7. As alluded to above, some C11
features came later with gcc 4.9, specifically generic, threads, and
atomics. I think it would still be useful to move forward without those
features. Threads and atomics are out of scope anyway because they
require VS >=2022, which I'm not prepared to require. And generic,
well, we'll just have to do without that for the moment. We can of
course have a separate discussion sometime about when to drop RHEL 7
support, but it doesn't have to be a prerequisite for this.
(Both gcc pre-4.9 and MSVC pre-2019 do support thread-local storage,
just not the C11 spelling, so this is at least on paper not a blocker
for a multithreaded server.)
Clang details: I don't think anyone cares about clang versions that old.
There is a clang 4.0 in the build farm, but I don't think even that
has any practical relevance.
I would also set the minimum supported C++ version to C++11. This is
the level required for, for example, static assertions (and also threads
and atomic types), so it makes some sense to align this with the C side.
Compilers tend to implement C++ features before C features, so this
wouldn't set any additional requirements on compiler versions in practice.
Summary:
1. require VS 2019
2. use C11
Thoughts?
On Mon, Jun 02, 2025 at 05:44:12AM +0200, Peter Eisentraut wrote:
Summary:
1. require VS 2019
2. use C11Thoughts?
+1
--
nathan
On Mon, Jun 02, 2025 at 08:52:00AM -0500, Nathan Bossart wrote:
On Mon, Jun 02, 2025 at 05:44:12AM +0200, Peter Eisentraut wrote:
Summary:
1. require VS 2019
2. use C11Thoughts?
+1
+1 to move on for both of these. I got convinced about the benefits
of C11 and the simplifications we could get from it in the Postgres
code base during your presentation at pgconf.dev.
Dropping VS 2015 and going up to VS 2019 brings other benefits,
__VA_ARGS__ coming in mind. I am wondering what's the state of
locales, actually. We've had some pain with VS 2015 as we lacked
locale_name in _locale_t, for example. That may be worth a second
look to see if some simplifications can happen in this area. I don't
think so at quick glance through the VS docs, unfortunately, but I may
be wrong, of course..
--
Michael
03.06.2025 07:51, Michael Paquier wrote:
On Mon, Jun 02, 2025 at 08:52:00AM -0500, Nathan Bossart wrote:
On Mon, Jun 02, 2025 at 05:44:12AM +0200, Peter Eisentraut wrote:
Summary:
1. require VS 2019
2. use C11Thoughts?
+1
+1 to move on for both of these. I got convinced about the benefits
of C11 and the simplifications we could get from it in the Postgres
code base during your presentation at pgconf.dev.Dropping VS 2015 and going up to VS 2019 brings other benefits,
__VA_ARGS__ coming in mind. I am wondering what's the state of
locales, actually. We've had some pain with VS 2015 as we lacked
locale_name in _locale_t, for example. That may be worth a second
look to see if some simplifications can happen in this area. I don't
think so at quick glance through the VS docs, unfortunately, but I may
be wrong, of course..
Will it mean we can implement atomics in term of C11 atomics?
Aside for VS 2019, which has no support for. (But VS 2022 already has.)
So instead of numerous variants we could just differ VS2019 vs plain C11.
--
regards
Yura Sokolov aka funny-falcon
Yura Sokolov <y.sokolov@postgrespro.ru> writes:
Will it mean we can implement atomics in term of C11 atomics?
Any such change would have to be supported by extensive performance
testing to verify that there's not a regression on any supported
platform. Yeah, it'd be cool if we could rip out a lot of that
code, but we aren't going to just rip on faith.
regards, tom lane
On Wed, Jun 4, 2025 at 2:02 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Yura Sokolov <y.sokolov@postgrespro.ru> writes:
Will it mean we can implement atomics in term of C11 atomics?
Any such change would have to be supported by extensive performance
testing to verify that there's not a regression on any supported
platform. Yeah, it'd be cool if we could rip out a lot of that
code, but we aren't going to just rip on faith.
FWIW I posted an experimental patch like that at:
/messages/by-id/CA+hUKG+w-2RyyYUte_mSAunoRE00bQUCG44=FiOuyMaN-6uoOw@mail.gmail.com
To make progress down this path, yeah, we'd definitely want to do a
bunch of cross-platform evaluation work, ie performance valuation and
probably reading assembler. Note that in that experiment I just
mapped to the non-_explicit() variants (in other words all the
operations are defaulting to memory_order_seq_cst, which is too strong
in many cases), so we'd also what to think hard about which of the
pg_atomics operations should use _explicit() with a weaker
memory_order. Nearby there are also patches to change our spinlocks
to use pg_atomics, so then that just becomes standard C11 code too.
Assuming all that can be ironed out, AFAIK there is only one piece
that we'll still need to hand-roll, because C11 doesn't provide
anything like it: pg_spin_delay_impl(). (I haven't looked into
whether there is anything standard proposed to deal with that in some
future C.)
On 03.06.25 06:51, Michael Paquier wrote:
Dropping VS 2015 and going up to VS 2019 brings other benefits,
__VA_ARGS__ coming in mind.
Yes, this was going to be my next step. As we're already talking about
it, here is my proposed patch.
For an explanation, the background is that MSVC has a "traditional"
preprocessor and a new "conforming" one. The latter is available
starting in VS 2019, but it's not the default. We have some code,
especially around __VA_ARGS__ that specifically caters to this
traditional preprocessor.
Turning on C11 mode in MSVC (/std:c11) automatically turns on the
conforming preprocessor, which would currently break compilation on MSVC
because the code expects it to be in traditional mode.
So my first patch is that we fix that bit and turn on just the
conforming preprocessor (/Zc:preprocessor), without turning on C11 yet.
That way, we get that part out of the way, and we update the
documentation about requiring VS 2019. (And we'd flush out anyone who
might still be running pre-VS-2019 build jobs somewhere.) Later, when
we turn on C11, we can remove the explicit /Zc:preprocessor option again.
(An alternative approach would be to turn on C11 and add another option
to explicitly turn the traditional preprocessor back on, but that seems
pointless, and the documentation also suggests that that combination is
not well supported.)
So the attached patch is my proposal to commit early in PG19.
Attachments:
0001-Enable-MSVC-conforming-preprocessor.patchtext/plain; charset=UTF-8; name=0001-Enable-MSVC-conforming-preprocessor.patchDownload+6-26
On 03.06.25 10:01, Yura Sokolov wrote:
Will it mean we can implement atomics in term of C11 atomics?
Aside for VS 2019, which has no support for. (But VS 2022 already has.)
So instead of numerous variants we could just differ VS2019 vs plain C11.
I wrote:
"""
GCC details: The oldest gcc version that we currently need to support is
gcc 4.8, which comes with RHEL 7. As alluded to above, some C11
features came later with gcc 4.9, specifically generic, threads, and
atomics. I think it would still be useful to move forward without those
features.
"""
So there is additional homework to do there.
On 04.06.25 08:15, Peter Eisentraut wrote:
On 03.06.25 06:51, Michael Paquier wrote:
Dropping VS 2015 and going up to VS 2019 brings other benefits,
__VA_ARGS__ coming in mind.Yes, this was going to be my next step. As we're already talking about
it, here is my proposed patch.For an explanation, the background is that MSVC has a "traditional"
preprocessor and a new "conforming" one. The latter is available
starting in VS 2019, but it's not the default. We have some code,
especially around __VA_ARGS__ that specifically caters to this
traditional preprocessor.Turning on C11 mode in MSVC (/std:c11) automatically turns on the
conforming preprocessor, which would currently break compilation on MSVC
because the code expects it to be in traditional mode.So my first patch is that we fix that bit and turn on just the
conforming preprocessor (/Zc:preprocessor), without turning on C11 yet.
That way, we get that part out of the way, and we update the
documentation about requiring VS 2019. (And we'd flush out anyone who
might still be running pre-VS-2019 build jobs somewhere.) Later, when
we turn on C11, we can remove the explicit /Zc:preprocessor option again.(An alternative approach would be to turn on C11 and add another option
to explicitly turn the traditional preprocessor back on, but that seems
pointless, and the documentation also suggests that that combination is
not well supported.)So the attached patch is my proposal to commit early in PG19.
I have committed this.
Peter Eisentraut <peter@eisentraut.org> writes:
On 04.06.25 08:15, Peter Eisentraut wrote:
For an explanation, the background is that MSVC has a "traditional"
preprocessor and a new "conforming" one. The latter is available
starting in VS 2019, but it's not the default. We have some code,
especially around __VA_ARGS__ that specifically caters to this
traditional preprocessor.
I have committed this.
Buildfarm member drongo has been failing in initdb since 1 July:
selecting default time zone ... UTC
creating configuration files ... ok
running bootstrap script ...
----------------------------------- stderr -----------------------------------
TRAP: failed Assert("SysCache[cacheId]->cc_nkeys == 2"), File: "../pgsql/src/backend/utils/cache/syscache.c", Line: 237, PID: 2684
child process was terminated by exception 0xC0000409
While there are 19 new commits in the first run that shows this
failure [1]https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=drongo&dt=2025-07-01%2016%3A09%3A21, the only one that looks plausibly related is
8fd9bb1d965 Tue Jul 1 07:41:40 2025 UTC Enable MSVC conforming preprocessor
because that changed our implementation of VA_ARGS_NARGS(), which is
what's used to compute the cc_nkeys fields for syscaches.
My conclusion is that Microsoft's "standards conforming" preprocessor
is not so standards conforming as all that.
regards, tom lane
[1]: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=drongo&dt=2025-07-01%2016%3A09%3A21
On 06.07.25 00:27, Tom Lane wrote:
Peter Eisentraut <peter@eisentraut.org> writes:
On 04.06.25 08:15, Peter Eisentraut wrote:
For an explanation, the background is that MSVC has a "traditional"
preprocessor and a new "conforming" one. The latter is available
starting in VS 2019, but it's not the default. We have some code,
especially around __VA_ARGS__ that specifically caters to this
traditional preprocessor.I have committed this.
Buildfarm member drongo has been failing in initdb since 1 July:
selecting default time zone ... UTC
creating configuration files ... ok
running bootstrap script ...
----------------------------------- stderr -----------------------------------
TRAP: failed Assert("SysCache[cacheId]->cc_nkeys == 2"), File: "../pgsql/src/backend/utils/cache/syscache.c", Line: 237, PID: 2684
child process was terminated by exception 0xC0000409While there are 19 new commits in the first run that shows this
failure [1], the only one that looks plausibly related is8fd9bb1d965 Tue Jul 1 07:41:40 2025 UTC Enable MSVC conforming preprocessor
because that changed our implementation of VA_ARGS_NARGS(), which is
what's used to compute the cc_nkeys fields for syscaches.My conclusion is that Microsoft's "standards conforming" preprocessor
is not so standards conforming as all that.
Hmm. We have the (allegedly) same VS version in Cirrus CI, and it's
never shown a problem like this.
I wonder if there could be a local problem on this host. Perhaps the
ccache or pch cache could use a cleaning up?
Hi,
On Mon, 7 Jul 2025 at 13:51, Peter Eisentraut <peter@eisentraut.org> wrote:
On 06.07.25 00:27, Tom Lane wrote:
Peter Eisentraut <peter@eisentraut.org> writes:
On 04.06.25 08:15, Peter Eisentraut wrote:
For an explanation, the background is that MSVC has a "traditional"
preprocessor and a new "conforming" one. The latter is available
starting in VS 2019, but it's not the default. We have some code,
especially around __VA_ARGS__ that specifically caters to this
traditional preprocessor.I have committed this.
Buildfarm member drongo has been failing in initdb since 1 July:
selecting default time zone ... UTC
creating configuration files ... ok
running bootstrap script ...
----------------------------------- stderr -----------------------------------
TRAP: failed Assert("SysCache[cacheId]->cc_nkeys == 2"), File: "../pgsql/src/backend/utils/cache/syscache.c", Line: 237, PID: 2684
child process was terminated by exception 0xC0000409While there are 19 new commits in the first run that shows this
failure [1], the only one that looks plausibly related is8fd9bb1d965 Tue Jul 1 07:41:40 2025 UTC Enable MSVC conforming preprocessor
because that changed our implementation of VA_ARGS_NARGS(), which is
what's used to compute the cc_nkeys fields for syscaches.My conclusion is that Microsoft's "standards conforming" preprocessor
is not so standards conforming as all that.Hmm. We have the (allegedly) same VS version in Cirrus CI, and it's
never shown a problem like this.
CI uses the latest VS 2019 (v16.11.48), it looks like buildfarm member
drongo uses VS 2019 v16.3.1. I created a custom Windows VM with the
same VS 2019 version (v16.3.1) at the drongo and CI failed with the
same error [1]https://cirrus-ci.com/task/6271845944524800.
[1]: https://cirrus-ci.com/task/6271845944524800
--
Regards,
Nazir Bilal Yavuz
Microsoft
Nazir Bilal Yavuz <byavuz81@gmail.com> writes:
On Mon, 7 Jul 2025 at 13:51, Peter Eisentraut <peter@eisentraut.org> wrote:
Hmm. We have the (allegedly) same VS version in Cirrus CI, and it's
never shown a problem like this.
CI uses the latest VS 2019 (v16.11.48), it looks like buildfarm member
drongo uses VS 2019 v16.3.1. I created a custom Windows VM with the
same VS 2019 version (v16.3.1) at the drongo and CI failed with the
same error [1].
Huh. Can we trawl the release notes for VS and see if this was
acknowledged as a bug fix, and if so when did it happen? I think
whether we can say "get a newer compiler" depends in part on how
long it's been fixed.
regards, tom lane
On 2025-07-07 Mo 10:13 AM, Tom Lane wrote:
Nazir Bilal Yavuz<byavuz81@gmail.com> writes:
On Mon, 7 Jul 2025 at 13:51, Peter Eisentraut<peter@eisentraut.org> wrote:
Hmm. We have the (allegedly) same VS version in Cirrus CI, and it's
never shown a problem like this.CI uses the latest VS 2019 (v16.11.48), it looks like buildfarm member
drongo uses VS 2019 v16.3.1. I created a custom Windows VM with the
same VS 2019 version (v16.3.1) at the drongo and CI failed with the
same error [1].Huh. Can we trawl the release notes for VS and see if this was
acknowledged as a bug fix, and if so when did it happen? I think
whether we can say "get a newer compiler" depends in part on how
long it's been fixed.
Meanwhile I will update drongo anyway.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 07.07.25 16:13, Tom Lane wrote:
Nazir Bilal Yavuz <byavuz81@gmail.com> writes:
On Mon, 7 Jul 2025 at 13:51, Peter Eisentraut <peter@eisentraut.org> wrote:
Hmm. We have the (allegedly) same VS version in Cirrus CI, and it's
never shown a problem like this.CI uses the latest VS 2019 (v16.11.48), it looks like buildfarm member
drongo uses VS 2019 v16.3.1. I created a custom Windows VM with the
same VS 2019 version (v16.3.1) at the drongo and CI failed with the
same error [1].Huh. Can we trawl the release notes for VS and see if this was
acknowledged as a bug fix, and if so when did it happen? I think
whether we can say "get a newer compiler" depends in part on how
long it's been fixed.
I tried doing that now, but didn't find anything fitting.
But this one [0]https://learn.microsoft.com/en-us/cpp/preprocessor/preprocessor-experimental-overview?view=msvc-170 seems to indicate you might need at least 16.5 for this.
Also, there is the support timeline [1]https://learn.microsoft.com/en-us/visualstudio/releases/2019/servicing-vs2019 that shows that anything older
than 16.11.* is way out of support.
[0]: https://learn.microsoft.com/en-us/cpp/preprocessor/preprocessor-experimental-overview?view=msvc-170
https://learn.microsoft.com/en-us/cpp/preprocessor/preprocessor-experimental-overview?view=msvc-170
[1]: https://learn.microsoft.com/en-us/visualstudio/releases/2019/servicing-vs2019
https://learn.microsoft.com/en-us/visualstudio/releases/2019/servicing-vs2019
Peter Eisentraut <peter@eisentraut.org> writes:
On 07.07.25 16:13, Tom Lane wrote:
Huh. Can we trawl the release notes for VS and see if this was
acknowledged as a bug fix, and if so when did it happen?
But this one [0] seems to indicate you might need at least 16.5 for this.
Ah, that says
Starting in Visual Studio 2019 version 16.5, preprocessor support
for the C++20 standard is feature-complete. These changes are
available by using the /Zc:preprocessor compiler switch.
The reference to C++20 is a bit confusing in this context; does C++
really have a different preprocessor? But anyway, the support matrix
seems like a convincing argument that we don't have to support 16.3.
If Andrew is willing to update drongo, I'm content to leave it at
that.
regards, tom lane
On 2025-07-07 Mo 12:01 PM, Tom Lane wrote:
Peter Eisentraut <peter@eisentraut.org> writes:
On 07.07.25 16:13, Tom Lane wrote:
Huh. Can we trawl the release notes for VS and see if this was
acknowledged as a bug fix, and if so when did it happen?But this one [0] seems to indicate you might need at least 16.5 for this.
Ah, that says
Starting in Visual Studio 2019 version 16.5, preprocessor support
for the C++20 standard is feature-complete. These changes are
available by using the /Zc:preprocessor compiler switch.The reference to C++20 is a bit confusing in this context; does C++
really have a different preprocessor? But anyway, the support matrix
seems like a convincing argument that we don't have to support 16.3.
If Andrew is willing to update drongo, I'm content to leave it at
that.
It's done and running. Testing before I re-enabled the animal it shows
it was happy.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Andrew Dunstan <andrew@dunslane.net> writes:
It's done and running. Testing before I re-enabled the animal it shows
it was happy.
In the no-good-deed-goes-unpunished department ... drongo is now spewing
a boatload of these warnings:
C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.18362.0\\um\\winbase.h(9305): warning C5105: macro expansion producing 'defined' has undefined behavior
Looks like this comes out once per .c file -- probably it's
in an inclusion from <windows.h>. Dunno if there's anything
we can do but ignore it. I wonder though why we have not seen
this on other buildfarm animals.
regards, tom lane
On 2025-07-08 Tu 3:45 PM, Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
It's done and running. Testing before I re-enabled the animal it shows
it was happy.In the no-good-deed-goes-unpunished department ... drongo is now spewing
a boatload of these warnings:C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.18362.0\\um\\winbase.h(9305): warning C5105: macro expansion producing 'defined' has undefined behavior
Looks like this comes out once per .c file -- probably it's
in an inclusion from <windows.h>. Dunno if there's anything
we can do but ignore it. I wonder though why we have not seen
this on other buildfarm animals.
*sigh*
will investigate.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2025-07-08 Tu 4:10 PM, Andrew Dunstan wrote:
On 2025-07-08 Tu 3:45 PM, Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
It's done and running. Testing before I re-enabled the animal it shows
it was happy.In the no-good-deed-goes-unpunished department ... drongo is now spewing
a boatload of these warnings:C:\\Program Files (x86)\\Windows
Kits\\10\\include\\10.0.18362.0\\um\\winbase.h(9305): warning C5105:
macro expansion producing 'defined' has undefined behaviorLooks like this comes out once per .c file -- probably it's
in an inclusion from <windows.h>. Dunno if there's anything
we can do but ignore it. I wonder though why we have not seen
this on other buildfarm animals.*sigh*
will investigate.
No grand insights yet. I note that this is not occurring on the back
branches.
Here's the MS page describing the error:
https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/c5105?view=msvc-170
The relevant portion of the winbase.h file appears to be:
/*
To turn off/hide the contents of this file:
#define
MICROSOFT_WINDOWS_WINBASE_H_DEFINE_INTERLOCKED_CPLUSPLUS_OVERLOADS 0
*/
#if
!defined(MICROSOFT_WINDOWS_WINBASE_H_DEFINE_INTERLOCKED_CPLUSPLUS_OVERLOADS)
#define
MICROSOFT_WINDOWS_WINBASE_H_DEFINE_INTERLOCKED_CPLUSPLUS_OVERLOADS
(_WIN32_WINNT >= 0x0502 || !defined(_WINBASE_))
#endif
#if
MICROSOFT_WINDOWS_WINBASE_H_DEFINE_INTERLOCKED_CPLUSPLUS_OVERLOADS
/* { */
The last line is 9305.
I don't think we have any other VS 2019 machines in the buildfarm. I can
try installing VS 2022, which hamerkop seems to be running without
producing the error.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
