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
