Hi,
I agree with you that C would benefit from a new type qualifier to
indicate pointer nullability, although not with your suggestion that
such a qualifier should indicate the property cannot-be-null.
If you just want a syntax for declaring that a function parameter is
not a null pointer, C already supports that (with the same limitation
as for C++ references, that the type of the referenced object cannot
be void):
int get_vector_size(struct vector vec[static 1])
{
return vec->size;
}
You can even implement the other behaviour of C++ references, which is
that they can only point to one object during their lifetime:
int get_vector_size(struct vector vec[const static 1])
{
return vec->size;
}
In GCC, -Wnonnull is required to get a warning about passing null to
such a function, and (in my experience) it won't warn about
non-trivial cases where the null pointer isn't passed as an immediate
constant.
Regardless of what the language formally guarantees, most C source
code in the real world already assumes that pointers are not null in
the absence of information to the contrary. This assumption is
necessary, for example, because the first argument to every function
in a C language interface is typically a pointer which fulfils the
same role as 'this' (aka 'self') in an object-oriented language. You
will also see, if you study the C standard library, that functions
which have well-defined behaviour for null pointer values are in a
minority.
I recently wrote a paper on this topic, which proposes a new qualifier
as well as modified semantics for the unary & operator. This paper is
currently with the relevant ISO committee for consideration.
My related article on Medium examines a lot of prior art in the area,
as well as explaining why I think none of the existing solutions is
adequate: https://itnext.io/why-c-needs-a-new-type-qualifier-61ad553cbe71
The article contains links (at the end) to my paper, as well as to a
working prototype implementation of the functionality I propose
(albeit using Clang rather than GCC).
I previously posted on this mailing list to enquire about whether it
would be worthwhile to implement the same functionality in GCC, but
got slapped down. It seems to me that the era of compiler extensions
informing the language standardization process (rather than vice
versa) is over, but that's just my perception based on limited
feedback.
There's a reason why C programmers haven't replaced all of their 'int
*ip' pointer arguments with 'int ip[const static 1]' during the past
24 years, and I don't think they ever will. It doesn't resemble
Kernighan & Ritchie's "pleasant, expressive, and versatile" language
which featured "economy of expression". Nor does it conform to K&R's
intent that declaration syntax be mnemonic, since 'int ip[const static
1]' doesn't resemble anything: neither a pointer declaration in any
other context, nor a real array declaration, nor the syntax for array
usage in expressions.
Best regards,
--
Christopher Bazley
