Re: New string-truncation warnings from GCC 15

Hi,

On 2025-09-16 18:48:07 -0400, Tom Lane wrote:
> Several of the buildfarm animals seem to have been updated to
> GCC 15 over the past week or so. They are now moaning about
> various places where we're intentionally omitting a string
> terminator, eg these warnings from scorpion:
>
> scorpion | 2025-09-16 18:39:03 | ../pgsql/src/backend/commands/copyfromparse.c:139:41: warning: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (12 chars into 11 available) [-Wunterminated-string-initialization]
> scorpion | 2025-09-16 18:39:03 | ../pgsql/src/backend/commands/copyto.c:109:41: warning: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (12 chars into 11 available) [-Wunterminated-string-initialization]
> scorpion | 2025-09-16 18:39:03 | ../pgsql/src/backend/utils/adt/encode.c:152:1: warning: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (513 chars into 512 available) [-Wunterminated-string-initialization]
> scorpion | 2025-09-16 18:39:03 | ../pgsql/src/backend/utils/adt/numutils.c:30:1: warning: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (201 chars into 200 available) [-Wunterminated-string-initialization]
> scorpion | 2025-09-16 18:39:03 | ../pgsql/contrib/fuzzystrmatch/daitch_mokotoff.c:92:20: warning: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (7 chars into 6 available) [-Wunterminated-string-initialization]
>
> These are not bugs, but it'd be a good idea to silence the
> warnings somehow.

I also started to see these locally, I was working up the will to do something
about it...

> Plan A seems to be to do what the warning suggests and add
> a "nonstring" marker to these constants. I gather the syntax
> is like this:
>
> char a2nonstring[1] __attribute__((nonstring)) = "a";
>
> It's not clear to me how well this approach will play with
> non-GCC compilers.

I'd assume we'd do something like

#if has_attribute(nonstring)
#define pg_nonstring __attribute__((nonstring))
#else
...
#define pg_nonstring
#endif

I can't really imagine that causing issues for other compilers...

> Plan B could be to change the code so that we're not
> truncating the implicit \0 characters. It doesn't look
> to me like this would involve any large amount of violence
> to the logic, but it's a bit less pretty.
>
> Plan B would be a compiler-independent fix, so I mildly favor plan B.

I very mildly prefer the attribute, since that triggers warnings when using
unsuitable string functions on such arrays... It's not a huge win or anything,
but seems mildly nice.

Greetings,

Andres Freund