Recent Features
| |||||||||||||
C and C++ could have non_nullable pointers, easilyC and C++ could have non_nullable pointers, easilyPosted Aug 20, 2009 18:25 UTC (Thu) by hummassa (subscriber, #307)In reply to: Null pointers, one month later by hppnq Parent article: Null pointers, one month later Put some pragma to deal with legacy code, etc...
int *nonnull a = NULL; // syntax error
int *b = NULL; // Ok
int f(int *nonnull c) { return *c; } // ok
int g(int *d) { return *d; } // syntax error
int h(int *e) {
if( e ) {
// here, "e" is of type "int *nonull" b/c of the check
return *e;
} else {
return 0;
}
} // ok
f(b); // syntax error
h(b); // ok
if( b ) f(b); // ok
(Log in to post comments)
C and C++ could have non_nullable pointers, easily Posted Aug 20, 2009 20:22 UTC (Thu) by nix (subscriber, #2304) [Link]
Great. Now what does malloc() return on error?
How will you *create* one of these pointers?
C and C++ could have non_nullable pointers, easily Posted Aug 21, 2009 4:47 UTC (Fri) by njs (guest, #40338) [Link]
Malloc returns a maybe-NULL pointer, just like now. The type system requires you to check for errors before it will let you dereference this pointer. (xmalloc can return a non-NULL pointer, though, because it has done the check.)
So... no problem?
C and C++ could have non_nullable pointers, easily Posted Aug 21, 2009 7:27 UTC (Fri) by nix (subscriber, #2304) [Link]
No improvement, more like. All it does is automates away the null checks
everyone should already be doing anyway, and replaces it with something which is sufficiently automated that I can't see how it could provide helpful output at runtime (unless it did a longjmp() or EH got added to C or something).
So at best it'd give you something like a dump of program state at the
C and C++ could have non_nullable pointers, easily Posted Aug 21, 2009 8:05 UTC (Fri) by njs (guest, #40338) [Link]
Well, xmalloc has all those effects, but that's the *point* of xmalloc, so I don't see what it has to do type-distinguishing nullable and non-nullable pointers... the point of which is to force people to think about whether a pointer can be null every time they want to dereference it, in a relatively painless way.
(This is all relatively common in languages with real type systems.)
C and C++ could have non_nullable pointers, easily Posted Aug 21, 2009 18:50 UTC (Fri) by bronson (subscriber, #4806) [Link]
> All it does is automates away the null checks everyone should already be doing anyway
More like it mandates the null checks that everybody is supposed to do but even the most skilled programmers can't get 100% correct. It should raise the quality of all C programs.
> at best it'd give you something like a dump of program state at the
Yes, that's better than dereferencing and getting rooted isn't it?
C and C++ could have non_nullable pointers, easily Posted Aug 21, 2009 19:06 UTC (Fri) by nix (subscriber, #2304) [Link]
True indeed. However, for nearly all programs (i.e., everything other than
kernels and those very rare userspace programs that dereference things at address zero or have structures whose sizeof() is in the multimegabyte range), dereferencing null pointers doesn't lead to a root hole, but to a crash. DoSes are bad enough, and it's still a bug...
So, yes, it's an improvement, but I'm not sure it's a large one. (I also
C and C++ could have non_nullable pointers, easily Posted Aug 27, 2009 19:30 UTC (Thu) by hummassa (subscriber, #307) [Link]
That's why, in my example, I stated that (sorry):
YOU CANNOT DEREFERENCE A NULLABLE POINTER
if you want to use the star, check if it is nullable. People will start to use non-nullable pointers everywhere in their interfaces because they don't want to be checking for null all the time. :-D Cunning, eh?
C and C++ could have non_nullable pointers, easily Posted Aug 27, 2009 19:31 UTC (Thu) by hummassa (subscriber, #307) [Link]
Forgot to explain: dereferencing a nullable pointer should be a syntax error. Uh, and no static_cast between nullable and non-nullable pointers, either... no cheating :-D
C and C++ could have non_nullable pointers, easily Posted Aug 20, 2009 22:19 UTC (Thu) by hppnq (guest, #14462) [Link] Well, yeah. For ages GCC has supported the nonnull function attribute, used to specify arguments of a function that should not be NULL so you can catch these at compile time.The problem, however, is that in non-trivial programs you need to be able to dereference pointers that could be NULL even if they should not be NULL. The compiler may not be able to catch all of these situations for you.
C and C++ could have non_nullable pointers, easily Posted Aug 21, 2009 4:45 UTC (Fri) by njs (guest, #40338) [Link]
> The problem, however, is that in non-trivial programs you need to be able to dereference pointers that could be NULL even if they should not be NULL.
Yes, that's no problem. When you set up the sort of type system he or she describes, you include some sort of syntax that lets you get convert a "nullable" pointer into a non-null pointer by checking that it is, in fact, non-NULL. Once it's a non-null pointer, it becomes legal to dereference. (In the OP's sketch they overload the 'if' operator for this, but you could add some sort of extra syntax instead if you want to make it clearer.)
It does mean you can't dereference a maybe-NULL pointer *that is actually NULL*, but... that's the point :-).
C and C++ could have non_nullable pointers, easily Posted Aug 21, 2009 7:17 UTC (Fri) by nix (subscriber, #2304) [Link]
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
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.
C and C++ could have non_nullable pointers, easily Posted Aug 21, 2009 8:00 UTC (Fri) by hppnq (guest, #14462) [Link] Once it's a non-null pointer, it becomes legal to dereference. This assumes that pointers do not change, which is only true in the trivial cases. If you want to be completely safe, your only option is to always check, right before using it, that a pointer is not NULL. And then, by the way, you still have to worry about what will happen it turns out to be pointing to 0x1. ;-)
C and C++ could have non_nullable pointers, easily Posted Aug 21, 2009 22:53 UTC (Fri) by nix (subscriber, #2304) [Link] I've maintained code that actually went so far as to do this:
struct blah *foo (...)
{
if (error_1)
return NULL;
if (error_2)
return (struct blah *)1;
if (error 3)
return (struct blah *)2;
/* repeat for ten or so errors */
return /* a real struct blah */;
}
After I'd finished being sick into the keyboard I got a new keyboard and
fixed it so it didn't do that anymore.
C and C++ could have non_nullable pointers, easily Posted Aug 21, 2009 23:40 UTC (Fri) by corbet (editor, #1) [Link] Ever seen the kernel ERR_PTR() macro? :)
C and C++ could have non_nullable pointers, easily Posted Aug 22, 2009 0:34 UTC (Sat) by nix (subscriber, #2304) [Link]
Ew. I wish you hadn't drawn my attention to that :)
... but ERR_PTR() has a somewhat comprehensible reason to exist. The thing
C and C++ could have non_nullable pointers, easily Posted Sep 9, 2009 6:59 UTC (Wed) by cmccabe (guest, #60281) [Link]
I actually don't see what the big deal is with ERR_PTR and friends.
In higher level languages like OCaml, Java, etc., when you encounter an unrecoverable error in a function, you throw an exception. Then the function has no return value-- control just passes directly to the relevant catch() block.
ERR_PTR is the same thing. Normally, the function would return a foo pointer, but an unrecoverable error happened. So you get an error code instead. As a bonus, if you forget to check for the error code, you get a guaranteed crash (well, if some bonehead hasn't allowed the page starting at address 0 to be mapped). I say "bonus" because the alternative is usually a nondeterministic crash.
C and C++ could have non_nullable pointers, easily Posted Sep 9, 2009 6:35 UTC (Wed) by cmccabe (guest, #60281) [Link]
C++ does have non nullable pointers. They're called references.
References must point to valid objects.
C and C++ could have non_nullable pointers, easily Posted Sep 9, 2009 14:28 UTC (Wed) by foom (subscriber, #14868) [Link]
The only problem is that:
Obj *p = 0; Obj &r = *p;
is perfectly valid. So they don't make a very good non-nullable pointer.
C and C++ could have non_nullable pointers, easily Posted Oct 18, 2009 22:52 UTC (Sun) by cmccabe (guest, #60281) [Link]
> The only problem is that:
> Obj *p = 0; > Obj &r = *p; > > is perfectly valid. So they don't make a very good non-nullable pointer.
There shall be no references to references, no arrays of references, and no pointers to references. The declaration of a reference shall contain an initializer (8.5.3) except when the declaration contains an explicit extern specifier (7.1.1), is a class member (9.2) declaration within a class declaration, or is the declaration of a parameter or a return type (8.3.5); see 3.1. A reference shall be initialized to refer to a valid object or function. [Note: in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the object obtained by dereferencing a null pointer, which causes undefined behavior. As described in 9.6, a reference cannot be bound directly to a bitfield. ]
ISO/IEC 14882:1998(E), the ISO C++ standard, in section 8.3.2 [dcl.ref]
C.
C and C++ could have non_nullable pointers, easily Posted Oct 19, 2009 3:47 UTC (Mon) by foom (subscriber, #14868) [Link]
> a null reference cannot exist in a well-defined program
I stand corrected.
I had always considered the "dereference" that occurs during the initialization of a reference
|
|||||||||||||