That weird feeling when you realise that the people you hang out with form such a weird niche that something considered common knowledge among you is being described as "buried deep within the C standard".<p>What's noteworthy is that the compiler isn't required to generate a warning if the array is too small. That's just GCC being generous with its help. The official stance is that it's simply undefined behaviour to pass a pointer to an object which is too small (yes, only to pass, even if you don't access it).
GCC also has an extension to support references to other parameters of the function:<p><pre><code> #include <stddef.h>
void foo(size_t n, int b[static n]);
</code></pre>
<a href="https://godbolt.org/z/c4o7hGaG1" rel="nofollow">https://godbolt.org/z/c4o7hGaG1</a><p>It is not limited to compile-time constants. Doesn't work in clang, sadly.
Pointer to array is not only type-safe, it is also objectively correct and should have always been the syntax used when passing in the address of a known, fixed size array. This is all a artifact of C automatically decaying arrays to pointers in argument lists when a array argument should have always meant passing a array by value; then this syntax would have been the only way to pass in the address of a array and we would not have these warts. Automatic decaying is truly one of the worst actual design mistakes of the language (i.e. a error even when it was designed, not the failure to adopt new innovations).
Better option: just wrap it in a unique struct.<p>There are perhaps only 3 numbers: 0, 1, and lots. A fair argument might be made that 2 also exists, but for anything higher, you need to think about your abstraction.
Funny thing about that n[static M] array checking syntax–it was even considered bad in 1999, when it was included:<p>"There was a unanimous vote that the feature is ugly, and a good consensus that its incorporation into the standard at the 11th hour was an unfortunate decision." - Raymond Mak (Canada C Working Group), <a href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_205.htm" rel="nofollow">https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_205.htm</a>
It wasn't considered bad, it was considered ugly and in the context given that is a major difference. The proposed alternative in that post to me is even more ugly so I would have agreed with the option that received the most support, to leave it as it was.
It was always considered bad not (just) because it's ugly, but because it hides potential problems and adds no safety at all: a `[static N]` parameter tells the compiler that the parameter will never be NULL, but the function can still be called with a NULL pointer anyway.<p>That's is the current state of both gcc and clang: they will both happily, without warnings, pass a NULL pointer to a function with a `[static N]` parameter, and then REMOVE ANY NULL CHECK from the function, because the argument can't possibly be NULL according to the function signature, so the check is obviously redundant.<p>See the example in [1]: note that in the assembly of `f1` the NULL check is removed, while it's present in the "unsafe" `f2`, making it actually safer.<p>Also note that gcc will at least tell you that the check in `f1()` is "useless" (yet no warning about `g()` calling it with a pointer that could be NULL), while clang sees nothing wrong at all.<p>[1] <a href="https://godbolt.org/z/ba6rxc8W5" rel="nofollow">https://godbolt.org/z/ba6rxc8W5</a>