NULL handling

[stephanearnold]

Hello,

While writing an interpreter in C, I have thought of a suggestion for
some new keywords that would help to reduce C application complexity:

- nullable
- notnullable

I have a bunch of sept_get_XXX functions that return a pointer to a
struct, namely sept_Type*.
I have defined 'nullable' and 'notnullable' as empty macros in the
main .H file.

Now I defined my functions prototypes as follows:

inline notnullable sept_Type* sept_get_dict(void);
inline notnullable sept_Type* sept_get_list(void);

And I think I will use these macros in my source tree even for
function arguments, like this:

int my_func(nullable sept_Foo* foo, notnullable gchar* msg);

Why doesn't exist such a functionality in standard C/ or in specific
compilers?
Has my idea a chance to live, or is there no way to create such
keywords?
By the way, I have noticed they tend to make my source code difficult
to read,
but I will strive and continue to use it until I find a better way to
handle such informations.

Regards,
Stéphane A.

 

[Richard]

Hello,

While writing an interpreter in C, I have thought of a suggestion for
some new keywords that would help to reduce C application complexity:

- nullable
- notnullable

I have a bunch of sept_get_XXX functions that return a pointer to a
struct, namely sept_Type*.
I have defined 'nullable' and 'notnullable' as empty macros in the
main .H file.

Now I defined my functions prototypes as follows:

inline notnullable sept_Type* sept_get_dict(void);
inline notnullable sept_Type* sept_get_list(void);

And I think I will use these macros in my source tree even for
function arguments, like this:

int my_func(nullable sept_Foo* foo, notnullable gchar* msg);

Why doesn't exist such a functionality in standard C/ or in specific
compilers?
Has my idea a chance to live, or is there no way to create such
keywords?
By the way, I have noticed they tend to make my source code difficult
to read,
Yes.....

but I will strive and continue to use it until I find a better way to
handle such informations.

How are these macros making anything simpler? You even admit it makes
your code harder to read. I see zero reason for them. Maybe you could
give an example of the problem you are trying to save with these
"extensions"? Especially since you will still need to manually check for
null conditions inside the functions.

 

[Walter Roberson]

While writing an interpreter in C, I have thought of a suggestion for
some new keywords that would help to reduce C application complexity:

- nullable
- notnullable

Why doesn't exist such a functionality in standard C/ or in specific
compilers?

You haven't indicated what they are intended to mean.

inline notnullable sept_Type* sept_get_dict(void);
inline notnullable sept_Type* sept_get_list(void);

If the intention is something along the line of "these routines
cannot return a NULL pointer", then

A) I can think of reasons why getting a list or dictionary
would need to return a NULL pointer; and

B) It doesn't make much difference to the compiler to know that
a pointer cannot become NULL. It would, I suppose, allow the
compiler to optimize away tests comparing the return result
against NULL, but if the coder knows from the API documentation
that it cannot be NULL and simply doesn't compare it to NULL then
there is nothing gained. Few compilers do "boundary checking"
before every access to ensure that the pointer is non-NULL: they
just go ahead and use the pointer and let the OS facilities catch
the problem. There are lots of other ways that pointer references
can fail (e.g., the pointer is junk, or an attempt is being made
to write into read-only memory) so the OS facilities have to be there
anyhow.

 

[SM Ryan]

# Why doesn't exist such a functionality in standard C/ or in specific
# compilers?

Because C doesn't have the notion of runtime checks. An implementation
may include such, but an implementation does not have to. Implementing
this only makes sense as a runtime check.

In a higher level language, what you want is to attach general
assertions to a type, perhaps like
type even = int where x: x mod 2 = 0

This however would be uncharacteristic of C.

 

[stephanearnold]

How are these macros making anything simpler? You even admit it makes
your code harder to read. I see zero reason for them. Maybe you could
give an example of the problem you are trying to save with these
"extensions"? Especially since you will still need to manually check for
null conditions inside the functions.

The benefits I see are:
- the compiler should warn me if I forget to test NULL values, or if I
check a NULL value that cannot happen.
- I will cease to write in the documentation : this function might/
cannot return NULL.

That is not a big win in the generic case, but in my special case it
might be.
Stephane

 

[Kenneth Brody]

[...]
The benefits I see are:
- the compiler should warn me if I forget to test NULL values, or if I
check a NULL value that cannot happen.

Just my $0.02 on the matter...

What if you simply return the value from a "nullable" function,
without checking it first? What if I store the value from such
a "nullable" function in a global variable, and test the value
later? What if NULL isn't a special case that has to be tested
against? (At least not by the function getting the NULL return.)

Perhaps you store a "notnullable" value into a variable, but
still need to test for NULL later on. For example:

mystruct_t *ptr = NULL;
...
if ( some_condition )
ptr = notnullable_function();
...
if ( ptr == NULL )

It sounds like this could get very complex to detect such
"wrong" tests.

Should the compiler add runtime checks to all returns from a
"notnullable" function to verify that the value is, in fact,
not NULL? (And what should it do if it is?)

- I will cease to write in the documentation : this function might/
cannot return NULL.

Shouldn't you go beyond documenting that a function can return NULL,
and document _why_ it might do so?

For example, even if you declare

extern nullable FILE *fopen(const char *,const char *);

you still need to document _why_ it would return NULL.

That is not a big win in the generic case, but in my special case it
might be.

I don't see anything beyond the possible (non-enforcable) use of
self-documenting in a header file, with no-op #defines for the
words.

Perhaps if you were to better describe your "special case", we
might come up with a "better" solution?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Gordon Burditt]

While writing an interpreter in C, I have thought of a suggestion for

some new keywords that would help to reduce C application complexity:

- nullable
- notnullable

So what are they supposed to *DO*?

I have a bunch of sept_get_XXX functions that return a pointer to a
struct, namely sept_Type*.
I have defined 'nullable' and 'notnullable' as empty macros in the
main .H file.

So what good are they?

Now I defined my functions prototypes as follows:

inline notnullable sept_Type* sept_get_dict(void);
inline notnullable sept_Type* sept_get_list(void);

What's the difference between that and:

inline /* notnullable */ /* GPLv3 */ sept_Type* sept_get_dict(void);
inline /* notnullable */ /* GPLv2 */ sept_Type* sept_get_list(void);
?

In particular, are you expecting the compiler to automatically generate
run-time checks and call abort() if any of them fail? C is not known
for having graceful run-time checking error handling.

I think you'd do far better with run-time license compatability
checking between calling and called functions.

And I think I will use these macros in my source tree even for
function arguments, like this:

int my_func(nullable sept_Foo* foo, notnullable gchar* msg);

Why doesn't exist such a functionality in standard C/ or in specific
compilers?

It is possible to introduce this feature as an extension to standard
C that doesn't make the resulting compiler non-conforming provided
you require programs to include <nullable.h> before using the
feature. That way you don't run afoul of namespace rules and

Has my idea a chance to live, or is there no way to create such
keywords?

See above. You can do it without making the compiler violate the
existing standard, although nullable and nonullable won't be
"keywords". They are reserved if you include <nullable.h>. I still
fail to see the purpose.