title: Is dereferencing a pointer that's equal to nullptr undefined behavior by the standard?
body: <p>An blog author has brought up the discussion about null pointer dereferecing:</p>
  
  <ul>
  <li><a href="http://www.viva64.com/en/b/0306/" rel="noreferrer">http://www.viva64.com/en/b/0306/</a></li>
  </ul>
  
  <p>I've put some counter arguments here:</p>
  
  <ul>
  <li><a href="http://bit.ly/1L98GL4" rel="noreferrer">http://bit.ly/1L98GL4</a></li>
  </ul>
  
  <p>His main line of reasoning quoting the standard is this:</p>
  
  <blockquote>
    <p>The '&amp;podhd->line6' expression is undefined behavior in the C language
    when 'podhd' is a null pointer.</p>
    
    <p>The C99 standard says the following about the '&amp;' address-of operator
    (6.5.3.2 "Address and indirection operators"):</p>
    
    <p>The operand of the unary &amp; operator shall be either a function
    designator, the result of a [] or unary * operator, or an lvalue that
    designates an object that is not a bit-field and is not declared with
    the register storage-class specifier.</p>
    
    <p>The expression 'podhd->line6' is clearly not a function designator,
    the result of a [] or * operator. It is an lvalue expression. However,
    when the 'podhd' pointer is NULL, the expression does not designate an
    object since 6.3.2.3 "Pointers" says:</p>
    
    <p>If a null pointer constant is converted to a pointer type, the
    resulting pointer, called a null pointer, is guaranteed to compare
    unequal to a pointer to any object or function.</p>
    
    <p>When "an lvalue does not designate an object when it is evaluated, the
    behavior is undefined" (C99 6.3.2.1 "Lvalues, arrays, and function
    designators"):</p>
    
    <p>An lvalue is an expression with an object type or an incomplete type
    other than void; if an lvalue does not designate an object when it is
    evaluated, the behavior is undefined.</p>
    
    <p>So, the same idea in brief:</p>
    
    <p>When -> was executed on the pointer, it evaluated to an lvalue where
    no object exists, and as a result the behavior is undefined.</p>
  </blockquote>
  
  <p>This question is purely language based, I'm not asking regarding whether a given system allows one to tamper with what lies at address 0 in any language.</p>
  
  <p>As far as I can see, there's no restriction in dereferencing a pointer variable whose value is equal to <code>nullptr</code>, even thought comparisons of a pointer against the <code>nullptr</code> (or <code>(void *) 0</code>) constant can vanish in optimizations in certain situations because of the stated paragraphs, but this looks like another issue, it doesn't prevent dereferencing a pointer whose value is equal to <code>nullptr</code>. Notice that I've checked other SO questions and answers, I particularly <a href="https://stackoverflow.com/a/26919197/1000282">like this set of quotations</a>, as well as the standard quotes above, and I didn't stumbled upon something that clearly infers from standard that if a pointer <code>ptr</code> compares equal to <code>nullptr</code>, dereferencing it would be undefined behavior.</p>
  
  <p>At most what I get is that deferencing <em>the constant</em> (or its cast to any pointer type) is what is UB, but nothing saying about a variable that's bit equal to the value that comes up from <code>nullptr</code>.</p>
  
  <p>I'd like to clearly separate the <code>nullptr</code> constant from a pointer variable that holds a value equals to it. But an answer that address both cases is ideal.</p>
  
  <p>I do realise that optimizations can quick in when there're comparisons against <code>nullptr</code>, etc and may simply strip code based on that.</p>
  
  <p>If the conclusion is that, if <code>ptr</code> equals to the value of <code>nullptr</code> dereferencing it is definitely UB, another question follows:</p>
  
  <p><a href="https://stackoverflow.com/q/28574069/1000282">Do C and C++ standards imply that a special value in the address space must exist solely to represent the value of null pointers?</a></p>