public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: [email protected]
Subject: New compiler warnings in buildfarm
Date: Tue, 30 Jul 2024 12:19:09 -0400
Message-ID: <[email protected]> (raw)
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] = "PGCOPY\n\377\r\n\0";
| ^~~~~~~~~~~~~~~~~~~~
../pgsql/src/backend/utils/adt/numutils.c:29:1: warning: initializer-string 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] = "PGCOPY\n\377\r\n\0";
+static const char BinarySignature[11] = "PGCOPY\n\377\r\n";
Or just drop the unnecessary array length specification:
-static const char BinarySignature[11] = "PGCOPY\n\377\r\n\0";
+static const char BinarySignature[] = "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] =
+static const char DIGIT_TABLE[] =
"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: initializer-string for array of 'char' is too long [-Wunterminated-string-initialization]
92 | .soundex = "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 = {'\0', '\0'},
.next_code_digits = {'\0', '\0'},
and that's *not* drawing a warning. So the most plausible fix
seems to be
- .soundex = "000000", /* Six digits */
+ .soundex = {'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=flaviventris&dt=2024-07-30%2012%3A...
view thread (3+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: New compiler warnings in buildfarm
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox