Hi, On Mon, Mar 09, 2026 at 09:44:45AM +0100, Peter Eisentraut wrote: > On 09.03.26 08:57, Bertrand Drouvot wrote: > > Hi, > > > > On Mon, Mar 02, 2026 at 07:36:20PM +0100, Peter Eisentraut wrote: > > > On 27.02.26 07:45, Bertrand Drouvot wrote: > > > > Hi, > > > > > > > > On Fri, Feb 27, 2026 at 02:04:30PM +0800, Chao Li wrote: > > > > > > > > > > > > > > > What I'm interested in is the broader policy: when reviewing patches, > > > > > if we encounter a foo() declaration, should we consistently request a > > > > > change to foo(void)? > > > > > If yes, the standard should be documented somewhere. > > > > > > > > I think that they should be consistently fixed for the reasons > > > > mentioned in > > > > [1], and that the best way to achieve this goal would be to enable > > > > -Wstrict-prototypes > > > > by default ([2]). > > > > > > Yes, why not add -Wstrict-prototypes and perhaps -Wold-style-definition to > > > the standard warnings. Then we don't have to keep chasing these manually. > > > > Yeah, I'll look at adding those. > > I played with this a little bit. A problem I found is that the generated > configure code itself generates its test programs with 'main()', and so with > these warnings, many of these tests will fail. So you'd need to create some > different arrangement where you test for the warnings but only add the flags > at the end of configure. > > But also, my research indicates that -Wstrict-prototypes and > -Wold-style-definition are available in all supported gcc and clang > versions, so maybe you could avoid this problem by not testing for them and > just unconditionally adding them at the end.
Yeah, I did observe the same. I moved the new flags late enough in configure.ac 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 the mingw_cross_warning CI task failing. I just shared the patch in a dedicated thread [1]. [1]: https://postgr.es/m/aa73q1aT0A3/vke/@ip-10-97-1-34.eu-west-3.compute.internal Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
