| |||||||||||
NULL v. zeroNULL v. zeroPosted Jul 15, 2004 13:34 UTC (Thu) by elanthis (subscriber, #6227)In reply to: NULL v. zero by ikm Parent article: NULL v. zero The C compiler and standards will accept a lot of things that are garbage, in all honesty. Just because a NULL pointer is just 0 is really nothing more than an implementation detail. It's also an artifact of C's weak type checking, which is one argument people often use in favor of C++, Java, C#, etc. A code checker like Sparse will often enforce a stricter dialect than standard C, which is a good thing, because then it will find errors that the normal C compiler wouldn't pick up. Correct type checking is one such error. It also does improve readability. If you are skimming through some code, and see: if (var == 0) { ... } You are likely to assume var is an integer, no? However, if you see: if (var == NULL) { ... } You are likely to assume var is a pointer, yes? Using the appropriate type makes the code easier to read and understand.
(Log in to post comments)
NULL v. zero Posted Jul 15, 2004 15:41 UTC (Thu) by ikm (subscriber, #493) [Link] 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.
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 So in C++ the nil pointer is 0 (they are very adamant about this).
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; 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
|
|||||||||||