| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
NULL v. zero
NULL v. zero
Posted Jul 15, 2004 15:41 UTC (Thu) by ikm (subscriber, #493)In reply to: NULL v. zero by elanthis
Parent article: NULL v. zero
The fact that a NULL pointer is just 0 is not an implementation detail. It is not really a value -- it is a standard *syntax* to say that you want a pointer to be null. Please read my comment a bit more thourough, it is all there. It has nothing to do with weak type checking either. As a matter of fact, this works the very same way in C++, that is, null pointer constant is 0. In C/C++, the compiler always knows what you mean, judging from the context (is it a pointer being assigned or an integer? the compiler knows).
In case it was really about coding styles and not about the language, this is all moot anyway. People could use 0 as NULL, and it would be perfectly legal and correct, as long as they don't participate in kernel development that way. Sorry guys, I overlooked that.
Btw, the quoted "int i = NULL" is always incorrect, and that's the language issue, not a style issue.
(Log in to post comments)
NULL v. zero
Posted Jul 15, 2004 18:23 UTC (Thu) by dvdeug (subscriber, #10998) [Link]
Yes, it is weak type checking. The only way C++ is a strong type checking language is if you compare it to C or Assembly. If you used Ada or Java, or any of a hundred different languages, you couldn't convert a constant of type integer to a pointer. 0, standing alone in a strong typing system is not ambigious, and it doesn't change type depending on what things you stick around it.
NULL v. zero
Posted Jul 15, 2004 23:03 UTC (Thu) by ikm (subscriber, #493) [Link]
It is not a weak type checking, it is the absence of any type checking at all is some cases. It is not the language itself which imposes this absence, it is libraries that do. All that ellipsis functions for instance, as an execl example above. These prototypes doesn't give the compiler any clue about the types at all, so it can't apply any type checking in these cases. In case the compiler knows about types, it will act accordingly, converting zeroes to null pointers when applicable.
NULL v. zero
Posted Jul 15, 2004 19:37 UTC (Thu) by Ross (subscriber, #4065) [Link]
Actually, no. C++ is a little more strict. C++ doesn't have a genericpointer type like C.
Valid C:
int *ptr=malloc(10*sizeof(int));
That's not valid C++. Instead you have to do this:
int *ptr=(int *)malloc(10*sizeof(int));
Which is really annoying because it is obvious from the context what the
type should be, and it masks the bug of not including stdlib.h before
calling malloc.
So in C++ the nil pointer is 0 (they are very adamant about this).
In C it is NULL, which can be either (void *)0 or 0. The first is
obviously better since the compiler will complain if it is used in
invalid contexts but it's a quality of implementation issue not a
conformance issue.
NULL v. zero
Posted Jul 15, 2004 20:20 UTC (Thu) by dvdeug (subscriber, #10998) [Link]
Actually, C++ won't compile if you don't have a function prototype for malloc in scope. If you don't include <stdlib.h> or something else that includes a malloc function, it simply won't work.
NULL v. zero
Posted Jul 15, 2004 23:52 UTC (Thu) by dododge (subscriber, #2870) [Link]
The header inclusion issue is in C, not C++. The differences in the languages mean that there is no single way to call malloc that works well for both of them.
If you're writing C++ you have to cast malloc because the compiler won't like the implicit conversion. If you're writing C you shouldn't cast it, in order to force the compiler to warn you if there's no prototype in scope.
Where you can run into trouble is when you've got code or a programmer moving betwen the two languages.
NULL v. zero
Posted Jul 15, 2004 19:40 UTC (Thu) by Ross (subscriber, #4065) [Link]
Is it not strange for the language to use the lhs to determine how toevaluate the rhs? This always bothered me about C++. For example:
int bob;
void *nancy;
bob = NULL*NULL; // NULL is an integer here but a warning would be nicer
nancy = NULL*5; // So you say NULL is a pointer here but I don't actually believe it
NULL v. zero
Posted Jul 15, 2004 22:02 UTC (Thu) by sir99 (guest, #3286) [Link]
If NULL is defined as (void*)0, then neither of those is legal C++. It seems that gcc special-cases NULL so that it can be treated as both an integer and a pointer. Further, only an expression that evaluates to 0 at compile-time can be implicitly cast to a pointer; no other integer can be.AIUI, the lhs doesn't determine how the rhs is evaluated. The rhs is evaluated independently and then promoted to the type of the lhs.
NULL v. zero
Posted Jul 16, 2004 19:35 UTC (Fri) by Ross (subscriber, #4065) [Link]
"AIUI, the lhs doesn't determine how the rhs is evaluated. The rhs is evaluated independently and then promoted to the type of the lhs."That was my point, really. That's why NULL as (void *)0 is better than just
zero, and why C++'s insistance that 0 is better confuses me.