title: When is an integer<->pointer cast actually correct?
body: <p>The common folklore says that:</p>
  
  <ul>
  <li><p>The type system exists for a reason. Integers and pointers are distinct types, casting between them is a malpractice in the majority of cases, may indicate a design error and should be avoided.</p></li>
  <li><p>Even when such a cast is performed, no assumptions shall be made about the size of integers and pointers (casting <code>void*</code> to <code>int</code> is the simplest way to make the code fail on x64), and instead of <code>int</code> one should use <code>intptr_t</code> or <code>uintptr_t</code> from <code>stdint.h</code>.</p></li>
  </ul>
  
  <p>Knowing that, <strong>when is it actually useful</strong> to perform such casts?  </p>
  
  <p><em>(Note: having a bit shorter code for the price of portability doesn't count as "actually useful".)</em></p>
  
  <hr>
  
  <p>One case I know:</p>
  
  <ul>
  <li>Some <strong>lock-free multiprocessor algorithms</strong> exploit the fact that a 2+-byte-alligned pointer has some redundancy. They then use the lowest bits of the pointer as boolean flags, for instance. With a processor having an appropriate instruction set, this may eliminate the need for a locking mechanism (which would be necessary if the pointer and the boolean flag were separate).<br>
  <em>(Note: This practice is even possible to do safely in Java via java.util.concurrent.atomic.AtomicMarkableReference)</em></li>
  </ul>
  
  <p>Anything more?</p>