From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Subject: New compiler warnings in buildfarm
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3074305.1722356349.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 30 Jul 2024 12:19:09 -0400
Message-ID: <3074306.1722356349@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/3074306.1722356349%40sss.pgh.pa.us>
Precedence: bulk

Sometime in the last month or so, flaviventris's bleeding-edge
version of gcc has started whining[1] about truncation of a
string literal's implicit trailing '\0' in contexts like this:

../pgsql/src/backend/commands/copyto.c:106:41: warning: initializer-string=
 for array of 'char' is too long [-Wunterminated-string-initialization]
  106 | static const char BinarySignature[11] =3D "PGCOPY\n\377\r\n\0";
      |                                         ^~~~~~~~~~~~~~~~~~~~

../pgsql/src/backend/utils/adt/numutils.c:29:1: warning: initializer-strin=
g for array of 'char' is too long [-Wunterminated-string-initialization]
   29 | "00" "01" "02" "03" "04" "05" "06" "07" "08" "09"
      | ^~~~

Presumably this'll appear in less-bleeding-edge releases in a
few months' time.

In the BinarySignature case, we could silence it in at least two ways.
We could remove the explicit trailing \0 and rely on the implicit one:

-static const char BinarySignature[11] =3D "PGCOPY\n\377\r\n\0";
+static const char BinarySignature[11] =3D "PGCOPY\n\377\r\n";

Or just drop the unnecessary array length specification:

-static const char BinarySignature[11] =3D "PGCOPY\n\377\r\n\0";
+static const char BinarySignature[] =3D "PGCOPY\n\377\r\n\0";

Or we could do both things, but that feels perhaps too magic.

In the numutils.c case, I think that dropping the array length
spec is the only reasonable fix, since the last desired character
isn't a \0:

-static const char DIGIT_TABLE[200] =3D
+static const char DIGIT_TABLE[] =3D
 "00" "01" "02" "03" "04" "05" "06" "07" "08" "09"
 ...
 "90" "91" "92" "93" "94" "95" "96" "97" "98" "99";

There is one more similar complaint:

../pgsql/contrib/fuzzystrmatch/daitch_mokotoff.c:92:20: warning: initializ=
er-string for array of 'char' is too long [-Wunterminated-string-initializ=
ation]
   92 |         .soundex =3D "000000",            /* Six digits */
      |                    ^~~~~~~~

Here, the struct field is declared

	char		soundex[DM_CODE_DIGITS];	/* Soundex code */

and we probably don't want to mess with that.  However, elsewhere in
the same struct initialization I see

	char		prev_code_digits[2];
	char		next_code_digits[2];

...

	.prev_code_digits =3D {'\0', '\0'},
	.next_code_digits =3D {'\0', '\0'},

and that's *not* drawing a warning.  So the most plausible fix
seems to be

-         .soundex =3D "000000",            /* Six digits */
+         .soundex =3D {'0', '0', '0', '0', '0', '0'},  /* Six digits */

(In principle, we could fix the COPY and numutils cases the same
way, but I don't care for the readability loss that'd entail.)

Preferences, other suggestions?

			regards, tom lane

[1] https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=3Dflaviv=
entris&dt=3D2024-07-30%2012%3A29%3A41&stg=3Dbuild