public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v1 2/2] Enable -Wstrict-prototypes and -Wold-style-definition by default
18+ messages / 6 participants
[nested] [flat]
* [PATCH v1 2/2] Enable -Wstrict-prototypes and -Wold-style-definition by default
@ 2026-03-09 09:31 Bertrand Drouvot <[email protected]>
0 siblings, 0 replies; 18+ messages in thread
From: Bertrand Drouvot @ 2026-03-09 09:31 UTC (permalink / raw)
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.
Having them enabled by default avoid having to chase these manually like
11171fe1fc8, cdf4b9aff2, 0e72b9d440, 7069dbcc31, f1283ed6cc, 7b66e2c086,
e95126cf04 and 9f7c527af3 have done.
Also, readline headers trigger a lot of warnings with -Wstrict-prototypes, so
we make use of the system_header pragma to hide the warnings.
Author: Bertrand Drouvot <[email protected]>
Discussion: https://postgr.es/m/13d51b20-a69c-4ac1-8546-ec4fc278064f%40eisentraut.org
Discussion: https://postgr.es/m/aTFctZwWSpl2/LG5%40ip-10-97-1-34.eu-west-3.compute.internal
---
configure | 8 ++++++++
configure.ac | 8 ++++++++
meson.build | 2 ++
src/bin/psql/input.h | 9 +++++++++
4 files changed, 27 insertions(+)
24.8% src/bin/psql/
diff --git a/configure b/configure
index 42621ecd051..dda8217e808 100755
--- a/configure
+++ b/configure
@@ -16905,6 +16905,14 @@ rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
fi
+# These flags are supported in all C11-capable GCC/Clang versions,
+# so no capability test is needed. Added here to avoid affecting configure probes,
+# particularly PGAC_PRINTF_ARCHETYPE which uses -Werror and would fail to detect
+# gnu_printf if -Wstrict-prototypes is active.
+if test "$GCC" = yes -a "$ICC" = no; then
+ CFLAGS="$CFLAGS -Wstrict-prototypes -Wold-style-definition"
+fi
+
# --------------------
# Run tests below here
# --------------------
diff --git a/configure.ac b/configure.ac
index 61ec895d23c..98d0698e4c8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2032,6 +2032,14 @@ related to locating shared libraries. Check the file 'config.log'
for the exact reason.]])],
[AC_MSG_RESULT([cross-compiling])])
+# These flags are supported in all C11-capable GCC/Clang versions,
+# so no capability test is needed. Added here to avoid affecting configure probes,
+# particularly PGAC_PRINTF_ARCHETYPE which uses -Werror and would fail to detect
+# gnu_printf if -Wstrict-prototypes is active.
+if test "$GCC" = yes -a "$ICC" = no; then
+ CFLAGS="$CFLAGS -Wstrict-prototypes -Wold-style-definition"
+fi
+
# --------------------
# Run tests below here
# --------------------
diff --git a/meson.build b/meson.build
index 2df54409ca6..db3a3327cb5 100644
--- a/meson.build
+++ b/meson.build
@@ -2242,6 +2242,8 @@ 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
diff --git a/src/bin/psql/input.h b/src/bin/psql/input.h
index 09961c84101..2a47166347e 100644
--- a/src/bin/psql/input.h
+++ b/src/bin/psql/input.h
@@ -17,6 +17,15 @@
#ifdef HAVE_LIBREADLINE
#define USE_READLINE 1
+/*
+ * Readline headers trigger a lot of warnings with our preferred compiler flags
+ * (at least -Wstrict-prototypes is known to be problematic). The system_header
+ * pragma hides warnings from within the rest of this file, if supported.
+ */
+#ifdef HAVE_PRAGMA_GCC_SYSTEM_HEADER
+#pragma GCC system_header
+#endif
+
#if defined(HAVE_READLINE_READLINE_H)
#include <readline/readline.h>
#if defined(HAVE_READLINE_HISTORY_H)
--
2.34.1
--xofE7MYp3i9PRJLn--
^ permalink raw reply [nested|flat] 18+ messages in thread
* Enable -Wstrict-prototypes and -Wold-style-definition by default
@ 2026-03-09 16:39 Bertrand Drouvot <[email protected]>
2026-03-18 13:32 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 18+ messages in thread
From: Bertrand Drouvot @ 2026-03-09 16:39 UTC (permalink / raw)
To: [email protected]; +Cc: Peter Eisentraut <[email protected]>
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
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Enable -Wstrict-prototypes and -Wold-style-definition by default
2026-03-09 16:39 Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
@ 2026-03-18 13:32 ` Peter Eisentraut <[email protected]>
2026-03-18 15:50 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Nazir Bilal Yavuz <[email protected]>
2026-03-24 07:16 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
0 siblings, 2 replies; 18+ messages in thread
From: Peter Eisentraut @ 2026-03-18 13:32 UTC (permalink / raw)
To: Bertrand Drouvot <[email protected]>; [email protected]
On 16.03.26 10:55, Peter Eisentraut wrote:
> On 09.03.26 17:39, Bertrand Drouvot wrote:
>> 0001: Prevent -Wstrict-prototypes and -Wold-style-definition warnings
>>
>> It fixes the remaining warnings that those new flags would generate.
>
> I have committed this one. I'll look at the rest next.
Also committed.
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Enable -Wstrict-prototypes and -Wold-style-definition by default
2026-03-09 16:39 Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-18 13:32 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
@ 2026-03-18 15:50 ` Nazir Bilal Yavuz <[email protected]>
2026-03-18 17:03 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Tom Lane <[email protected]>
1 sibling, 1 reply; 18+ messages in thread
From: Nazir Bilal Yavuz @ 2026-03-18 15:50 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Bertrand Drouvot <[email protected]>; [email protected]
Hi,
Thank you for working on this!
On Wed, 18 Mar 2026 at 16:32, Peter Eisentraut <[email protected]> wrote:
>
> On 16.03.26 10:55, Peter Eisentraut wrote:
> > On 09.03.26 17:39, Bertrand Drouvot wrote:
> >> 0001: Prevent -Wstrict-prototypes and -Wold-style-definition warnings
> >>
> >> It fixes the remaining warnings that those new flags would generate.
> >
> > I have committed this one. I'll look at the rest next.
>
> Also committed.
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
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Enable -Wstrict-prototypes and -Wold-style-definition by default
2026-03-09 16:39 Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-18 13:32 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
2026-03-18 15:50 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Nazir Bilal Yavuz <[email protected]>
@ 2026-03-18 17:03 ` Tom Lane <[email protected]>
2026-03-18 17:26 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Andres Freund <[email protected]>
2026-03-18 19:15 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
0 siblings, 2 replies; 18+ messages in thread
From: Tom Lane @ 2026-03-18 17:03 UTC (permalink / raw)
To: Nazir Bilal Yavuz <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Bertrand Drouvot <[email protected]>; [email protected]
Nazir Bilal Yavuz <[email protected]> writes:
> 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)
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
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Enable -Wstrict-prototypes and -Wold-style-definition by default
2026-03-09 16:39 Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-18 13:32 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
2026-03-18 15:50 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Nazir Bilal Yavuz <[email protected]>
2026-03-18 17:03 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Tom Lane <[email protected]>
@ 2026-03-18 17:26 ` Andres Freund <[email protected]>
2026-03-18 17:33 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Tom Lane <[email protected]>
1 sibling, 1 reply; 18+ messages in thread
From: Andres Freund @ 2026-03-18 17:26 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Nazir Bilal Yavuz <[email protected]>; Peter Eisentraut <[email protected]>; Bertrand Drouvot <[email protected]>; [email protected]
Hi,
On 2026-03-18 13:03:03 -0400, Tom Lane wrote:
> Nazir Bilal Yavuz <[email protected]> writes:
> > 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)
>
> 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.
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
>
> (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?
1) seems to be the preferrable approach. It's what code using ecpg already has
to do, right?
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Enable -Wstrict-prototypes and -Wold-style-definition by default
2026-03-09 16:39 Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-18 13:32 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
2026-03-18 15:50 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Nazir Bilal Yavuz <[email protected]>
2026-03-18 17:03 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Tom Lane <[email protected]>
2026-03-18 17:26 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Andres Freund <[email protected]>
@ 2026-03-18 17:33 ` Tom Lane <[email protected]>
0 siblings, 0 replies; 18+ messages in thread
From: Tom Lane @ 2026-03-18 17:33 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Nazir Bilal Yavuz <[email protected]>; Peter Eisentraut <[email protected]>; Bertrand Drouvot <[email protected]>; [email protected]
Andres Freund <[email protected]> writes:
> On 2026-03-18 13:03:03 -0400, Tom Lane wrote:
>> 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
> 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.
Looks like it's so --- AFAICS, POSTGRES_ECPG_INTERNAL isn't tested
anywhere except in this fragment in sqlca.h.
>> 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?
> 1) seems to be the preferrable approach. It's what code using ecpg already has
> to do, right?
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
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Enable -Wstrict-prototypes and -Wold-style-definition by default
2026-03-09 16:39 Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-18 13:32 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
2026-03-18 15:50 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Nazir Bilal Yavuz <[email protected]>
2026-03-18 17:03 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Tom Lane <[email protected]>
@ 2026-03-18 19:15 ` Bertrand Drouvot <[email protected]>
1 sibling, 0 replies; 18+ messages in thread
From: Bertrand Drouvot @ 2026-03-18 19:15 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Nazir Bilal Yavuz <[email protected]>; Peter Eisentraut <[email protected]>; [email protected]
Hi,
On Wed, Mar 18, 2026 at 01:03:03PM -0400, Tom Lane wrote:
> Nazir Bilal Yavuz <[email protected]> writes:
> > I got this warning while running headerscheck after this commit:
Thanks for the report!
> > ~/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)
>
> 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);
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...
> 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?
I'd vote for #1 too, done in the attached.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Enable -Wstrict-prototypes and -Wold-style-definition by default
2026-03-09 16:39 Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-18 13:32 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
@ 2026-03-24 07:16 ` Bertrand Drouvot <[email protected]>
2026-03-25 03:17 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-27 07:38 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
1 sibling, 2 replies; 18+ messages in thread
From: Bertrand Drouvot @ 2026-03-24 07:16 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: [email protected]
Hi,
On Mon, Mar 23, 2026 at 04:13:20PM +0100, Peter Eisentraut wrote:
> On 18.03.26 14:32, Peter Eisentraut wrote:
> > On 16.03.26 10:55, Peter Eisentraut wrote:
> > > On 09.03.26 17:39, Bertrand Drouvot wrote:
> > > > 0001: Prevent -Wstrict-prototypes and -Wold-style-definition warnings
> > > >
> > > > It fixes the remaining warnings that those new flags would generate.
> > >
> > > I have committed this one. I'll look at the rest next.
> >
> > Also committed.
>
> 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=msv...
[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,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Enable -Wstrict-prototypes and -Wold-style-definition by default
2026-03-09 16:39 Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-18 13:32 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
2026-03-24 07:16 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
@ 2026-03-25 03:17 ` Bertrand Drouvot <[email protected]>
1 sibling, 0 replies; 18+ messages in thread
From: Bertrand Drouvot @ 2026-03-25 03:17 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: [email protected]
Hi,
On Tue, Mar 24, 2026 at 10:36:43PM +0100, Peter Eisentraut wrote:
> On 24.03.26 08:16, Bertrand Drouvot wrote:
> > 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?
>
> Per discussion in [0] we effectively require 16.11, so I think this should
> be ok.
Agree, thanks for the link!
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Enable -Wstrict-prototypes and -Wold-style-definition by default
2026-03-09 16:39 Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-18 13:32 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
2026-03-24 07:16 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
@ 2026-03-27 07:38 ` Peter Eisentraut <[email protected]>
2026-03-27 10:07 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-04-06 21:19 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Tom Lane <[email protected]>
1 sibling, 2 replies; 18+ messages in thread
From: Peter Eisentraut @ 2026-03-27 07:38 UTC (permalink / raw)
To: Bertrand Drouvot <[email protected]>; +Cc: [email protected]
The first three patches have been committed.
On 24.03.26 08:16, Bertrand Drouvot wrote:
> 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'])
> "
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 protected]>
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 protected]>
Reviewed-by: Bertrand Drouvot <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/aa73q1aT0A3/vke/%40ip-10-97-1-34.eu-west-3.compute.intern...
---
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
Attachments:
[text/plain] v3-0001-Add-warning-option-Wold-style-declaration.patch (4.4K, 2-v3-0001-Add-warning-option-Wold-style-declaration.patch)
download | inline diff:
From ae3a34e762a7f8af22a0718f91d39200689c07e3 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <[email protected]>
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 protected]>
Reviewed-by: Bertrand Drouvot <[email protected]>
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
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Enable -Wstrict-prototypes and -Wold-style-definition by default
2026-03-09 16:39 Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-18 13:32 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
2026-03-24 07:16 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-27 07:38 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
@ 2026-03-27 10:07 ` Bertrand Drouvot <[email protected]>
2026-03-27 12:15 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
1 sibling, 1 reply; 18+ messages in thread
From: Bertrand Drouvot @ 2026-03-27 10:07 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: [email protected]
Hi,
On Fri, Mar 27, 2026 at 08:38:45AM +0100, Peter Eisentraut wrote:
> The first three patches have been committed.
>
> On 24.03.26 08:16, Bertrand Drouvot wrote:
> > 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'])
> > "
>
> 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 = [
+ '-Wmissing-prototypes',
+ '-Wold-style-declaration',
+ '-Wold-style-definition',
+ '-Wstrict-prototypes',
+]
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,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Enable -Wstrict-prototypes and -Wold-style-definition by default
2026-03-09 16:39 Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-18 13:32 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
2026-03-24 07:16 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-27 07:38 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
2026-03-27 10:07 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
@ 2026-03-27 12:15 ` Peter Eisentraut <[email protected]>
2026-03-27 13:23 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
0 siblings, 1 reply; 18+ messages in thread
From: Peter Eisentraut @ 2026-03-27 12:15 UTC (permalink / raw)
To: Bertrand Drouvot <[email protected]>; +Cc: [email protected]
On 27.03.26 11:07, Bertrand Drouvot wrote:
> 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++
> "
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.)
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Enable -Wstrict-prototypes and -Wold-style-definition by default
2026-03-09 16:39 Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-18 13:32 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
2026-03-24 07:16 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-27 07:38 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
2026-03-27 10:07 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-27 12:15 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
@ 2026-03-27 13:23 ` Bertrand Drouvot <[email protected]>
2026-03-30 21:50 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 18+ messages in thread
From: Bertrand Drouvot @ 2026-03-27 13:23 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: [email protected]
Hi,
On Fri, Mar 27, 2026 at 01:15:29PM +0100, Peter Eisentraut wrote:
> On 27.03.26 11:07, Bertrand Drouvot wrote:
> > 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++
> > "
>
> 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,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Enable -Wstrict-prototypes and -Wold-style-definition by default
2026-03-09 16:39 Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-18 13:32 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
2026-03-24 07:16 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-27 07:38 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
2026-03-27 10:07 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-27 12:15 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
2026-03-27 13:23 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
@ 2026-03-30 21:50 ` Peter Eisentraut <[email protected]>
0 siblings, 0 replies; 18+ messages in thread
From: Peter Eisentraut @ 2026-03-30 21:50 UTC (permalink / raw)
To: Bertrand Drouvot <[email protected]>; +Cc: [email protected]
On 27.03.26 14:23, Bertrand Drouvot wrote:
> Hi,
>
> On Fri, Mar 27, 2026 at 01:15:29PM +0100, Peter Eisentraut wrote:
>> On 27.03.26 11:07, Bertrand Drouvot wrote:
>>> 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++
>>> "
>>
>> 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.
Ok, both committed.
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Enable -Wstrict-prototypes and -Wold-style-definition by default
2026-03-09 16:39 Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-18 13:32 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
2026-03-24 07:16 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-27 07:38 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
@ 2026-04-06 21:19 ` Tom Lane <[email protected]>
2026-04-08 12:51 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
1 sibling, 1 reply; 18+ messages in thread
From: Tom Lane @ 2026-04-06 21:19 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Bertrand Drouvot <[email protected]>; [email protected]
Peter Eisentraut <[email protected]> writes:
> 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
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Enable -Wstrict-prototypes and -Wold-style-definition by default
2026-03-09 16:39 Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-18 13:32 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
2026-03-24 07:16 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-27 07:38 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
2026-04-06 21:19 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Tom Lane <[email protected]>
@ 2026-04-08 12:51 ` Peter Eisentraut <[email protected]>
2026-04-08 15:14 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Andrew Dunstan <[email protected]>
0 siblings, 1 reply; 18+ messages in thread
From: Peter Eisentraut @ 2026-04-08 12:51 UTC (permalink / raw)
To: Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; Dave Cramer <[email protected]>; +Cc: Bertrand Drouvot <[email protected]>; [email protected]
On 06.04.26 23:19, Tom Lane wrote:
> Peter Eisentraut <[email protected]> writes:
>> 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.
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.
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Enable -Wstrict-prototypes and -Wold-style-definition by default
2026-03-09 16:39 Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-18 13:32 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
2026-03-24 07:16 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-27 07:38 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
2026-04-06 21:19 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Tom Lane <[email protected]>
2026-04-08 12:51 ` Re: Enable -Wstrict-prototypes and -Wold-style-definition by default Peter Eisentraut <[email protected]>
@ 2026-04-08 15:14 ` Andrew Dunstan <[email protected]>
0 siblings, 0 replies; 18+ messages in thread
From: Andrew Dunstan @ 2026-04-08 15:14 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; Tom Lane <[email protected]>; Dave Cramer <[email protected]>; +Cc: Bertrand Drouvot <[email protected]>; [email protected]
On 2026-04-08 We 8:51 AM, Peter Eisentraut wrote:
> On 06.04.26 23:19, Tom Lane wrote:
>> Peter Eisentraut <[email protected]> writes:
>>> 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.
>
> 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.
drongo is updated
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 18+ messages in thread
end of thread, other threads:[~2026-04-08 15:14 UTC | newest]
Thread overview: 18+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-03-09 09:31 [PATCH v1 2/2] Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-09 16:39 Enable -Wstrict-prototypes and -Wold-style-definition by default Bertrand Drouvot <[email protected]>
2026-03-18 13:32 ` Peter Eisentraut <[email protected]>
2026-03-18 15:50 ` Nazir Bilal Yavuz <[email protected]>
2026-03-18 17:03 ` Tom Lane <[email protected]>
2026-03-18 17:26 ` Andres Freund <[email protected]>
2026-03-18 17:33 ` Tom Lane <[email protected]>
2026-03-18 19:15 ` Bertrand Drouvot <[email protected]>
2026-03-24 07:16 ` Bertrand Drouvot <[email protected]>
2026-03-25 03:17 ` Bertrand Drouvot <[email protected]>
2026-03-27 07:38 ` Peter Eisentraut <[email protected]>
2026-03-27 10:07 ` Bertrand Drouvot <[email protected]>
2026-03-27 12:15 ` Peter Eisentraut <[email protected]>
2026-03-27 13:23 ` Bertrand Drouvot <[email protected]>
2026-03-30 21:50 ` Peter Eisentraut <[email protected]>
2026-04-06 21:19 ` Tom Lane <[email protected]>
2026-04-08 12:51 ` Peter Eisentraut <[email protected]>
2026-04-08 15:14 ` Andrew Dunstan <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox