Subject: Enable -Wstrict-prototypes and -Wold-style-definition by default

From: Bertrand Drouvot <[email-masked]>
Date: Mon, 9 Mar 2026 16:39:07 +0000

Hi hackers,

PFA a patch to $SUBJECT. The idea is to avoid having to chase those warnings
manually like 11171fe1fc8, cdf4b9aff2, 0e72b9d440, 7069dbcc31, f1283ed6cc,
7b66e2c086, e95126cf04 and 9f7c527af3 have done.

The idea has been discussed in [1] and [2].

The patch is divided in 2 parts:

0001: Prevent -Wstrict-prototypes and -Wold-style-definition warnings

It fixes the remaining warnings that those new flags would generate.

0002: Enable -Wstrict-prototypes and -Wold-style-definition by default

Those are available in all gcc and clang versions that support C11 and as C11
is required as of f5e0186f865c, then we can add them without capability test.

The new flags are moved in configure.ac late enough to avoid any error (for
example, PGAC_PRINTF_ARCHETYPE which uses -Werror and would fail to detect
gnu_printf if -Wstrict-prototypes is active) leading to mingw_cross_warning CI
task failing.

Also, readline headers trigger a lot of warnings with -Wstrict-prototypes, so
we make use of the system_header pragma to hide the warnings (as discussed in
[3].

[1]: https://postgr.es/m/262909b8-3f4b-42ce-acd7-bdd4a6897990%40eisentraut.org
[2]: https://postgr.es/m/aTJ9T8HyJN3D024w%40ip-10-97-1-34.eu-west-3.compute.internal
[3]: https://postgr.es/m/1049756.1764861448%40sss.pgh.pa.us

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

---

From: Peter Eisentraut <[email-masked]>
Date: Wed, 18 Mar 2026 14:32:30 +0100

On 16.03.26 10:55, Peter Eisentraut wrote:
> On 09.03.26 17:39, Bertrand Drouvot wrote:
> I have committed this one.  I'll look at the rest next.

Also committed.

---

From: Nazir Bilal Yavuz <[email-masked]>
Date: Wed, 18 Mar 2026 18:50:20 +0300

Hi,

Thank you for working on this!

> > I have committed this one.  I'll look at the rest next.

I got this warning while running headerscheck after this commit:

~/Desktop/projects/postgres/src/interfaces/ecpg/ecpglib/ecpglib_extern.h:221:40:
warning: function declaration isn’t a prototype [-Wstrict-prototypes]
  221 | void            ecpg_init_sqlca(struct sqlca_t *sqlca)

Another topic is that, CI already catched this [1] (and other not
related things in cpluspluscheck). However, it seems that since we run
headerscheck and cpluspluscheck with the '-fmax-errors=10' option; CI
didn't fail. It would be good to remove '-fmax-errors=10', though.

[1] https://cirrus-ci.com/task/5166361724321792?logs=headers_headerscheck#L0

--
Regards,
Nazir Bilal Yavuz
Microsoft

---

From: Tom Lane <[email-masked]>
Date: Wed, 18 Mar 2026 13:03:03 -0400

>   221 | void            ecpg_init_sqlca(struct sqlca_t *sqlca)

Yeah, I see that too.  I believe the problem is that headerscheck
doesn't cause POSTGRES_ECPG_INTERNAL to become defined, so that
what the compiler is seeing is (from sqlca.h):

	#ifndef POSTGRES_ECPG_INTERNAL
	#define sqlca (*ECPGget_sqlca())
	#endif

and then

	void		ecpg_init_sqlca(struct sqlca_t *sqlca);

Kinda surprising that that's not a syntax error.  We could plausibly
fix this either by

(1) renaming ecpg_init_sqlca's parameter to something else;

(2) ensuring that POSTGRES_ECPG_INTERNAL is defined.  I'd be inclined
to make ecpglib_extern.h do that rather than expecting headerscheck
to know about it.

Neither of these options are beautiful, but perhaps #1 is slightly
less ugly.  Any preferences?

			regards, tom lane

---

From: Andres Freund <[email-masked]>
Date: Wed, 18 Mar 2026 13:26:26 -0400

Hi,

On 2026-03-18 13:03:03 -0400, Tom Lane wrote:
> Kinda surprising that that's not a syntax error.

Indeed.

I don't even really understand what that POSTGRES_ECPG_INTERNAL business is
about. Is that really just so we can use a local "sqlca" variable in some of
our own ecpglib code while code using ecpg can't do that?  Please tell me it
ain't so.

> We could plausibly fix this either by
> 

> less ugly.  Any preferences?

1) seems to be the preferrable approach. It's what code using ecpg already has
to do, right?

Greetings,

Andres Freund

---

From: Tom Lane <[email-masked]>
Date: Wed, 18 Mar 2026 13:33:46 -0400

> our own ecpglib code while code using ecpg can't do that?  Please tell me it

Looks like it's so --- AFAICS, POSTGRES_ECPG_INTERNAL isn't tested
anywhere except in this fragment in sqlca.h.

> 1) seems to be the preferrable approach. It's what code using ecpg already has

I think that from the point of view of ecpg client applications,
"sqlca" is supposed to be a library-defined global variable
(and this macro is about making it thread-local).
They'd not really have use for local variables named that.

			regards, tom lane

---

From: Bertrand Drouvot <[email-masked]>
Date: Wed, 18 Mar 2026 19:15:33 +0000

Hi,

> > I got this warning while running headerscheck after this commit:

Thanks for the report!

> 	void		ecpg_init_sqlca(struct sqlca_t *sqlca);

Oh right, confirmed with:

"
$ gcc -E -I src/interfaces/ecpg/include -I src/include -I src/interfaces/libpq \ 
    -include src/include/postgres_fe.h src/interfaces/ecpg/ecpglib/ecpglib_extern.h \
     | grep ECPGget_sqlca

$ struct sqlca_t *ECPGget_sqlca(void);
$ void ecpg_init_sqlca(struct sqlca_t *(*ECPGget_sqlca()));
"
> Kinda surprising that that's not a syntax error.

Yeah...

> less ugly.  Any preferences?

I'd vote for #1 too, done in the attached.

Regards,

---

From: Bertrand Drouvot <[email-masked]>
Date: Tue, 24 Mar 2026 07:16:47 +0000

Hi,

On Mon, Mar 23, 2026 at 04:13:20PM +0100, Peter Eisentraut wrote:
> On 18.03.26 14:32, Peter Eisentraut wrote:
> I have a couple of follow-up patches that I had developed while playing with
> this.

Thanks!

> There is a warning option for MSVC that appears to have a very similar
> effect to the ones we added here, so I propose we add that one as well.
> 
> Additionally, there is an option for MSVC to disable warnings in system
> headers, similar to the default behavior of GCC.  This would be required
> here because some system header files have non-strict prototypes.

Some comments:

0001:

+    '/external:anglebrackets',
+    '/external:W0',

The doc [1], states:

"
The /external compiler options are available starting in Visual Studio 2017 version 15.6.
In versions of Visual Studio before Visual Studio 2019 version 16.10, the /external
options require you also set the /experimental:external compiler option.
"

We currently require MSVC 2019, but what if one is using a version < 16.10?

0003:

"
This has been the default since gcc 4.0.  (Introduced in 3.3, so it
was only available but turned off for a relatively short time.)
"

It looks like it was default to on since its introduction in 909de5da19 ([2]),
means since 3.3. In 90689ae11db ([3]), added in 4.0, the documentation has been
updated to mention it (but I think that it was already on by default since
3.3).

0004:

--- a/meson.build
+++ b/meson.build
@@ -2199,6 +2199,7 @@ unroll_loops_cflags = cc.get_supported_arguments(['-funroll-loops'])
 
 common_warning_flags = [
   '-Wmissing-prototypes',
+  '-Wold-style-declaration',

Nit, what about adding it with (as the comment is also accurate for the new one)?

"
# These are C-only flags, supported in all C11-capable GCC/Clang versions.
cflags_warn += cc.get_supported_arguments(['-Wstrict-prototypes', '-Wold-style-definition'])
"

[1]: https://learn.microsoft.com/en-us/cpp/build/reference/external-external-headers-diagnostics?view=msvc-170
[2]: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=909de5da192
[3]: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=90689ae11db

Regards,

---

From: Bertrand Drouvot <[email-masked]>
Date: Wed, 25 Mar 2026 03:17:35 +0000

Hi,

On Tue, Mar 24, 2026 at 10:36:43PM +0100, Peter Eisentraut wrote:
> On 24.03.26 08:16, Bertrand Drouvot wrote:
> > 0001:
> > 
> Per discussion in [0] we effectively require 16.11, so I think this should
> be ok.

Agree, thanks for the link!

Regards,

---

From: Peter Eisentraut <[email-masked]>
Date: Fri, 27 Mar 2026 08:38:45 +0100

The first three patches have been committed.

> cflags_warn += cc.get_supported_arguments(['-Wstrict-prototypes', '-Wold-style-definition'])

Yeah, makes sense to collect the C-only flags together.  But now that 
I'm looking at this again, the comment "supported in all C11-capable 
GCC/Clang versions" is not relevant here, it was only relevant in 
configure.ac because there we don't actually test for these flags but 
require them without testing.  What do you think about the attached 
patch, which reorganizes this a bit more?
From ae3a34e762a7f8af22a0718f91d39200689c07e3 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <[email-masked]>
Date: Fri, 27 Mar 2026 08:34:37 +0100
Subject: [PATCH v3] Add warning option -Wold-style-declaration

This warning has been triggered a few times via the buildfarm (see
commits 8212625e53f, 2b7259f8557, afe86a9e73b), so we might as well
add it so that everyone sees it.

(This is completely separate from the recently added
-Wold-style-definition.)

Reviewed-by: Tom Lane <[email-masked]>
Reviewed-by: Bertrand Drouvot <[email-masked]>
Discussion: https://www.postgresql.org/message-id/flat/aa73q1aT0A3/vke/%40ip-10-97-1-34.eu-west-3.compute.internal
---
 configure    | 41 +++++++++++++++++++++++++++++++++++++++++
 configure.ac |  2 ++
 meson.build  | 14 +++++++++-----
 3 files changed, 52 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index 8e0e7483c1d..d058605c7ad 100755
--- a/configure
+++ b/configure
@@ -5526,6 +5526,47 @@ fi

+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether ${CC} supports -Wold-style-declaration, for CFLAGS" >&5
+$as_echo_n "checking whether ${CC} supports -Wold-style-declaration, for CFLAGS... " >&6; }
+if ${pgac_cv_prog_CC_cflags__Wold_style_declaration+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  pgac_save_CFLAGS=$CFLAGS
+pgac_save_CC=$CC
+CC=${CC}
+CFLAGS="${CFLAGS} -Wold-style-declaration"
+ac_save_c_werror_flag=$ac_c_werror_flag
+ac_c_werror_flag=yes
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+int
+main ()
+{
+
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+  pgac_cv_prog_CC_cflags__Wold_style_declaration=yes
+else
+  pgac_cv_prog_CC_cflags__Wold_style_declaration=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+ac_c_werror_flag=$ac_save_c_werror_flag
+CFLAGS="$pgac_save_CFLAGS"
+CC="$pgac_save_CC"
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv_prog_CC_cflags__Wold_style_declaration" >&5
+$as_echo "$pgac_cv_prog_CC_cflags__Wold_style_declaration" >&6; }
+if test x"$pgac_cv_prog_CC_cflags__Wold_style_declaration" = x"yes"; then
+  CFLAGS="${CFLAGS} -Wold-style-declaration"
+fi
+
+
+  # -Wold-style-declaration is not applicable for C++
+
   # To require fallthrough attribute annotations, use
   # -Wimplicit-fallthrough=5 with gcc and -Wimplicit-fallthrough with
   # clang.  The latter is also accepted on gcc but does not enforce
diff --git a/configure.ac b/configure.ac
index 2baac5e9da7..c27afee1822 100644
--- a/configure.ac
+++ b/configure.ac
@@ -555,6 +555,8 @@ if test "$GCC" = yes -a "$ICC" = no; then
   PGAC_PROG_CXX_CFLAGS_OPT([-Werror=unguarded-availability-new])
   PGAC_PROG_CC_CFLAGS_OPT([-Wmissing-format-attribute])
   PGAC_PROG_CXX_CFLAGS_OPT([-Wmissing-format-attribute])
+  PGAC_PROG_CC_CFLAGS_OPT([-Wold-style-declaration])
+  # -Wold-style-declaration is not applicable for C++
 
   # To require fallthrough attribute annotations, use
   # -Wimplicit-fallthrough=5 with gcc and -Wimplicit-fallthrough with
diff --git a/meson.build b/meson.build
index ea31cbce9c0..0ee772cd475 100644
--- a/meson.build
+++ b/meson.build
@@ -2198,7 +2198,6 @@ vectorize_cflags = cc.get_supported_arguments(['-ftree-vectorize'])
 unroll_loops_cflags = cc.get_supported_arguments(['-funroll-loops'])
 
 common_warning_flags = [
-  '-Wmissing-prototypes',
   '-Wpointer-arith',
   # Really don't want VLAs to be used in our dialect of C
   '-Werror=vla',
@@ -2211,7 +2210,15 @@ common_warning_flags = [
   '-Wformat-security',
 ]
 
-cflags_warn += cc.get_supported_arguments(common_warning_flags)
+# C-only warnings
+c_warning_flags = [
+  '-Wmissing-prototypes',
+  '-Wold-style-declaration',
+  '-Wold-style-definition',
+  '-Wstrict-prototypes',
+]
+
+cflags_warn += cc.get_supported_arguments(common_warning_flags, c_warning_flags)
 if have_cxx
   cxxflags_warn += cxx.get_supported_arguments(common_warning_flags)
 endif
@@ -2252,9 +2259,6 @@ if cc.has_argument('-Wmissing-variable-declarations')
   cflags_no_missing_var_decls += '-Wno-missing-variable-declarations'
 endif
 
-# These are C-only flags, supported in all C11-capable GCC/Clang versions.
-cflags_warn += cc.get_supported_arguments(['-Wstrict-prototypes', '-Wold-style-definition'])
-
 # The following tests want to suppress various unhelpful warnings by adding
 # -Wno-foo switches.  But gcc won't complain about unrecognized -Wno-foo
 # switches, so we have to test for the positive form and if that works,
-- 
2.53.0

---

From: Bertrand Drouvot <[email-masked]>
Date: Fri, 27 Mar 2026 10:07:40 +0000

Hi,

On Fri, Mar 27, 2026 at 08:38:45AM +0100, Peter Eisentraut wrote:
> Yeah, makes sense to collect the C-only flags together.  But now that I'm
> looking at this again, the comment "supported in all C11-capable GCC/Clang
> versions" is not relevant here, it was only relevant in configure.ac because
> there we don't actually test for these flags but require them without
> testing. 

Right, it was a bit misleading.

> What do you think about the attached patch, which reorganizes this
> a bit more?

+# C-only warnings
+c_warning_flags = [

That looks ok but I wonder if we should also add '-Werror=vla' to it (
and remove it from common_warning_flags) to be in sync with what configure.ac
is doing:

"
  PGAC_PROG_CC_CFLAGS_OPT([-Werror=vla])
  # -Wvla is not applicable for C++
"

Regards,

---

From: Peter Eisentraut <[email-masked]>
Date: Fri, 27 Mar 2026 13:15:29 +0100

>    # -Wvla is not applicable for C++

Hmm.  This comment is not actually fully correct.  With g++, you can 
write a VLA and it will work, and also -Wvla will warn about it.  So we 
should actually add that option to C++ as well.  (It is true that VLAs 
are not in standard C++, and g++ with -pedantic will also warn about it.)

---

From: Bertrand Drouvot <[email-masked]>
Date: Fri, 27 Mar 2026 13:23:14 +0000

Hi,

On Fri, Mar 27, 2026 at 01:15:29PM +0100, Peter Eisentraut wrote:
> Hmm.  This comment is not actually fully correct.  With g++, you can write a
> VLA and it will work, and also -Wvla will warn about it.  So we should
> actually add that option to C++ as well.  (It is true that VLAs are not in
> standard C++, and g++ with -pedantic will also warn about it.)

Oh right, just did a few tests and agree with your comment above. I agree that
it should also be added for C++ in autoconf then.

What about the attached?

That said, your patch LGTM given that the VLA remark was not appropriate.

Regards,

---

From: Peter Eisentraut <[email-masked]>
Date: Mon, 30 Mar 2026 23:50:24 +0200

> That said, your patch LGTM given that the VLA remark was not appropriate.

Ok, both committed.

---

From: Tom Lane <[email-masked]>
Date: Mon, 06 Apr 2026 17:19:51 -0400

> The first three patches have been committed.

b4a132022 has had some not-so-desirable effects in the buildfarm:
drongo and hoatzin are each spewing a couple dozen repetitive
warnings about every bison-generated header file, eg

src/backend/bootstrap/bootparse.h(111): warning C4255: 'boot_yyparse': no function prototype given: converting '()' to '(void)'

Both of those machines are using bison 2.7, which is pretty old
and evidently isn't careful about generating complete prototypes.

I'm not sure if there's anything to be done about this, except
perhaps nag the animals' owners to find a newer bison somewhere.
We could revert b4a132022, but then we might miss valid warnings
about such issues in Windows-only code.

			regards, tom lane

---

From: Peter Eisentraut <[email-masked]>
Date: Wed, 8 Apr 2026 14:51:05 +0200

> about such issues in Windows-only code.

Let's try the nagging route.

I found it especially curious that hoatzin is a relatively new member, 
so why is it running this ancient Bison version?  Looking at the 
Chocolatey packages:

https://community.chocolatey.org/packages?q=bison

it appears that

     choco install winflexbison

gives you the old version, and you need

     choco install winflexbison3

to get a newer version.  So it seems easy to fall into that "trap" if 
you don't pay attention.

So perhaps these buildfarm members could update their Bison version 
sometime.

I found one mention of this command in our wiki 
(https://wiki.postgresql.org/wiki/Meson#Windows), which I updated.  If 
we find any other documents or guides with these commands, we should try 
to get them updated, too.

---

From: Andrew Dunstan <[email-masked]>
Date: Wed, 8 Apr 2026 11:14:35 -0400

On 2026-04-08 We 8:51 AM, Peter Eisentraut wrote:
>> src/backend/bootstrap/bootparse.h(111): warning C4255: 
>> 'boot_yyparse': no function prototype given: converting '()' to '(void)'
>>
> we find any other documents or guides with these commands, we should 
> try to get them updated, too.

drongo is updated

cheers

andrew

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