Обсуждение: Use func(void) for functions with no parameters

Hi hackers,

In C standards till C17, func() means "unspecified parameters" while func(void)
means "no parameters". The former disables compile time type checking and was
marked obsolescent in C99 ([1]).

This patch replaces empty parameter lists with explicit void to enable proper
type checking and eliminate possible undefined behavior (see [1]) if the function
is called with parameters. This also prevents real bugs (API misuse for example).

Remarks:

- C23 ([2]) made func() and func(void) equivalent and would produce an error
if an argument is passed.

- The patch has been generated with the help of a coccinelle script [3]. It does
modify 8 functions and did not touch the few ones in .c "test" files (libpq_testclient.c
for example).

[1]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
[2]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf
[3]: https://github.com/bdrouvot/coccinelle_on_pg/blob/main/misc/use_func_void.cocci

Regards,

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

On Wed, 3 Dec 2025 at 15:51, Bertrand Drouvot
<bertranddrouvot.pg@gmail.com> wrote:
>
> Hi hackers,
>
> In C standards till C17, func() means "unspecified parameters" while func(void)
> means "no parameters". The former disables compile time type checking and was
> marked obsolescent in C99 ([1]).
>
> This patch replaces empty parameter lists with explicit void to enable proper
> type checking and eliminate possible undefined behavior (see [1]) if the function
> is called with parameters. This also prevents real bugs (API misuse for example).

LGTM, thanks!

I noticed the only changes here are for `static` definitions. Are we
just more careful with normal functions, or does the compiler complain
more easily about such "incomplete" definitions when they're in
headers or need to be linked against?


Kind regards,

Matthias van de Meent
Databricks (https://www.databricks.com)

Matthias van de Meent <boekewurm+postgres@gmail.com> writes:
> I noticed the only changes here are for `static` definitions. Are we
> just more careful with normal functions, or does the compiler complain
> more easily about such "incomplete" definitions when they're in
> headers or need to be linked against?

Some years ago we had a buildfarm animal that would complain about
this construct, so the tree used to be clean.  Probably it's just
chance that these have only snuck into local functions.

            regards, tom lane

Hi,

On Wed, Dec 03, 2025 at 10:15:41AM -0500, Tom Lane wrote:
> Matthias van de Meent <boekewurm+postgres@gmail.com> writes:
> > I noticed the only changes here are for `static` definitions. Are we
> > just more careful with normal functions, or does the compiler complain
> > more easily about such "incomplete" definitions when they're in
> > headers or need to be linked against?
> 
> Some years ago we had a buildfarm animal that would complain about
> this construct, so the tree used to be clean.  Probably it's just
> chance that these have only snuck into local functions.

Thank you both for looking at it!

The buildfarm animal remark makes me think to check with -Wstrict-prototypes
and -Wold-style-definition. I just did that and found two more (added in v2
attached) that the coccinelle script missed...

Those new two (run_apply_worker() and usage()) are also static, so that's just
chance.

Regards,

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

On Wed, Dec 03, 2025 at 03:53:37PM +0000, Bertrand Drouvot wrote:
> The buildfarm animal remark makes me think to check with -Wstrict-prototypes
> and -Wold-style-definition. I just did that and found two more (added in v2
> attached) that the coccinelle script missed...
> 
> Those new two (run_apply_worker() and usage()) are also static, so that's just
> chance.

LGTM, too.  I'll take care of committing this shortly.

-- 
nathan

Committed.

-- 
nathan