title: NULL equals 0 in C, so should I treat both values like a nil?
body: <p>Afaik <code>NULL</code> can be (or really is, at least in my <code>stdlib</code> implementation) <code>#define</code>'d as:</p>
  
  <pre><code>#define NULL ((void*)0)
  </code></pre>
  
  <p>also, <a href="https://stackoverflow.com/a/924683/668125">https://stackoverflow.com/a/924683/668125</a> states that in C++ NULL is transparently cast to/from <code>((int)0)</code> (which is the reason to use <code>std::nullptr</code> in C++ instead, since that has a real nil type/value pair thanks to the <code>nullptr_t</code> opaque typedef).</p>
  
  <p>So, I'm currently developing a LuaJIT library and want to provide a helper function to check if a value is <code>nil</code>/<code>NULL</code>/whatever (=a value <em>meaning</em> <code>nil</code> but maybe not of type <code>nil</code>).</p>
  
  <p>currently, that's:</p>
  
  <pre><code>function ffi.nil(value)
    return value==nil or value==ffi.NULL
  end
  </code></pre>
  
  <p>but, a <code>(NULL==0)</code> in C would be true, as verified by this snippet printing <code>true</code> on my system:</p>
  
  <pre><code>#include &lt;stdio.h&gt;
  #include &lt;stdlib.h&gt;
  void main(void){
    if(NULL==0)
      printf("true\n");
    else
      printf("false\n");
  }
  </code></pre>
  
  <p>so should I go for this definition of a "<code>nil</code> meaning value" instead?</p>
  
  <pre><code>function ffi.nil(value)
    return value==nil or value==ffi.NULL or value==0
  end
  </code></pre>
  
  <p><strong>TL;DR:</strong> in C, <code>NULL</code> is equal to <code>0</code>, while in LuaJIT's FFI, no two pairs of <code>nil, ffi.NULL, 0</code> are equal; so when defining what value should be considered a "<code>nil</code> like value" when dealing with 3rd party C libs, shall I include <code>0</code> or only <code>nil or ffi.NULL</code>?</p>
  
  <p>Disclaimer: I'm afraid this might be considered an "opinion based question", so, in that case, I'll refine the question: Which behavior would more likely produce correct result, ignoring the fact that it could be considered good or bad style (so yes, if it's bad style but this particular style flaw is consistent between >50% of common libs, it's the way I'll have to do it)?</p>