Обсуждение: 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].)

[0]: 
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])
- anonymous unions, mostly aesthetic
- generic selection, for some more type safety in certain cases
- threads library (needs separate consideration, see [2])
- atomic types, to maybe simplify some of our atomics support

[1]: 
https://www.postgresql.org/message-id/f36c0a45-98cd-40b2-a7cc-f2bf02b12890@eisentraut.org
[2]: 
https://www.postgresql.org/message-id/flat/CA%2BhUKGLtmexrpMtxBRLCVePqV_dtWG-ZsEbyPrYc%2BNBB2TkNsw%40mail.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 C11
> 
> Thoughts?

+1

-- 
nathan

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 C11
>>>
>>> Thoughts?
>>
>> +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:


https://www.postgresql.org/message-id/flat/CA%2BhUKG%2Bw-2RyyYUte_mSAunoRE00bQUCG44%3DFiOuyMaN-6uoOw%40mail.gmail.com#60354fbd9784c58d3eeaf9a4193a7414

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.

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], 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 0xC0000409
> 
> While there are 19 new commits in the first run that shows this
> failure [1], 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.

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 0xC0000409
> >
> > While there are 19 new commits in the first run that shows this
> > failure [1], 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.
>
> 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].

[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

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] seems to indicate you might need at least 16.5 for this.

Also, there is the support timeline [1] 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

[1]: 
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 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.

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

Andrew Dunstan <andrew@dunslane.net> writes:
> On 2025-07-08 Tu 4:10 PM, Andrew Dunstan wrote:
>> On 2025-07-08 Tu 3:45 PM, Tom Lane wrote:
>>> 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

> The relevant portion of the winbase.h file appears to be:

>     #define
>     MICROSOFT_WINDOWS_WINBASE_H_DEFINE_INTERLOCKED_CPLUSPLUS_OVERLOADS
>     (_WIN32_WINNT >= 0x0502 || !defined(_WINBASE_))

Hmm ... I don't pretend to be enough of a C language lawyer to know
whether this should have undefined behavior per spec, but it surely
does meet the conditions stated in the warning message.

I wonder if we should do what it says here:

>     /*
>     To turn off/hide the contents of this file:
>       #define
>     MICROSOFT_WINDOWS_WINBASE_H_DEFINE_INTERLOCKED_CPLUSPLUS_OVERLOADS 0
>     */

> 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.

That would amount to desupporting VS 2019, which I'm not sure we want
to do yet.  I don't have a huge problem with ignoring this warning.

            regards, tom lane

Hi,

On 2025-07-09 16:10:25 -0400, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> >     /*
> >     To turn off/hide the contents of this file:
> >       #define
> >     MICROSOFT_WINDOWS_WINBASE_H_DEFINE_INTERLOCKED_CPLUSPLUS_OVERLOADS 0
> >     */
> 
> > 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.
> 
> That would amount to desupporting VS 2019, which I'm not sure we want
> to do yet.  I don't have a huge problem with ignoring this warning.

FWIW, my understanding is that headers like winbase.h aren't part of the
compiler but part of the "SDK". And there are SDKs targetting different OS
versions, and different versions can be installed for the same or different
compiler versions.  So it's quite possible that this is a question of the
target SDK version, rather than the OS version.

hamerkop:
C:\\Program Files (x86)\\Windows Kits\\10\\\\include\\10.0.22621.0\\\\um\\windows.h

drongo:
C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.18362.0\\um\\windows.h


And with that trail, I found
  https://developer.microsoft.com/en-us/windows/downloads/windows-SDK/

which says, about Windows 10 SDK, Version 2104:

    SDK headers have been updated to address errors when compiling using the
    standard-conformant C preprocessor in the MSVC compiler cl.exe
    (/Zc:preprocessor, introduced in VS 2019 v16.6).

Which seems likely to describe precisely what we're seeing?

Greetings,

Andres Freund

PS: Wonder if we should make the SDK version visible in meson setup...

Hi,

On 2025-07-09 16:10:25 -0400, Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

    /*    To turn off/hide the contents of this file:      #define    MICROSOFT_WINDOWS_WINBASE_H_DEFINE_INTERLOCKED_CPLUSPLUS_OVERLOADS 0    */

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.

That would amount to desupporting VS 2019, which I'm not sure we want
to do yet.  I don't have a huge problem with ignoring this warning.

FWIW, my understanding is that headers like winbase.h aren't part of the
compiler but part of the "SDK". And there are SDKs targetting different OS
versions, and different versions can be installed for the same or different
compiler versions.  So it's quite possible that this is a question of the
target SDK version, rather than the OS version.

hamerkop:
C:\\Program Files (x86)\\Windows Kits\\10\\\\include\\10.0.22621.0\\\\um\\windows.h

drongo:
C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.18362.0\\um\\windows.h


And with that trail, I found  https://developer.microsoft.com/en-us/windows/downloads/windows-SDK/

which says, about Windows 10 SDK, Version 2104:
    SDK headers have been updated to address errors when compiling using the    standard-conformant C preprocessor in the MSVC compiler cl.exe    (/Zc:preprocessor, introduced in VS 2019 v16.6).

Which seems likely to describe precisely what we're seeing?

Yeah, installing the latest SDK seems to have done the trick.

PS: Wonder if we should make the SDK version visible in meson setup...

Maybe.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Ok, now that we have seemingly stabilized the VS 2019 upgrade, here is 
the next patch set to actually raise the compiler requirement to C11.

Viewed from very far away, this just adjusts the existing places that 
say C99 and replaces them with a C11 analogue.

The details are a bit of a longer story.

configure.ac previously used AC_PROG_CC_C99 to activate C99.  But there 
is no AC_PROG_CC_C11 in Autoconf 2.69, because it's too old.  Also, 
post-2.69, the AC_PROG_CC_Cnn macros were deprecated and AC_PROG_CC 
activates the last supported C mode.

So, at this point, we could "just" update the Autoconf version requirement.

But somehow I don't feel like doing that, as it's just another 
non-trivial project to negotiate.  Instead, I just hand-coded some test 
for C11 using some inspiration from later Autoconf versions.  But 
instead of writing an elaborate test program that exercises many 
different features, I kept it simple and just check __STDC_VERSION__, 
which should be good enough in practice.

(If someone later wanted to update the Autoconf version, they could just 
delete that code again.)

In meson.build, there is an existing hand-coded C99 test that I update 
to C11, but again just checking for __STDC_VERSION__.

I also moved the test a bit earlier in meson.build, as a separate patch, 
because between the place where the compiler is first set up and the 
place where we detected the C99 options, if any, there were already some 
tests run that use the compiler.  I don't think this was a big problem 
in practice, but it seems a bit incorrect, so it makes sense to correct it.

Note, we don't use the "official" way to set the C standard in Meson 
using the c_std project option, because that is IMO impossible to use 
correctly (see <https://github.com/mesonbuild/meson/issues/14717>). 
(Well, that is my reason now.  I don't know what the reason was 
previously.)  The disadvantage is that meson will complain like

meson.build:3013: WARNING: Consider using the built-in option for 
language standard version instead of using "/std:c11".

But you will get warnings from meson with MSVC anyway, so, uh, another 
one will not make a significant difference.  (Also, this issue exists 
with the existing C99 detection code as well, except that in practice 
you don't need an option, so the warning does not appear.)

Note that gcc and clang switched to C11 by default a long time ago 
(gcc-5 and clang-3.6), so for most users all these tests won't need to 
do anything.  If you want to test it, you could simulate an older 
default like

./configure CC='gcc -std=c99'

and then the test should decide that it needs to add another option to 
override the C mode.

On Fri, 18 Jul 2025 at 23:12, Peter Eisentraut <peter@eisentraut.org> wrote:
> Note that gcc and clang switched to C11 by default a long time ago
> (gcc-5 and clang-3.6), so for most users all these tests won't need to
> do anything.  If you want to test it, you could simulate an older
> default like
>
> ./configure CC='gcc -std=c99'
>
> and then the test should decide that it needs to add another option to
> override the C mode.

This isn't quite my area of expertise, but I've been reviewing the
patch and testing. I don't see any issues with VS2022.

On Linux, doing a bit more testing using meson and clang, I tried with
CC=clang CFLAGS=-std=c99 . I get:

Checking if "C11" compiles: NO
Checking if "C11 with -std=gnu11" compiles: YES

But later:

FAILED: src/backend/parser/parser.a.p/meson-generated_.._gram.c.o
clang -Isrc/backend/parser/parser.a.p -Isrc/backend/parser
-I../src/backend/parser -Isrc/include -I../src/include
-I/usr/include/libxml2 -fdiagnostics-color=always
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O2 -g -std=gnu11
-fno-strict-aliasing -fwrapv -fexcess-precision=standard -D_GNU_SOURCE
-Wmissing-prototypes -Wpointer-arith -Werror=vla
-Werror=unguarded-availability-new -Wendif-labels
-Wmissing-format-attribute -Wcast-function-type -Wformat-security
-Wdeclaration-after-statement -Wmissing-variable-declarations
-Wno-unused-command-line-argument -Wno-compound-token-split-by-macro
-Wno-format-truncation -Wno-cast-function-type-strict -std=c99 -fPIC
-pthread -DBUILDING_DLL -MD -MQ
src/backend/parser/parser.a.p/meson-generated_.._gram.c.o -MF
src/backend/parser/parser.a.p/meson-generated_.._gram.c.o.d -o
src/backend/parser/parser.a.p/meson-generated_.._gram.c.o -c
src/backend/parser/gram.c
../src/backend/parser/gram.y:19362:12: error: call to undeclared
function 'typeof'; ISO C99 and later do not support implicit function
declarations [-Wimplicit-function-declaration]
 19362 |                 result = copyObject(p->argType);

It's not quite clear to me why the C11 test passes but then the build
fails. I assumed the mixed -std=gnu11 then -std=c99 are passed in the
test as well. I don't know how to check.

Strangely, if I swap the order of the c11_test_args so the test tries
and uses -std=c11 first, it works ok.

@@ -558,7 +558,7 @@ if not cc.compiles(c11_test, name: 'C11')
   if cc.get_id() == 'msvc'
     c11_test_args = ['/std:c11']
   else
-    c11_test_args = ['-std=gnu11', '-std=c11']
+    c11_test_args = ['-std=c11', '-std=gnu11']
   endif

Perhaps this isn't an issue. I just did this to try to test what would
happen in a compiler that defaulted to c99. I'm unsure how clang
processes conflicting compiler flags.

David

David Rowley <dgrowleyml@gmail.com> writes:
> On Fri, 18 Jul 2025 at 23:12, Peter Eisentraut <peter@eisentraut.org> wrote:
>> Note that gcc and clang switched to C11 by default a long time ago
>> (gcc-5 and clang-3.6), so for most users all these tests won't need to
>> do anything.  If you want to test it, you could simulate an older
>> default like
>> ./configure CC='gcc -std=c99'

> On Linux, doing a bit more testing using meson and clang, I tried with
> CC=clang CFLAGS=-std=c99 . I get:

Note that that's not what Peter suggested.  That leads to

> FAILED: src/backend/parser/parser.a.p/meson-generated_.._gram.c.o
> clang -Isrc/backend/parser/parser.a.p -Isrc/backend/parser
> -I../src/backend/parser -Isrc/include -I../src/include
> -I/usr/include/libxml2 -fdiagnostics-color=always
> -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O2 -g -std=gnu11
                                                    ^^^^^^^^^^
> -fno-strict-aliasing -fwrapv -fexcess-precision=standard -D_GNU_SOURCE
> -Wmissing-prototypes -Wpointer-arith -Werror=vla
> -Werror=unguarded-availability-new -Wendif-labels
> -Wmissing-format-attribute -Wcast-function-type -Wformat-security
> -Wdeclaration-after-statement -Wmissing-variable-declarations
> -Wno-unused-command-line-argument -Wno-compound-token-split-by-macro
> -Wno-format-truncation -Wno-cast-function-type-strict -std=c99 -fPIC
                                                        ^^^^^^^^
> -pthread -DBUILDING_DLL -MD -MQ
> src/backend/parser/parser.a.p/meson-generated_.._gram.c.o -MF
> src/backend/parser/parser.a.p/meson-generated_.._gram.c.o.d -o
> src/backend/parser/parser.a.p/meson-generated_.._gram.c.o -c
> src/backend/parser/gram.c

Apparently we are not being too consistent about the order of
user-specified CFLAGS versus ones added by configuration?
The configuration test must have put the user CFLAGS first.

> Strangely, if I swap the order of the c11_test_args so the test tries
> and uses -std=c11 first, it works ok.

That is indeed weird.

            regards, tom lane

On Wed, 30 Jul 2025 at 00:57, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> David Rowley <dgrowleyml@gmail.com> writes:
> > On Fri, 18 Jul 2025 at 23:12, Peter Eisentraut <peter@eisentraut.org> wrote:
> >> Note that gcc and clang switched to C11 by default a long time ago
> >> (gcc-5 and clang-3.6), so for most users all these tests won't need to
> >> do anything.  If you want to test it, you could simulate an older
> >> default like
> >> ./configure CC='gcc -std=c99'
>
> > On Linux, doing a bit more testing using meson and clang, I tried with
> > CC=clang CFLAGS=-std=c99 . I get:
>
> Note that that's not what Peter suggested.  That leads to

OK, thanks. There are no issues when I use CC="clang -std=c99" meson setup ...

David

On 29.07.25 11:46, David Rowley wrote:
> ../src/backend/parser/gram.y:19362:12: error: call to undeclared
> function 'typeof'; ISO C99 and later do not support implicit function
> declarations [-Wimplicit-function-declaration]
>   19362 |                 result = copyObject(p->argType);
> 
> It's not quite clear to me why the C11 test passes but then the build
> fails. I assumed the mixed -std=gnu11 then -std=c99 are passed in the
> test as well. I don't know how to check.

The equivalent of config.log is in build/meson-logs/meson-log.txt.

> Strangely, if I swap the order of the c11_test_args so the test tries
> and uses -std=c11 first, it works ok.
> 
> @@ -558,7 +558,7 @@ if not cc.compiles(c11_test, name: 'C11')
>     if cc.get_id() == 'msvc'
>       c11_test_args = ['/std:c11']
>     else
> -    c11_test_args = ['-std=gnu11', '-std=c11']
> +    c11_test_args = ['-std=c11', '-std=gnu11']
>     endif

The situation is that with my original code, the C11 test picks the 
option -std=gnu11, and the typeof() test is then run with

cc ... -std=c99 ... -std=gnu11

which makes the test for typeof() pass (last option wins), but the 
actual build is run with

cc ... -std=gnu11 ... -std=c99

which disables the availability of typeof(), but pg_config.h says it's 
available, so the compilation fails.

If you flip the order of the arguments to be tested, then the C11 test 
picks -std=c11, and the typeof() test runs with

cc ... -std=c99 ... -std=c11

which will fail to detect typeof() (since it's neither in strict C99 nor 
in strict C11), and then later the actual compilation won't see typeof() 
at all.

Ideally, the tests should be run with the arguments in the same order as 
the actual compilation, but I don't think meson is equipped to support 
that.  I've been digging around the code and the documentation and don't 
find any mention about the *order* of the arguments supplied by various 
means like global, project, per-target, tests, environment, etc.  So I 
don't think there is any hope right now to sanely support "competing" 
arguments supplied from different sources.

(One might have valid concerns about -I and -L options, but that's a 
different potential topic.)

But since this is not how the patch was supposed to be used anyway, this 
shouldn't be a problem in practice.  It's not a new problem anyway.

FWIW, if you do this with autoconf, you get an early failure:

./configure CFLAGS='-std=c90'
...
checking for gcc option to accept ISO C89... none needed
checking for gcc option to accept ISO C99... unsupported
configure: error: C compiler "gcc" does not support C99

So putting "-std=" options into CFLAGS was never working.

Peter Eisentraut <peter@eisentraut.org> writes:
> Ideally, the tests should be run with the arguments in the same order as 
> the actual compilation, but I don't think meson is equipped to support 
> that.

Egad.  We are putting our faith in a build system that can't get
that right?  Order of switches is frequently critical.

            regards, tom lane

Hi,

On 2025-07-18 14:12:34 +0300, Peter Eisentraut wrote:
> I also moved the test a bit earlier in meson.build, as a separate patch,
> because between the place where the compiler is first set up and the place
> where we detected the C99 options, if any, there were already some tests run
> that use the compiler.  I don't think this was a big problem in practice,
> but it seems a bit incorrect, so it makes sense to correct it.

I distinctly dislike this. You mashed a compiler test in the middle of
something else, without updating any comments. We now do one compiler test
earlier, then dependency tests, and then other compiler tests.  Doing anything
the order we do it in autoconf is an anti-argument, because the ordering we
use in autoconf is completely unintelligible.

Greetings,

Andres Freund

On 18.08.25 15:27, Andres Freund wrote:
> On 2025-07-18 14:12:34 +0300, Peter Eisentraut wrote:
>> I also moved the test a bit earlier in meson.build, as a separate patch,
>> because between the place where the compiler is first set up and the place
>> where we detected the C99 options, if any, there were already some tests run
>> that use the compiler.  I don't think this was a big problem in practice,
>> but it seems a bit incorrect, so it makes sense to correct it.
> 
> I distinctly dislike this. You mashed a compiler test in the middle of
> something else, without updating any comments. We now do one compiler test
> earlier, then dependency tests, and then other compiler tests.

I think these are different things.  The C99 test is something that 
potentially adds a compiler flag and changes the mode of the compiler. 
So we need to do this first before we test anything else with the compiler.

The other compiler tests are just checking what the compiler is doing 
and record the result.  This does not affect subsequent tests.  Ok, 
there are some tests for warning flags and some -f options, but there 
are also arguments to be made that these should be set before checking 
external library headers for example.

So calling all of these compiler tests doesn't capture the necessary 
distinction.  I would think of these maybe as compiler flag tests versus 
compiler characteristics tests.

> Doing anything
> the order we do it in autoconf is an anti-argument, because the ordering we
> use in autoconf is completely unintelligible.

The point is that autoconf does the C-standard determination first, 
before doing anything else with the compiler.  That is clearly the 
correct thing to do.

Btw., the ordering is documented at the top of configure.ac, but it has 
surely degraded over time.

On 30.07.25 00:11, David Rowley wrote:
> On Wed, 30 Jul 2025 at 00:57, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> David Rowley <dgrowleyml@gmail.com> writes:
>>> On Fri, 18 Jul 2025 at 23:12, Peter Eisentraut <peter@eisentraut.org> wrote:
>>>> Note that gcc and clang switched to C11 by default a long time ago
>>>> (gcc-5 and clang-3.6), so for most users all these tests won't need to
>>>> do anything.  If you want to test it, you could simulate an older
>>>> default like
>>>> ./configure CC='gcc -std=c99'
>>
>>> On Linux, doing a bit more testing using meson and clang, I tried with
>>> CC=clang CFLAGS=-std=c99 . I get:
>>
>> Note that that's not what Peter suggested.  That leads to
> 
> OK, thanks. There are no issues when I use CC="clang -std=c99" meson setup ...

This has been committed.  C11 is the default mode now.

David: You could rebase your other patch (about emulating 
__builtin_constant_p) now.

Tom: You ought to update the configuration on the buildfarm members 
longfin and sifaka from

'CC' => 'ccache clang -std=gnu99',

to

'CC' => 'ccache clang -std=gnu11',

for the master branch.

Peter Eisentraut <peter@eisentraut.org> writes:
> Tom: You ought to update the configuration on the buildfarm members 
> longfin and sifaka from
> 'CC' => 'ccache clang -std=gnu99',
> to
> 'CC' => 'ccache clang -std=gnu11',
> for the master branch.

Roger, will do.

            regards, tom lane