Re: New compiler warnings in buildfarm - Mailing list pgsql-hackers

From Ranier Vilela
Subject Re: New compiler warnings in buildfarm
Date
Msg-id CAEudQApxfgRjnwqUw=pyAB4pkL9pUrAVDwN4eNMBUVjaeVE0Fg@mail.gmail.com
Whole thread Raw
In response to New compiler warnings in buildfarm  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Em ter., 30 de jul. de 2024 às 13:19, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
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:
+1 for dropping the length specification.
The trailing \0 the compiler will automatically fill in.
Note this came from copyfromparse.c, who also have the same problem.

best regards,
Ranier Vilela

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Suboptimal spinlock code due to volatile
Next
From: Melih Mutlu
Date:
Subject: Do we still need parent column in pg_backend_memory_context?