C语言中NULL，就是个概念本身并没有什么，其定义为宏: #define NULL ((void*)0)。。。很多人会产生误解，以为NULL就是0，其实完全可以自己定义NULL，你定义为1或者其他任何整数（不于系统地址冲突）都行，NULL只是个空的概念，，，所以大家在进行控制指针判断时，不要写 !p 之类的判断语句，一定要老老实实的写 p == NULL

C标准规定NULL的定义只能是两种：0或者(void*)0。你把NULL重定义为1，那就是你违反了标准。使用!p判断指针非空完全符合标准。

多谢楼主开贴拓展这个概念。但是#define NULL ((void*)0)里面的((void*)0)看不懂

如果只是 C 就算了，但放在更一般的背景下这种习惯是个错误示范。
最直接的理由是，因为很多 C 代码同时会被当作 C++ 代码复用（通过预处理器控制），而在 C++ 下，这里的惯用法就有些问题了。
C++ 中，像 if 这样的上下文专门引入 contextually convert to bool 来描述，这是一个语言层面上一等的机制，独立于整数表示的含义的判断。虽然这个 wording 是 C++11 加入的，根本问题是 C++ 原生支持具有特定用途的 bool ，而不是 C99 这样加补丁搞的 _Bool ，并没法让 if 依赖。虽然 C++ 这样做的必要性还有跟 explicit 之类搞事的问题，但
原则上 C 缺乏 bool 而让整数越俎代庖开洞是个过时的设计，据此不得不依赖 == 来判断条件，在有其它选择的情形下也不是一个好习惯。
使用 NULL 至少对兼容 C++ 的代码还有其它显然的问题，例如 -Wzero-as-null-pointer-constant 。这种情况下就算非要用显式的空指针，也应该用字面量 nullptr 而不是 NULL 。注意 C++ 虽然一直支持 NULL ，但一直以来都和 C 略有区别——允许是 0 或者 0L 而禁止(void*)0 。这个限制和类型检查的强度有关（考虑 char* p = NULL; ），再次暴露了 C 设计在这里的无能（虽然讽刺的是，C++ 引入 nullptr 的一个原因是 0 或 0L 的类型干扰重载）。

依赖整数类型 bool 的习惯在工业界还有一些更加作死的例子。可能很多人会遇到的，Win32 的 BOOL 导致莫名其妙的“性能警告”，需要显式转换或者比较判断来解决。从错误的源头来讲，引入比较在逻辑上也是说不通的。
这种流毒还会在莫名其妙的地方生效。一个很多人大概都不知道的例子是，CLR 底层的 bool 实际上类似伪劣的 BOOL ，而 C# 这种真正的 bool 的语言因为支持互操作，结果会引起在 bool 外能表示的值……这种情况在 C++ 直接是未定义行为，但在 C# 就强行是文档 bug 了，即便 C# 的 spec 根本没打算允许在 safe 代码中出现这种实质上的未定义行为（Roslyn 大概就是实现开洞处理，等效当作未定义行为）。

谈严格的C语言标准的没有多大意义，，，C语言没有将NULL在语法上实现，也没有在语法上实现BOOL，就是为了让编程更加灵活，，，
比如我的一个项目，为了统一性（大型项目统一性十分重要，当然我举的这个例子很极端），我将0做其他作用，并不代表就是BOOL的假，或者NULL，我就要重新定义BOOL的FALSE，TRUE和NULL，如果C语言在语法上写死，反而就不能这么灵活了

很多时候感觉这就也是C语言故意不写死，就是要让用户自己去定义，自己去扩展的。。。毕竟在语法上强制写死NULL，BOOLEAN等等是很容易的事情。。。。毕竟就算是不少库中，NULL的定义也是类似这样写的
#ifndef NULL
#define NULL ((void *)0)
#endif

你要非得重新define一下从语法上讲也没毛病 从行为上说你是小项目坑自己大项目坑队友 专坑自己人系列 你信不信当你队友发现你对Null重新定义后 他手边就会放把菜刀？！