`-Wunterminated-string-initialization` warning on some kinds of initializations appears to be unactionable

[alexrp]

#include <stdint.h>
int main() {
    uint8_t *p = (uint8_t[4]){"\252\273\314\335"};
}

❯ clang test.c -Wunterminated-string-initialization
test.c:3:31: warning: initializer-string for character array is too long, array size is 4 but initializer has size 5
      (including the null terminating character); did you mean to use the 'nonstring' attribute? [-Wunterminated-string-initialization]
    3 |     uint8_t *p = (uint8_t[4]){"\252\273\314\335"};
      |                               ^~~~~~~~~~~~~~~~~~
1 warning generated.

We've already made Zig's C backend use __attribute__((nonstring)) where possible, but in cases like this, it doesn't seem like there's anything we can do?

cc @AaronBallman (#137829)

[shafik]

Can you provide more context to what your are trying to do with the code? Maybe there are alternatives solutions.

[alexrp]

It's code generated by Zig's C backend. This is the actual case we hit:

test
└─ test-modules
   └─ test-behavior
      └─ run test behavior-native-raptorlake-Debug-libc-cbe
         └─ compile exe behavior-native-raptorlake-Debug-libc-cbe Debug native 1 errors
.zig-cache/o/506a40b60804eec97fcc76d86af777c1/test.c:439752:135: error: initializer-string for character array is too long, array size is 4 but initializer has size 5 (including the null terminating character); did you mean to use the 'nonstring' attribute?
 t1 = *((union behavior_union_test_store_20of_20comptime_20reinterpreted_20memory_20to_20extern_20union_U__78669 const *)(uint8_t[4]){"\252\273\314\335"});

Obviously we could emit individual elements instead of a string literal, but that would be suboptimal codegen in the sense that it makes the C compiler do more work and use more memory, especially for larger arrays. This adds up when we're generating files that contain hundreds of thousands to millions of lines.

[tbaederr]

For generated code, you'd pass -Wno-unterminated-string-initialization, or not?

[alexrp]

We try to keep the output of our C backend -Wall -Wextra clean. We have a handful of warnings disabled, but only because we haven't yet done the work to get rid of them, not necessarily because it's impossible to do so.

I think this case is pretty unusual in how there's no remedy other than disabling the warning or entirely avoiding a perfectly valid language construct. IMO the warning should either not fire in cases like this one, or it should be split into two warnings: One in -Wextra that only fires when there's a reasonable remedy, and a stronger version that fires in cases like this but which requires explicit opt-in.

[AaronBallman]

#include <stdint.h>
int main() {
uint8_t *p = (uint8_t[4]){"\252\273\314\335"};
}

❯ clang test.c -Wunterminated-string-initialization
test.c:3:31: warning: initializer-string for character array is too long, array size is 4 but initializer has size 5
(including the null terminating character); did you mean to use the 'nonstring' attribute? [-Wunterminated-string-initialization]
3 | uint8_t *p = (uint8_t[4]){"\252\273\314\335"};
| ^~~~~~~~~~~~~~~~~~
1 warning generated.

We've already made Zig's C backend use __attribute__((nonstring)) where possible, but in cases like this, it doesn't seem like there's anything we can do?

cc @AaronBallman (#137829)

This behavior is consistent with GCC: https://godbolt.org/z/ofnT7c6so and I think it points out a real bug more often than it is a false positive, so I'm not certain we'd want to make a change. There is something you can do, which is provide the elements explicitly:

int main() {
    __attribute__((nonstring)) const char *p = (char[4]){0252, 0273, 0314, 0335};
}

https://godbolt.org/z/5aq4r9j3c