can-be-null can-not-be-null break-instruction for better handling pointers.

can-be-null can-not-be-null break-instruction for better handling pointers.

[Sławomir Lach]

I am not C expert, so be polity. I do not see something similar in C world, 
but similar techniques in other languages, such like Vala.

I suggest to create two new pointer type:
1. can-be-null
2. cannot-be-null
(You must find other words to describe it behavior).

First enforces to compiler checking it is not null, when it was used (by -> 
operator) or used, when cannot-be-null is excepted. Of course, user can cast 
to cannot-be-null to avoid checking. So:
1. Usage with -> operator, or * must be placed inside conditional block, with 
contains null check in condition
2. Passing as cannot-be-null (except explicit conversion) will requires to put 
in block as above

The same restrictions apply to put normal pointer in case, when cannot-be-null 
excepted.

Additionally, break-instruction word will be reserved for functions, so exit 
will be traded as end of control-flow and further code will be traded as 
checked.

Imagine assert will be traded as break-ins

This code:

int get_vector_size(struct vector cannot-be-null *vec)
{
   assert(vec != NULL)

   return vec->size;
}

Will be correct, because assert macro will (possible) be extended to:

if (!(vec != NULL)) {
    puts("assertion error: vec != NULL");
    exit(1);
}

And exit will be break-instruction.

We could use cannot-be-null in some cases, such like:

int year;

scanf("How old are you:%d", &year);

But user could pass NULL as second parameter.

When pointers in scanf parameters are cannot-be-null, the compiler will 
disallow pass null by us.

Of course - inside scanf must check if each parameter are not NULL.

Another code:

void error(const char *message)
{
   perror(message);
}

And perror will have cannot-be-null word describe one's parameter.
This will cause compile-time-error, because message was passed to function, 
which parameter is cannot-be-null.

Programmer should do:
void error(const char *message)
{
   if (NULL != message)
     perror(message);
}

What do you think. This will solve a lot of problems,

It could be also great to introduce function checking if any of it parameter 
are null, but I do not known how to make it good-quality (simple in usage). 
Programer should propably pass number of passed parameters, or type of 
parameter before each.

Re: can-be-null can-not-be-null break-instruction for better handling pointers.

[Christopher Bazley]

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