C11 / VS 2019 - Mailing list pgsql-hackers

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?