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 1wIALh-007qTo-2i for pgsql-hackers@arkaria.postgresql.org; Wed, 29 Apr 2026 19:13:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wIALg-004idO-3C for pgsql-hackers@arkaria.postgresql.org; Wed, 29 Apr 2026 19:13:28 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wIALg-004idF-1q for pgsql-hackers@lists.postgresql.org; Wed, 29 Apr 2026 19:13:28 +0000 Received: from mail-yw1-x1133.google.com ([2607:f8b0:4864:20::1133]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wIALe-00000003r3A-1VKW for pgsql-hackers@postgresql.org; Wed, 29 Apr 2026 19:13:28 +0000 Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-7b6ae2ea4a1so1284777b3.2 for ; Wed, 29 Apr 2026 12:13:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1777490003; cv=none; d=google.com; s=arc-20240605; b=YFDuxSkVAY8Y6cJQQnpXSY68S4j3b7qjVEhbv/wqMj7rYdPb62G7ZR7wAJVWN9OQ8J +S6KpqeWuxKX+qkJhUsW6JMRlTJON3MwR1G+9M5mKn2sEIIlnsgC89djv7svWIwPe0ld nFjFFB8NuzhtDQlK1h+wQPHkjoK7nJf1mYRvRea3EEzo/0Sp1uzk9Xs+GeosUgENrEYA sgvB69p9YrfafU/t4LCkZRzQsBXYfB0DS3lGmB5Q9DWFqi7nTohxl7/AkQUZKMiSHm0b CkNEZjFCK+odhd/ZUTWgueRyLh0GySQcEScGizazVcz+lUYMC+uwgE1UFihrIAIC4fHJ 8skQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=Mp6sRRVg86pFGnzlVbPtHaV8YdCAz7n8amPN2ujDzSY=; fh=ab2QULvDsfAQZSkQ0LbXUMmEfPg89lFn2bauBsCokMg=; b=DqyA5WpLC1lLdk7VQJ9Uqo6RdS2NEK+fkCHnwZKbEKnLODfAcWLFgyuI/8kzZrrf/V YJzRALPD4E38nbaLGo4clvWWmUcl9JGwuk458lkZhysj6pg80VLV9yzwJh43ZbeMX9wV 8Awdv5Hp5/r2nip9AiLNq5onTmEgKRESFULNxi6cOdbFEuXwL6aErzmucq9+S4GkwVUc 3iws6U86BR4cNGSrppfNQB2jtO9UV8nWUUWMp9HWaFfu79pEdPtp/63owCAHbsWsfacz YKKyPegqS0QmDVPLXHEU8JKYrDu3WrQyWA0n6tTMOeIdH4iGyySHSY25APOG7cAF3YAP TirA==; darn=postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777490003; x=1778094803; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Mp6sRRVg86pFGnzlVbPtHaV8YdCAz7n8amPN2ujDzSY=; b=nt1/2gH7PLzlx5w6bXGSty10y2CswRe+xv0wBN2Iojn5ri6eoJw5dsKXvpOATr2ASy gEJq3PqNm8r7i4ovSdONzzlMZW1seXjzDF6x7vyPG2z5bp1h+Q3GkvqmHYdhiMCLVedX 7YmUEHSi9JnS6m+iKzJ7iYznEZ7+Fs+wAsjqRDDNJhvco/k99a4RrBonB4qKaGPz+HgV BoqGiSoPp0DrWvX+V1rdHIcZ6F6pNEFXIGSlBGapQ0Ln07ZpiaQiK1X4cMQu2GiHbxXo HDptgEiELWxDaUNGsuKDQcI6SN92MjwL5gGGxEy2TTS/yrPOIU7gWVqE+Q98CcPkvoXf 1uSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777490003; x=1778094803; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Mp6sRRVg86pFGnzlVbPtHaV8YdCAz7n8amPN2ujDzSY=; b=kHBWdlVmHfnLxa/bp/IWLQjSueo8zM6D547dD9v6WUHobMbJdbm84cC9wUbGACMtI0 FDW18Oxiv+/yZ7JpjIZmK01R9kTiksttMNc7ytLKTXyytG7j95xFhCN0E8H/FBCG/Vhh SmWrGou0uidS9aYewzd+ePgPEKuLFU6+idyVbqrEajDHQcs/N/4omt+vlRxoOiyANlY7 U6ne/y9XOdne78+PIn0v+Nr5Y0UpfEVjmJuzmGYr5eYHa40BTQMxn92qnMX6d4msAiml VojzS/6sZFVJXuPGm+6YvGdoPlYSbDc5zn5Hpfa4ge+k4qtULXhjxHjp7idoQIUn2Oed pjCQ== X-Gm-Message-State: AOJu0YyjtWr4zyecmfKzFLPZuroIJmpoeBKePO69Tfb3cVkkTF6mRvO4 T77YHY2mOeaF0ygmm0YGzsAPGBqUAvepbAk0vT2VzcVxnE3l3E0ST1WxDy9bdI5AWSYZTKSthXV sxFFFk8yWnW7ZCes8z0VLkC73ZLtw550I5qoQBP0= X-Gm-Gg: AeBDieujMVyZzXC/qcM7wST87ieQpOI/oBk2DBuAglnaO1B7NN1reyu21rECpUniOPT D0P9W9JwF0KtPgU2VjTaeX5tkUyObxKAhaef0KfgDJNeoowdJKvVe9hg43TQLkBeQ3x0y8mr7h6 7B5KDV7tb3SQolShnujjMSv2ykbco2EEpOKYvbU4K6U6voQBaLIbJheaSHkT0otL1dwV/jsOiOz gJ7UN+yQyC61t+mTclTd48Nvb33/SPYm+yN8DA5Mwrnulq2KSelPsMX5fZrCQjkR6mxt5vx6Vr3 q9B7vU6VjlpHuHRI6w== X-Received: by 2002:a05:690c:c50d:b0:7b2:2382:e309 with SMTP id 00721157ae682-7bd52963da2mr312387b3.33.1777490003183; Wed, 29 Apr 2026 12:13:23 -0700 (PDT) MIME-Version: 1.0 References: <3nuudxv365kjnmwjhnygdakhxuktpdjvf26rt26eb44esgqdrj@y2x3vomkrfoo> In-Reply-To: <3nuudxv365kjnmwjhnygdakhxuktpdjvf26rt26eb44esgqdrj@y2x3vomkrfoo> From: Ayush Tiwari Date: Thu, 30 Apr 2026 00:43:12 +0530 X-Gm-Features: AVHnY4J_yym7bBFEZGMxDPa_PaXa74pVf7vYPIAI4QpOFxVZndhTGClKwd-2m7E Message-ID: Subject: Re: Spurious warnings in crypto-des.c when building with gcc-16 -O3 To: Andres Freund Cc: pgsql-hackers@postgresql.org Content-Type: multipart/alternative; boundary="0000000000003b4c9406509e24f3" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000003b4c9406509e24f3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, On Wed, 29 Apr 2026 at 23:17, Andres Freund wrote: > Hi, > > Recently I got a bit of a shock building postgres with gcc-16: > > ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c: I= n > function =E2=80=98px_crypt_des=E2=80=99: > ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:67= 5:22: > warning: writing 8 bytes into a region of size 7 [-Wstringop-overflow=3D] > 675 | *q++ =3D *key << 1; > | ~~~~~^~~~~~~~~~~ > ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:65= 9:33: > note: at offset [1, 2] into destination object =E2=80=98keybuf=E2=80=99 o= f size 8 > 659 | keybuf[2]; > | ^~~~~~ > ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:65= 9:33: > note: at offset [2, 3] into destination object =E2=80=98keybuf=E2=80=99 o= f size 8 > ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:65= 9:33: > note: at offset [3, 4] into destination object =E2=80=98keybuf=E2=80=99 o= f size 8 > ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:65= 9:33: > note: at offset [4, 5] into destination object =E2=80=98keybuf=E2=80=99 o= f size 8 > ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:65= 9:33: > note: at offset [5, 6] into destination object =E2=80=98keybuf=E2=80=99 o= f size 8 > ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:65= 9:33: > note: at offset [6, 7] into destination object =E2=80=98keybuf=E2=80=99 o= f size 8 > ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:65= 9:33: > note: at offset [7, 8] into destination object =E2=80=98keybuf=E2=80=99 o= f size 8 > ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:67= 5:22: > warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=3D] > 675 | *q++ =3D *key << 1; > | ~~~~~^~~~~~~~~~~ > ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:65= 9:33: > note: at offset 8 into destination object =E2=80=98keybuf=E2=80=99 of siz= e 8 > 659 | keybuf[2]; > | ^~~~~~ > ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:65= 9:33: > note: at offset [9, 10] into destination object =E2=80=98keybuf=E2=80=99 = of size 8 > ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:65= 9:33: > note: at offset [10, 11] into destination object =E2=80=98keybuf=E2=80=99= of size 8 > ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:65= 9:33: > note: at offset [11, 12] into destination object =E2=80=98keybuf=E2=80=99= of size 8 > ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:65= 9:33: > note: at offset [12, 13] into destination object =E2=80=98keybuf=E2=80=99= of size 8 > ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:65= 9:33: > note: at offset [13, 14] into destination object =E2=80=98keybuf=E2=80=99= of size 8 > ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:65= 9:33: > note: at offset [14, 15] into destination object =E2=80=98keybuf=E2=80=99= of size 8 > > > Luckily it turns out that that the warning is spurious, due to a bug in g= cc > [1]. > > However, it took me quite a while to figure out what the hell the code wa= s > doing: > > char * > px_crypt_des(const char *key, const char *setting) > { > uint32 keybuf[2]; > ... > uint8 *q; > ... > > /* > * Copy the key, shifting each character up by one bit and padding wi= th > * zeros. > */ > q =3D (uint8 *) keybuf; > while (q - (uint8 *) keybuf - 8) > { > *q++ =3D *key << 1; > if (*key !=3D '\0') > key++; > } > > Like, it's far from immediately obvious where the 8 is coming from (it's > the > size of keybuf), whether there are precedence issues or what this is even > trying to achieve. > > And it's still not clear to me why on earth it makes sense to write it th= at > complicated, when it seems something like > > for (int byteno =3D 0; byteno < sizeof(keybuf); byteno++) > { > *q++ =3D *key << 1; > if (*key !=3D '\0') > key++; > } > > would do the same thing, except be trivially understandable for humans an= d > compilers. > > > Am I missing something or is what I suggest equivalent? Any reason to no= t > change it that way, both to clarify the code and to work around the > spurious > warning? > I got the warning with gcc-16 that you are pointing out. Your proposed rewrite looks equivalent to me. The current condition: q - (uint8 *) keybuf - 8 is a rather obscure way to say that the loop should stop once eight bytes have been written, and it seems plausible that gcc is getting confused by that form. There is one similar loop a little further down in the extended-DES path: while (q - (uint8 *) keybuf - 8 && *key) *q++ ^=3D *key++ << 1; That one did not warn in my build, probably because of the additional data-dependent "*key" condition, but it uses the same idiom. It might be worth rewriting both loops to use an explicit sizeof(keybuf)-bounded for loop, for readability and consistency. Regards, Ayush --0000000000003b4c9406509e24f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

=
On Wed= , 29 Apr 2026 at 23:17, Andres Freund <andres@anarazel.de> wrote:
Hi,

Recently I got a bit of a shock building postgres with gcc-16:

../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c: In = function =E2=80=98px_crypt_des=E2=80=99:
../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:675:= 22: warning: writing 8 bytes into a region of size 7 [-Wstringop-overflow= =3D]
=C2=A0 675 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*= q++ =3D *key << 1;
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0~~~~~^~~~~~~~~~~
../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:659:= 33: note: at offset [1, 2] into destination object =E2=80=98keybuf=E2=80=99= of size 8
=C2=A0 659 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0keybuf[2];
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^~~~~~ ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:659:= 33: note: at offset [2, 3] into destination object =E2=80=98keybuf=E2=80=99= of size 8
../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:659:= 33: note: at offset [3, 4] into destination object =E2=80=98keybuf=E2=80=99= of size 8
../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:659:= 33: note: at offset [4, 5] into destination object =E2=80=98keybuf=E2=80=99= of size 8
../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:659:= 33: note: at offset [5, 6] into destination object =E2=80=98keybuf=E2=80=99= of size 8
../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:659:= 33: note: at offset [6, 7] into destination object =E2=80=98keybuf=E2=80=99= of size 8
../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:659:= 33: note: at offset [7, 8] into destination object =E2=80=98keybuf=E2=80=99= of size 8
../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:675:= 22: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=3D= ]
=C2=A0 675 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*= q++ =3D *key << 1;
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0~~~~~^~~~~~~~~~~
../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:659:= 33: note: at offset 8 into destination object =E2=80=98keybuf=E2=80=99 of s= ize 8
=C2=A0 659 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0keybuf[2];
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^~~~~~ ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:659:= 33: note: at offset [9, 10] into destination object =E2=80=98keybuf=E2=80= =99 of size 8
../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:659:= 33: note: at offset [10, 11] into destination object =E2=80=98keybuf=E2=80= =99 of size 8
../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:659:= 33: note: at offset [11, 12] into destination object =E2=80=98keybuf=E2=80= =99 of size 8
../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:659:= 33: note: at offset [12, 13] into destination object =E2=80=98keybuf=E2=80= =99 of size 8
../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:659:= 33: note: at offset [13, 14] into destination object =E2=80=98keybuf=E2=80= =99 of size 8
../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-des.c:659:= 33: note: at offset [14, 15] into destination object =E2=80=98keybuf=E2=80= =99 of size 8


Luckily it turns out that that the warning is spurious, due to a bug in gcc=
[1].

However, it took me quite a while to figure out what the hell the code was<= br> doing:

char *
px_crypt_des(const char *key, const char *setting)
{
=C2=A0 =C2=A0 uint32 keybuf[2];
...
=C2=A0 =C2=A0 uint8=C2=A0 =C2=A0 =C2=A0 *q;
...

=C2=A0 =C2=A0 /*
=C2=A0 =C2=A0 =C2=A0* Copy the key, shifting each character up by one bit a= nd padding with
=C2=A0 =C2=A0 =C2=A0* zeros.
=C2=A0 =C2=A0 =C2=A0*/
=C2=A0 =C2=A0 q =3D (uint8 *) keybuf;
=C2=A0 =C2=A0 while (q - (uint8 *) keybuf - 8)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *q++ =3D *key << 1;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (*key !=3D '\0')
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key++;
=C2=A0 =C2=A0 }

Like, it's far from immediately obvious where the 8 is coming from (it&= #39;s the
size of keybuf), whether there are precedence issues or what this is even trying to achieve.

And it's still not clear to me why on earth it makes sense to write it = that
complicated, when it seems something like

=C2=A0 =C2=A0 for (int byteno =3D 0; byteno < sizeof(keybuf); byteno++)<= br> =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *q++ =3D *key << 1;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (*key !=3D '\0')
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key++;
=C2=A0 =C2=A0 }

would do the same thing, except be trivially understandable for humans and<= br> compilers.


Am I missing something or is what I suggest equivalent?=C2=A0 Any reason to= not
change it that way, both to clarify the code and to work around the spuriou= s
warning?

I got the warning with gcc-16 that = you are pointing out.

Your proposed rewrite looks equivalent to me.=C2=A0 The cu= rrent condition:

=C2=A0 q - (uint8 *) keybuf - 8

is a rather = obscure way to say that the loop should stop once eight bytes
have been = written, and it seems plausible that gcc is getting confused by
that for= m.

There is one similar loop a little further down in the extended-D= ES path:

=C2=A0 while (q - (uint8 *) keybuf - 8 && *key)
= =C2=A0 =C2=A0 =C2=A0 *q++ ^=3D *key++ << 1;

That one did not w= arn in my build, probably because of the additional
data-dependent "= ;*key" condition, but it uses the same idiom.=C2=A0 It might be
wor= th rewriting both loops to use an explicit sizeof(keybuf)-bounded for
lo= op, for readability and consistency.

Regards,
Ayu= sh
--0000000000003b4c9406509e24f3--