FrozenNULL


int a = NULL + 5;
printf("%d\n", a);


Prints 5, therefore NULL is #defineD to 0.

NULL is #defineD to 0.
WHY THANK YOU, I DID NOT KNOW THAT. THAT IS A VERY USEFUL PIECE OF INFORMATION. ALSO NO EXCEPTIONS.

>>1,2
Actually, the value of NULL is implementation specific. That's why you should test a pointer with if (ptr == NULL) or if (!ptr), rather than if (ptr == 0).

>>3
It's okay to use if (ptr == 0) because the integer literal "0", according to the C spec, will always be converted to NULL (when cast to a pointer type), no matter what the actual representation of NULL is.  (And the "==" operator will perform that implicit cast.)  Using 0 instead of NULL is slightly more portable, for those people who insist upon targeting the moronic broken platforms where NULL (the macro) doesn't work quite right or doesn't appear in the right header.

It is also legal to have a platform where (void *)0 is NULL for pointers to data, but broken for pointers to functions.

That said,


test.c:4:6: warning: incompatible pointer to integer conversion initializing
      'void *', expected 'int' [-pedantic]
        int a = NULL + 5;
            ^   ~~~~~~~~

...==0

Always better written as !....

Everyone says NULL is a mistake but I personally appreciate it because I understand that it's not the thing at fault.  The problem of "an object does not exist here" is daunting to get around.  It's no different from saying any object that does not exist when requested is equatable to numeric 0 or the array escape character /0 - we'd just have to deal with ZeroPointerExceptions and other such language-specific nonsense.

In the end, you can not get around having to make some kind of manual check every now and then.

...==compile-time-constant is always better written as
compile-time-constant == ...

>>7
Maybe, but I don't see two measly spaces as a matter of importance.

>>7
Come on now. Any compiler would pick up the former example.

>>7
(I assume) he's saying that putting the constant expression first is less error prone.  Because if you write this accidentally:

  if (x = 5)
it will compile and you'll just get incorrect behavior, but if you write this accidentally:

  if (5 = x)
it won't compile.  I work with a guy who does this and it drives me nuts.  I guess the argument is sound, but I think it looks shitty.