I didn't know about use of static keyword in array parameter declaration, but I dare to say that a lot of senior C programmers are unaware of this C99 feature.
It's nice to be able to specify function's expectations on that level, yet it looks that only clang (tested with 3.5.0) takes use of it, while gcc (tested with 4.9.1) seems oblivious to it. Be it NULL or shorter string literal than expected, gcc with -Wall -Wextra -pedantic -std=c99 spits nothing. Both mistakes are detected by clang.
Sadly even clang doesn't warn us when fun(int len, char str[static len+1]) is called like fun(5, "test").
But I'm not sure that I agree with the rule 2.11.7.1 Don't use NULL. In any sane C environment NULL is defined as follows (unless __cplusplus is already defined, because then it's defined as 0 or 0L)
#define NULL ((void*)0)
and IMHO there is nothing wrong with that.
Distinguishing kind of 0 we're dealing with (even if it's not strongly guarded by compiler) is often important for readability and eases maintenance of the code (0 vs '\0' vs NULL). While comparing pointer with NULL (writing p == NULL or p != NULL instead of simply !p or p) may seem superfluous (yet I have nothing against programmers doing so), calling function with pointer parameters providing 0 argument instead of NULL seems less clear to me.
> if you really want to emphasize that the value is a pointer use the magic token sequence (void *)0 directly.
The topic was modern C and in modern C environment NULL is defined as
(void *)0
There is no point in writing longer form and it's still clearer and safer than 0 alone.
C++ is another story with its
void* hate
built-in. In this land you rather write
(type*)0
or
(type*)NULL
(or
static_cast<type*>(0)
for extra purists), but as you're denoting pointer type already in this notation, there is not much gain in using NULL instead of 0 (well, beside grepability).
In many cases you can be done with 0 alone in C++, that's true, and in such cases NULL at least poses some intention, but if you're not careful enough, you may end up putting NULL alone (without pointer-to-type cast) in some variadic function and things start to blow up all of a sudden (that is if your NULL integer width isn't the same as pointer width). That's why having a habit of writing
It's nice to be able to specify function's expectations on that level, yet it looks that only clang (tested with 3.5.0) takes use of it, while gcc (tested with 4.9.1) seems oblivious to it. Be it NULL or shorter string literal than expected, gcc with -Wall -Wextra -pedantic -std=c99 spits nothing. Both mistakes are detected by clang.
Sadly even clang doesn't warn us when fun(int len, char str[static len+1]) is called like fun(5, "test").
But I'm not sure that I agree with the rule 2.11.7.1 Don't use NULL. In any sane C environment NULL is defined as follows (unless __cplusplus is already defined, because then it's defined as 0 or 0L)
and IMHO there is nothing wrong with that.Distinguishing kind of 0 we're dealing with (even if it's not strongly guarded by compiler) is often important for readability and eases maintenance of the code (0 vs '\0' vs NULL). While comparing pointer with NULL (writing p == NULL or p != NULL instead of simply !p or p) may seem superfluous (yet I have nothing against programmers doing so), calling function with pointer parameters providing 0 argument instead of NULL seems less clear to me.
> if you really want to emphasize that the value is a pointer use the magic token sequence (void *)0 directly.
I don't buy it.