Hi Chris, > Date: 2026-10-24 17:16:19+0100 > From: Christopher Bazley > > On Sat, Oct 24, 2026 at 2:38 PM Alejandro Colomar > wrote: > > > > > Date: 2026-10-24 09:45:02-0300 > > > From: "Michael Kerrisk (man7.org)" > > > [...] > > > I was unfamiliar with that syntax, but at least in context it is > > > immediately understandable, > > > > Actually, it is not understandable. [static 2] doesn't mean the same as > > [2], and this is one historic mistake of the C Committee that I wish had > > never happened. [static 2] is never what you want (I was tempted to say > > almost never, but I've never seen a good case for it). Programmers want > > the meaning of [2]. > > > > The main differences between [static 2] and [2] are: > > > > - [2] means (in GNU C, and in common understanding, but not > > acknowledged by ISO C) that: > > > > - The caller must supply at least 2 elements. > > - The callee must not access past those 2 elements. > > > > - [static 2] means (in ISO C, but ignored by GCC): > > > > - The caller must supply at least 2 elements. > > - The callee is free to access past those 2 elements!! > > (of course, if there aren't any elements after that, it's UB) > > You can, of course, document for the benefit of callers that a > function does not read past the static array bound. Comments are bound to be wrong in the future, often near future. It's better to not use the feature, because it's not necessary. Just use [2], and ask your compiler to be better than what ISO C requires. > > - The caller must supply a non-null pointer. > > > > The null-pointer issue is nonsense, but we can live with it. > > The allowance to access past the specified length, that's the real issue > > with this feature, and why it should not be used at all. > > Of the compilers I have tried, only SDCC currently warns about access > past the specified length, and it does so regardless of whether the > length is specified using 'static' or not: > > int foo(int a[static 2]) > { > return a[2]; // warning from SDCC > } > > int bar(int a[2]) > { > return a[2]; // warning from SDCC > } > > https://godbolt.org/z/zf3nPerdn GCC has some partial diagnostics for out-of-bounds accesses. alx@debian:~/tmp$ cat oob.c void five(int a[5]); void four(int a[4]) { five(a); } void three(int a[static 3]) { five(a); } alx@debian:~/tmp$ gcc -Wall -Wextra -S oob.c oob.c: In function ‘four’: oob.c:4:9: warning: ‘five’ accessing 20 bytes in a region of size 16 [-Wstringop-overflow=] 4 | five(a); | ^~~~~~~ oob.c:4:9: note: referencing argument 1 of type ‘int[5]’ oob.c:1:6: note: in a call to function ‘five’ 1 | void five(int a[5]); | ^~~~ oob.c: In function ‘three’: oob.c:8:9: warning: ‘five’ accessing 20 bytes in a region of size 12 [-Wstringop-overflow=] 8 | five(a); | ^~~~~~~ oob.c:8:9: note: referencing argument 1 of type ‘int[5]’ oob.c:1:6: note: in a call to function ‘five’ 1 | void five(int a[5]); | ^~~~ I wish it diagnosed as much as SDCC, but not yet. :) > (I'm tempted to report the warning produced in the 'static' case as a > bug, but in reality no warning is a conformance issue, so that > characterisation is subjective.) Clearly, not a bug, but rather QoI. ISO C has a bug. > > The committee was clearly confused when they added this feature. > > It was around the time when 'restrict' was added, which is another > > historical mistake of the committee. In general, every feature they > > added thinking of optimizations (and that includes these two) has > > resulted in a mistake. > > > > > and I so I don't dislike it, And it is > > > standard C. > > > > When the standard clashes with reality and common sense, I'm not sure > > I'd give the standard much credibility. > > > > > I really don't think Linux man-pages is the place to > > > introducing nonstandard, GNU-specific syntax (that people clearly > > > don't understand). > > > > People clearly don't understand [static 2] either. > > My understanding is that [static 2] was introduced to facilitate cases > like the following, where an implementation could theoretically > generate code that reads the first four elements together, but would > have to load subsequent elements individually: My understanding is tthe same. > > int len(int s[static 4]) > { > int i = 0; > do > { > if (!s[i]) break; else ++i; > if (!s[i]) break; else ++i; > if (!s[i]) break; else ++i; > if (!s[i]) break; else ++i; > } while (1); > return i; > } > https://godbolt.org/z/ra6zh7Ej3 > > I have never yet managed to persuade a compiler to optimise such code > differently from a version without 'static 4', and I struggle to > believe it would ever be beneficial to do so. The more obvious case, > where an array bound such as [static 4 * n] potentially enables > speculative loads when unrolling a loop with an early exit, does not > need the compiler to be permitted to generate code that reads beyond > the passed-in array bound. And indeed, I agree. This seems a case of bad design, wishing that it might eventually be optimizable, while it wasn't and still isn't, and also while ignoring the safety issues caused by it. We should just pretend that the feature doesn't exist. Cheers, Alex --