Horton
Menu

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add warning option -Wold-style-declaration

  2. configure: Apply -Werror=vla to C++ as well as C

  3. Enable warning like -Wstrict-prototypes on MSVC as well

  4. Remove compiler warning option -Wendif-labels

  5. Disable warnings in system headers in MSVC

  6. Fix -Wstrict-prototypes warning in ecpg_init_sqlca() declaration.

  1. Enable -Wstrict-prototypes and -Wold-style-definition by default

    Bertrand Drouvot <bertranddrouvot.pg@gmail.com> — 2026-03-09T16:39:07Z

    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

  2. Re: Enable -Wstrict-prototypes and -Wold-style-definition by default

    Peter Eisentraut <peter@eisentraut.org> — 2026-03-16T09:55:13Z

    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.

  3. Re: Enable -Wstrict-prototypes and -Wold-style-definition by default

    Peter Eisentraut <peter@eisentraut.org> — 2026-03-18T13:32:30Z

    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.

  4. Re: Enable -Wstrict-prototypes and -Wold-style-definition by default

    Nazir Bilal Yavuz <byavuz81@gmail.com> — 2026-03-18T15:50:20Z

    Hi,

Thank you for working on this!

On Wed, 18 Mar 2026 at 16:32, Peter Eisentraut <peter@eisentraut.org> 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

  5. Re: Enable -Wstrict-prototypes and -Wold-style-definition by default

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-03-18T17:03:03Z

    Nazir Bilal Yavuz <byavuz81@gmail.com> 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

  6. Re: Enable -Wstrict-prototypes and -Wold-style-definition by default

    Andres Freund <andres@anarazel.de> — 2026-03-18T17:26:26Z

    Hi,

On 2026-03-18 13:03:03 -0400, Tom Lane wrote:
> Nazir Bilal Yavuz <byavuz81@gmail.com> 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

  7. Re: Enable -Wstrict-prototypes and -Wold-style-definition by default

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-03-18T17:33:46Z

    Andres Freund <andres@anarazel.de> 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

  8. Re: Enable -Wstrict-prototypes and -Wold-style-definition by default

    Bertrand Drouvot <bertranddrouvot.pg@gmail.com> — 2026-03-18T19:15:33Z

    Hi,

On Wed, Mar 18, 2026 at 01:03:03PM -0400, Tom Lane wrote:
> Nazir Bilal Yavuz <byavuz81@gmail.com> 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

  9. Re: Enable -Wstrict-prototypes and -Wold-style-definition by default

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-03-18T19:29:00Z

    Bertrand Drouvot <bertranddrouvot.pg@gmail.com> writes:
> On Wed, Mar 18, 2026 at 01:03:03PM -0400, Tom Lane wrote:
>> 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.

Agreed and pushed.

			regards, tom lane

  10. Re: Enable -Wstrict-prototypes and -Wold-style-definition by default

    Peter Eisentraut <peter@eisentraut.org> — 2026-03-23T15:13:20Z

    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.

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.

Additionally, I propose to add -Wold-style-declaration, which is 
completely unrelated to -Wold-style-definition, but it has popped up a 
few times via the buildfarm (grep for it in git log), so I think we 
might as well add it so that everyone sees it.

Finally, I think we can remove the option -Wendif-labels, which doesn't 
do anything anymore that isn't the default.  (It was only not the 
default before gcc 4.0.)

  11. Re: Enable -Wstrict-prototypes and -Wold-style-definition by default

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-03-23T15:20:39Z

    Peter Eisentraut <peter@eisentraut.org> writes:
> I have a couple of follow-up patches that I had developed while playing 
> with this.

I'm not in a position to evaluate the MSVC-specific changes, but
+1 for the other two.

			regards, tom lane

  12. Re: Enable -Wstrict-prototypes and -Wold-style-definition by default

    Bertrand Drouvot <bertranddrouvot.pg@gmail.com> — 2026-03-24T07:16:47Z

    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=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,

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

  13. Re: Enable -Wstrict-prototypes and -Wold-style-definition by default

    Peter Eisentraut <peter@eisentraut.org> — 2026-03-24T21:36:43Z

    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.


[0]: 
https://www.postgresql.org/message-id/04ab76a3-186c-4a37-8076-e6882ebf9d43%40eisentraut.org

  14. Re: Enable -Wstrict-prototypes and -Wold-style-definition by default

    Bertrand Drouvot <bertranddrouvot.pg@gmail.com> — 2026-03-25T03:17:35Z

    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

  15. Re: Enable -Wstrict-prototypes and -Wold-style-definition by default

    Peter Eisentraut <peter@eisentraut.org> — 2026-03-27T07:38:45Z

    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?

  16. Re: Enable -Wstrict-prototypes and -Wold-style-definition by default

    Bertrand Drouvot <bertranddrouvot.pg@gmail.com> — 2026-03-27T10:07:40Z

    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

  17. Re: Enable -Wstrict-prototypes and -Wold-style-definition by default

    Peter Eisentraut <peter@eisentraut.org> — 2026-03-27T12:15:29Z

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

  18. Re: Enable -Wstrict-prototypes and -Wold-style-definition by default

    Bertrand Drouvot <bertranddrouvot.pg@gmail.com> — 2026-03-27T13:23:14Z

    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

  19. Re: Enable -Wstrict-prototypes and -Wold-style-definition by default

    Peter Eisentraut <peter@eisentraut.org> — 2026-03-30T21:50:24Z

    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.

  20. Re: Enable -Wstrict-prototypes and -Wold-style-definition by default

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-04-06T21:19:51Z

    Peter Eisentraut <peter@eisentraut.org> 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

  21. Re: Enable -Wstrict-prototypes and -Wold-style-definition by default

    Peter Eisentraut <peter@eisentraut.org> — 2026-04-08T12:51:05Z

    On 06.04.26 23:19, Tom Lane wrote:
> Peter Eisentraut <peter@eisentraut.org> 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.

  22. Re: Enable -Wstrict-prototypes and -Wold-style-definition by default

    Andrew Dunstan <andrew@dunslane.net> — 2026-04-08T15:14:35Z

    On 2026-04-08 We 8:51 AM, Peter Eisentraut wrote:
> On 06.04.26 23:19, Tom Lane wrote:
>> Peter Eisentraut <peter@eisentraut.org> 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