Re: Use pg_icu_unicode_version(void) instead of pg_icu_unicode_version() - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Use pg_icu_unicode_version(void) instead of pg_icu_unicode_version()
Date
Msg-id 13d51b20-a69c-4ac1-8546-ec4fc278064f@eisentraut.org
Whole thread Raw
In response to Re: Use pg_icu_unicode_version(void) instead of pg_icu_unicode_version()  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Responses Re: Use pg_icu_unicode_version(void) instead of pg_icu_unicode_version()
List pgsql-hackers
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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Make copyObject work in C++
Next
From: Jim Jones
Date:
Subject: Re: [PoC] XMLCast (SQL/XML X025)