| |||||||||||||
C and C++ could have non_nullable pointers, easilyC and C++ could have non_nullable pointers, easilyPosted Aug 21, 2009 7:17 UTC (Fri) by nix (subscriber, #2304)In reply to: C and C++ could have non_nullable pointers, easily by njs Parent article: Null pointers, one month later
So... instead of getting null pointer dereferences, we get
cannot_convert_null exceptions from the pointer conversion?
I still don't see any robustness benefit here.
(Of course proving that pointers cannot be null at compile time is
(Log in to post comments)
C and C++ could have non_nullable pointers, easily Posted Aug 21, 2009 7:48 UTC (Fri) by dgm (subscriber, #49227) [Link]
This would be useful if the type system _forced_ you to check before assigning a maybe-null-pointer to a never-null-pointer. And to be really useful, only never-null-pointers should be dereferenced, and the compiler would only allow pointer arithmetic on maybe-null-pointers.
The gotcha is that null pointers are just _one_ type of invalid pointer.
C and C++ could have non_nullable pointers, easily Posted Aug 21, 2009 19:10 UTC (Fri) by nix (subscriber, #2304) [Link]
Yes, those changes would make the idea genuinely useful. They'd also break
compatibility with almost all previous code: this from a language so conservative that by word-of-dmr the precedence of && and || was intentionally set wrong so as to avoid breaking code running on three sites :)
C and C++ could have non_nullable pointers, easily Posted Aug 22, 2009 1:10 UTC (Sat) by njs (guest, #40338) [Link]
Yeah, it's more of a thought experiment, though one could enable it only for certain (new) compilation units, or treat them as annotations for a tool like sparse.
C and C++ could have non_nullable pointers, easily Posted Aug 21, 2009 7:54 UTC (Fri) by farnz (guest, #17727) [Link] It's also impossible to verify the C type system; this doesn't stop compilers from running. The trick is to go for a conservative assessment; you're not interested in the choices "will sometimes be null/will never be null", you're interested in "might or might not be null/will never be null". The second is tractable; imagine an "ifnull( <ptrexpression> ) { null-block } else { <ptrexpression is now nonnull> nonnull-block }". By requiring you to use ifnull to convert nullable pointers to nonnull pointers whenever you might encounter them, the compiler can force you to decide how you're going to handle unexpected nulls. Whenever the compiler isn't sure that a pointer is nonnull, it gives a compile-time error message. So, examples:
int func1( int *pointer )
{
return *pointer; // Compile error here - cannot deference a nullable
}
int func2( int * nonnull pointer )
{
return *pointer; // OK
}
int func3( int * pointer )
{
return func2( pointer ); // Compile error here - even if pointer is
actually non-null.
}
int func4( int * pointer )
{
ifnull( pointer )
return 0;
else
return func3( pointer ); // OK, but func3 still won't compile, as
other callers might use a null pointer.
}
int func5( int * pointer )
{
ifnull( pointer )
return 0;
else
return func2( pointer ); // OK
}
This forces you to handle nulls sanely at some point, or fail to compile and link properly. Practical code handles nullness at boundary points, and then passes nonnull pointers around the place, to code which can assume that they're not null.
C and C++ could have non_nullable pointers, easily Posted Aug 27, 2009 19:35 UTC (Thu) by hummassa (subscriber, #307) [Link]
No, you get a syntax error everytime you try to dereference a nullable pointer. People will pepper the APIs with non-nullable pointers, and will prefer to pass them around instead of nullable pointers (that will still have their place as "optional object" references). But, if you want to use the star or the arrow, you will have to have a non-nullable pointer.
|
|||||||||||||