This is an RFC pull-request to check if this approach is acceptable. It's what we do in Unit and what I've proposed for njs.

GCC 15 (Fedora 42 which shipped today^H^H^Hyesterday has a GCC 15 snapshot) implements a new warning -Wunterminated-string-initialization that is also enabled by -Wextra that we enable.

This causes compilation failures (due to -Werror) due to the likes of

static const u_char nginx[5] = "\x84\xaa\x63\x55\xe7";

E.g.

src/http/v2/ngx_http_v2_filter_module.c:118:36: error: initializer-string for array of ‘unsigned char’ truncates NUL terminator but destination lacks ‘nonstring’ attribute (6 chars into 5 available) [-Werror=unterminated-string-initialization]
        118 |     static const u_char nginx[5] = "\x84\xaa\x63\x55\xe7";
            |                                    ^~~~~~~~~~~~~~~~~~~~~~

These are very much meant not to be NUL terminated.

Now we could just disable this new warning. But I think it is worth leaving it enabled (the GCC developers also obviously feel it's useful enough to enable under -Wexta), anything that helps the compiler help us avoid silly mistakes is a good thing(tm), particularly in the current climate.

So rather than disable this warning, we can make use of the GCC "nonstring" variable attribute __attribute__((nonstring)).

This attribute is used to mark character arrays that are intentionally not NUL terminated.

So the above example would become (we of course wrap it in a more friendly name NGX_NONSTRING)

 static const u_char nginx[5] NGX_NONSTRING = "\x84\xaa\x63\x55\xe7";

This attribute doesn't exist in clang (where we just define it to nothing), but then clang doesn't have this warning.

The good news is no released version of GCC had this warning that couldn't be quelled by the "nonstring" attribute. (This attribute existed before this new warning was added, the fix to allow this attribute to quell the warning went in sometime after the warning was added).

The first commit checks for the "nonstring" attribute.

The second commit is just a taster of what it looks like in practice.

Before I go through finding all the places that need fixing, I just wanted to check a couple of things.

So @arut @pluknet a couple of questions.

1. Is this general approach acceptable?

I believe it to be superior to either simply disabling this new warning or removing the size from arrays making them NUL terminated, or setting the individual array elements.

I think it's a good idea to keep the warning enabled and aside from saving a byte it keeps it clear what their function is. Code may also assume these arrays to be of certain sizes.

2. I couldn't find a great place to create the NGX_NONSTRING macro, so I just stuck it in src/core/ngx_config.h.

An alternative would be to create a new file something like src/core/ngx_clang.h for putting general C language stuff (we have this in Unit & njs).