Re: Use pg_icu_unicode_version(void) instead of pg_icu_unicode_version()
От
Peter Eisentraut
Тема
Re: Use pg_icu_unicode_version(void) instead of pg_icu_unicode_version()
Дата
Msg-id
13d51b20-a69c-4ac1-8546-ec4fc278064f@eisentraut.org
Ответ на
Re: Use pg_icu_unicode_version(void) instead of pg_icu_unicode_version() (Bertrand Drouvot)
Список
Дерево обсуждения
Use pg_icu_unicode_version(void) instead of pg_icu_unicode_version() Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: Use pg_icu_unicode_version(void) instead of pg_icu_unicode_version() Chao Li <li.evan.chao@gmail.com>
Re: Use pg_icu_unicode_version(void) instead of pg_icu_unicode_version() Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: Use pg_icu_unicode_version(void) instead of pg_icu_unicode_version() Peter Eisentraut <peter@eisentraut.org>
Re: Use pg_icu_unicode_version(void) instead of pg_icu_unicode_version() Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: Use pg_icu_unicode_version(void) instead of pg_icu_unicode_version() Peter Eisentraut <peter@eisentraut.org>
Re: Use pg_icu_unicode_version(void) instead of pg_icu_unicode_version() Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: Use pg_icu_unicode_version(void) instead of pg_icu_unicode_version() Joe Conway <mail@joeconway.com>
Re: Use pg_icu_unicode_version(void) instead of pg_icu_unicode_version() Andreas Karlsson <andreas@proxel.se>
Re: Use pg_icu_unicode_version(void) instead of pg_icu_unicode_version() Jeff Davis <pgsql@j-davis.com>
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.
В списке pgsql-hackers по дате отправления