Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wVOmK-001vsA-1x for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Jun 2026 07:15:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wVOmJ-00AcUM-1M for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Jun 2026 07:15:39 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wVOmI-00AcUE-3D for pgsql-hackers@lists.postgresql.org; Fri, 05 Jun 2026 07:15:39 +0000 Received: from ma04-relay.lansolnet.com ([176.95.46.38]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wVOmG-00000001CHp-1iEd for pgsql-hackers@postgresql.org; Fri, 05 Jun 2026 07:15:37 +0000 ARC-Authentication-Results: i=1; ma04.lansolnet.com 1; spf=pass reason=mailfrom (ip=194.126.198.214, headerfrom=nidsa.net) smtp.mailfrom=nidsa.net smtp.helo=mail.cloud4partner.com; ARC-Message-Signature: a=rsa-sha256; bh=nGEQpJKN3IalJcNsPG5CDC05Li+VW/5CgUdw0Ju8rlc=; c=relaxed/relaxed; d=hornetsecurity.com; h=from:to:date:subject:mime-version:; i=1; s=hse1; t=1780643732; b=rmaapmL3dn2pRXEyd6vGO3tCqJLBlx3I9Hv0pP2u5oBDCe9Tr1CeQ6pUMdog52ev35xVCCmc lfxHETTMatf6Vn/urKYulFRphsqX9ekPaeNFFV1EJS+PiL0YNZVVVYjugL/bBjYwTzmMdwrKHAy /1pct2Uufq+tYMcpYB1Pi9u6QptOwf1FwQ1k8I9vu/auBuMV+wAH6S0Osrr/JcovT41hdIrRU08 WisRDSkFO/Y2VbBMI66S/LKug0nSYrF++jpsHoHDNQc4Jq/wB3+KvmDIomS9/AFYfu7yjcyBvBH DCcDwi6RAQsdjherSyKyPtUWvo0SYNzlWxhYdrmszbOsw== ARC-Seal: a=rsa-sha256; cv=none; d=hornetsecurity.com; i=1; s=hse1; t=1780643732; b=jtbuU5P4Q3ooXWW5Uh2fZvUU7y1i3NAcwkhNJN42BCf5PANYLQ80W5dMCo70ibKyW6UnSRfa a2oHL8jTQ3R0yjqLn56IR91lpzftTOWECUAmeVAXlysY2L/oeUgZbtbSRg7Ax5iBiqszRqWYyQR BBvoZTGRV84/MoZRm7FEpVPHSjFQLeTr3fxsHz4PvJV5wQfc3tfhGc9gsxyf9WVRrypHWzo1P24 IjERYWYANAOK1Zhe4USaXLDW1eJioxCwPG77XqF4ftKpVmywJoTFldTFTo5j4i0LC2MmqvQM7LV 2PVTMdJ0zlhGX5ONo7pF9bUYLVXMTlC+GzhBGBsLuY9kg== Received: from unknown ([194.126.198.214]) by ma04; Fri, 05 Jun 2026 09:15:32 +0200 Received: from MBX200E.cloud4partner.com (192.168.8.234) by MBX200E.cloud4partner.com (192.168.8.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521) id 15.1.2507.44; Fri, 5 Jun 2026 09:15:29 +0200 Received: from MBX200E.cloud4partner.com ([fe80::e4a1:818c:c1f9:8e28]) by MBX200E.cloud4partner.com ([fe80::e4a1:818c:c1f9:8e28%15]) with mapi id 15.01.2507.044; Fri, 5 Jun 2026 09:15:29 +0200 From: Hans Buschmann To: Tristan Partin , Nathan Bossart CC: "pgsql-hackers@postgresql.org" Subject: =?Windows-1252?Q?AW:_PG19beta1:_GCC_16.1.1_warning:_=91actual=5Farg=5Ftyp?= =?Windows-1252?Q?es=92_may_be_used_uninitialized_in_clauses.c?= Thread-Topic: =?Windows-1252?Q?PG19beta1:_GCC_16.1.1_warning:_=91actual=5Farg=5Ftypes?= =?Windows-1252?Q?=92_may_be_used_uninitialized_in_clauses.c?= Thread-Index: AQHc9C88/cIVe4rll0iBj/EtUV15e7YuXekAgAB6HICAALJqgw== Date: Fri, 5 Jun 2026 07:15:29 +0000 Message-ID: References: <6c52a1a6612948519468d46cb224a8c4@nidsa.net> , In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.8.240] Content-Type: multipart/alternative; boundary="_000_d891f1b260ae462aa2548b8aaf3f460dnidsanet_" MIME-Version: 1.0 X-cloud-security-sender: buschmann@nidsa.net X-cloud-security-recipient: pgsql-hackers@postgresql.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on ma04 with E7ECFB8155F X-cloud-security-connect: unknown[194.126.198.214], TLS=1, IP=194.126.198.214 X-cloud-security: scantime:.4975 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --_000_d891f1b260ae462aa2548b8aaf3f460dnidsanet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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 upgrad= e 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 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: =91actual_arg_types=92 may be u= sed 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 =91recheck_cast_fun= ction_args.isra=92: >> ../src/backend/optimizer/util/clauses.c:5152:19: warning: =91actual_arg_= types=92 may be used uninitialized [-Wmaybe-uninitialized] >> 5152 | rettype =3D 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 p= ronargs, > 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 =3D 0; > foreach(lc, args) > { > actual_arg_types[nargs++] =3D exprType((Node *) lfirst(lc)= ); > } > Assert(nargs =3D=3D pronargs); > memcpy(declared_arg_types, proargtypes, pronargs * sizeof(Oid)); > rettype =3D 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] =3D {Inval= idOid}; 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) --_000_d891f1b260ae462aa2548b8aaf3f460dnidsanet_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

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


root@fedora ~]# dnf list --installed gcc*
Installed packages (available for rei= nstall, 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 postgr= es (tested with 18.4 in the BUG report), so backpatching could be necessary= .


Hans Buschmann



Von: Tristan Partin <t= ristan@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: =91actual_arg_types=92 m= ay 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/optimize= r_util_clauses.c.o
>> ../src/backend/optimizer/util/clauses.c: In function =91recheck_ca= st_function_args.isra=92:
>> ../src/backend/optimizer/util/clauses.c:5152:19: warning: =91actua= l_arg_types=92 may be used uninitialized [-Wmaybe-uninitialized]
>>  5152 |         retty= pe =3D 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,
>            = ;            &n= bsp;            = ;            &n= bsp; Oid *proargtypes, int pronargs,
>            = ;            &n= bsp;            = ;            &n= bsp; HeapTuple func_tuple)
> {
>        [...]
>        Oid    &= nbsp;           &nbs= p;    actual_arg_types[FUNC_MAX_ARGS];
>        [...]
>        ListCell   *lc; >
>        if (list_length(args) > F= UNC_MAX_ARGS)
>            = ;    elog(ERROR, "too many function arguments"); >        nargs =3D 0;
>        foreach(lc, args)
>        {
>            = ;    actual_arg_types[nargs++] =3D exprType((Node *)= lfirst(lc));
>        }
>        Assert(nargs =3D=3D pronargs= );
>        memcpy(declared_arg_types, p= roargtypes, pronargs * sizeof(Oid));
>        rettype =3D 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    &= nbsp;           &nbs= p;    actual_arg_types[FUNC_MAX_ARGS] =3D {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)
--_000_d891f1b260ae462aa2548b8aaf3f460dnidsanet_--