PG19beta1: GCC 16.1.1 warning: ‘actual_arg_types’ may be used uninitialized in clauses.c

On Thu, Jun 04, 2026 at 02:42:18PM +0000, Hans Buschmann wrote:

839/2360] Compiling C object src/backend/postgres_lib.a.p/optimizer_util_clauses.c.o
../src/backend/optimizer/util/clauses.c: In function ‘recheck_cast_function_args.isra’:
../src/backend/optimizer/util/clauses.c:5152:19: warning: ‘actual_arg_types’ may be used uninitialized [-Wmaybe-uninitialized]
5152 | rettype = enforce_generic_type_consistency(actual_arg_types,

This code is ~18 years old, so I'm dubious there's a real problem here.
Does something like this suppress the warning?

Oid actual_arg_types[FUNC_MAX_ARGS] = {InvalidOid};

--
nathan

On Thu Jun 4, 2026 at 3:08 PM UTC, Nathan Bossart wrote:

On Thu, Jun 04, 2026 at 02:42:18PM +0000, Hans Buschmann wrote:

839/2360] Compiling C object src/backend/postgres_lib.a.p/optimizer_util_clauses.c.o
../src/backend/optimizer/util/clauses.c: In function ‘recheck_cast_function_args.isra’:
../src/backend/optimizer/util/clauses.c:5152:19: warning: ‘actual_arg_types’ may be used uninitialized [-Wmaybe-uninitialized]
5152 | rettype = enforce_generic_type_consistency(actual_arg_types,

This code is ~18 years old, so I'm dubious there's a real problem here.

Pulling the code into the email:

static void
recheck_cast_function_args(List *args, Oid result_type,
Oid *proargtypes, int pronargs,
HeapTuple func_tuple)
{
[...]
Oid actual_arg_types[FUNC_MAX_ARGS];
[...]
ListCell *lc;

if (list_length(args) > FUNC_MAX_ARGS)
elog(ERROR, "too many function arguments");
nargs = 0;
foreach(lc, args)
{
actual_arg_types[nargs++] = exprType((Node *) lfirst(lc));
}
Assert(nargs == pronargs);
memcpy(declared_arg_types, proargtypes, pronargs * sizeof(Oid));
rettype = enforce_generic_type_consistency(actual_arg_types,

GCC seems right to complain. A NIL list or a list with a length of 0
would initialize none of the elements in actual_arg_types. However, is
this a problem in actuality? No, because we use nargs to make sure we
don't access uninitialized memory in
enforce_generic_type_consistency(). Maybe GCC's static analysis is a lot
smarter than I give it credit for though, and this is a compiler bug in
the newer version.

Does something like this suppress the warning?

Oid actual_arg_types[FUNC_MAX_ARGS] = {InvalidOid};

I could not reproduce on 16.1.0 via nixpkgs or 16.1.1 on Fedora 44
(which is strange), but theoretically this would work.

--
Tristan Partin
PostgreSQL Contributors Team
AWS (https://aws.amazon.com)

I only want to add that my system is current up to date (dnf check-update --refresh), The GCC is installed from Fedora during the normal system upgrade process to Fedora 44.

root@fedora ~]# dnf list --installed gcc*
Installed packages (available for reinstall, available for upgrade)

gcc.x86_64 16.1.1-2.fc44 updates
gcc-c++.x86_64 16.1.1-2.fc44 updates
gcc-plugin-annobin.x86_64 16.1.1-2.fc44 updates

As seen in the Bug report, this is not specific to PG 19 beta1.

My guess is that this warning occurs on all supported versions of postgres (tested with 18.4 in the BUG report), so backpatching could be necessary.

Hans Buschmann

________________________________
Von: Tristan Partin <tristan@partin.io>
Gesendet: Freitag, 5. Juni 2026 00:24
An: Nathan Bossart
Cc: pgsql-hackers@postgresql.org; Hans Buschmann
Betreff: Re: PG19beta1: GCC 16.1.1 warning: ‘actual_arg_types’ may be used uninitialized in clauses.c

On Thu Jun 4, 2026 at 3:08 PM UTC, Nathan Bossart wrote:

On Thu, Jun 04, 2026 at 02:42:18PM +0000, Hans Buschmann wrote:

839/2360] Compiling C object src/backend/postgres_lib.a.p/optimizer_util_clauses.c.o
../src/backend/optimizer/util/clauses.c: In function ‘recheck_cast_function_args.isra’:
../src/backend/optimizer/util/clauses.c:5152:19: warning: ‘actual_arg_types’ may be used uninitialized [-Wmaybe-uninitialized]
5152 | rettype = enforce_generic_type_consistency(actual_arg_types,

This code is ~18 years old, so I'm dubious there's a real problem here.

Pulling the code into the email:

static void
recheck_cast_function_args(List *args, Oid result_type,
Oid *proargtypes, int pronargs,
HeapTuple func_tuple)
{
[...]
Oid actual_arg_types[FUNC_MAX_ARGS];
[...]
ListCell *lc;

if (list_length(args) > FUNC_MAX_ARGS)
elog(ERROR, "too many function arguments");
nargs = 0;
foreach(lc, args)
{
actual_arg_types[nargs++] = exprType((Node *) lfirst(lc));
}
Assert(nargs == pronargs);
memcpy(declared_arg_types, proargtypes, pronargs * sizeof(Oid));
rettype = enforce_generic_type_consistency(actual_arg_types,

GCC seems right to complain. A NIL list or a list with a length of 0
would initialize none of the elements in actual_arg_types. However, is
this a problem in actuality? No, because we use nargs to make sure we
don't access uninitialized memory in
enforce_generic_type_consistency(). Maybe GCC's static analysis is a lot
smarter than I give it credit for though, and this is a compiler bug in
the newer version.

Does something like this suppress the warning?

Oid actual_arg_types[FUNC_MAX_ARGS] = {InvalidOid};

I could not reproduce on 16.1.0 via nixpkgs or 16.1.1 on Fedora 44
(which is strange), but theoretically this would work.

--
Tristan Partin
PostgreSQL Contributors Team
AWS (https://aws.amazon.com)

On 2026-Jun-04, Nathan Bossart wrote:

On Thu, Jun 04, 2026 at 02:42:18PM +0000, Hans Buschmann wrote:

839/2360] Compiling C object src/backend/postgres_lib.a.p/optimizer_util_clauses.c.o
../src/backend/optimizer/util/clauses.c: In function ‘recheck_cast_function_args.isra’:
../src/backend/optimizer/util/clauses.c:5152:19: warning: ‘actual_arg_types’ may be used uninitialized [-Wmaybe-uninitialized]
5152 | rettype = enforce_generic_type_consistency(actual_arg_types,

This code is ~18 years old, so I'm dubious there's a real problem here.
Does something like this suppress the warning?

Oid actual_arg_types[FUNC_MAX_ARGS] = {InvalidOid};

I agree that it doesn't look like there's a real problem, and that
something like what you suggest should silence this warning. I mildly
prefer to do " = {0}" though, the rules for C incomplete initializers
being so weird. But I wouldn't oppose this patch as posted.

BTW we seem to do pretty much the same thing in ParseFuncOrColumn(),
right?

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"People get annoyed when you try to debug them." (Larry Wall)

On Fri, Jun 12, 2026 at 04:54:04PM +0200, Álvaro Herrera wrote:

On 2026-Jun-04, Nathan Bossart wrote:

This code is ~18 years old, so I'm dubious there's a real problem here.
Does something like this suppress the warning?

Oid actual_arg_types[FUNC_MAX_ARGS] = {InvalidOid};

I agree that it doesn't look like there's a real problem, and that
something like what you suggest should silence this warning. I mildly
prefer to do " = {0}" though, the rules for C incomplete initializers
being so weird. But I wouldn't oppose this patch as posted.

WFM. Hans, can you confirm this fixes the issue?

--
nathan

Op 6/17/26 om 16:39 schreef Nathan Bossart:

On Fri, Jun 12, 2026 at 04:54:04PM +0200, Álvaro Herrera wrote:

On 2026-Jun-04, Nathan Bossart wrote:

This code is ~18 years old, so I'm dubious there's a real problem here.
Does something like this suppress the warning?

Oid actual_arg_types[FUNC_MAX_ARGS] = {InvalidOid};

I agree that it doesn't look like there's a real problem, and that
something like what you suggest should silence this warning. I mildly
prefer to do " = {0}" though, the rules for C incomplete initializers
being so weird. But I wouldn't oppose this patch as posted.

WFM. Hans, can you confirm this fixes the issue?

FWIW, it silences that warning on my gcc 16.1.0

Erik

I also can confirm that this silences the compiler warning of GCC 16.1.1.

(tested with pg19_beta1, but should be the same on stable branches like 18.4)

No further tests here.

Hans Buschmann

On Thu, Jun 18, 2026 at 11:33:23AM +0000, Hans Buschmann wrote:

I also can confirm that this silences the compiler warning of GCC 16.1.1.

Thanks! I'm debating whether to back-patch this to unsupported branches.
IIUC it qualifies. I'm getting ready to bump up the minimum supported
version of pg_dump and friends to v10, so maybe I should stop there. But
also, stopping at v14 might be good enough for something small like this.
Any opinions?

--
nathan

On 2026-Jun-18, Nathan Bossart wrote:

On Thu, Jun 18, 2026 at 11:33:23AM +0000, Hans Buschmann wrote:

I also can confirm that this silences the compiler warning of GCC 16.1.1.

Thanks! I'm debating whether to back-patch this to unsupported branches.
IIUC it qualifies. I'm getting ready to bump up the minimum supported
version of pg_dump and friends to v10, so maybe I should stop there. But
also, stopping at v14 might be good enough for something small like this.
Any opinions?

I'd stop at 14 and call it a day. It doesn't prevent building, which is
IIRC the criteria we use for the older branches.

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"You're _really_ hosed if the person doing the hiring doesn't understand
relational systems: you end up with a whole raft of programmers, none of
whom has had a Date with the clue stick." (Andrew Sullivan)
/messages/by-id/20050809113420.GD2768@phlogiston.dyndns.org

On Thu, Jun 18, 2026 at 06:08:12PM +0200, Álvaro Herrera wrote:

I'd stop at 14 and call it a day. It doesn't prevent building, which is
IIRC the criteria we use for the older branches.

WFM. Committed, thanks.

--
nathan