title: Does an observable difference exist using `unsigned long` and `unsigned int` in C (or C++) when both are 32 bits wide?
body: <p>I'm using an MPC56XX (embedded systems) with a compiler for which an <code>int</code> and a <code>long</code> are both 32 bits wide.</p>
  
  <p>In a required software package we had the following definitions for 32-bit wide types:</p>
  
  <pre><code>typedef   signed int sint32;
  typedef unsigned int uint32;
  </code></pre>
  
  <p>In a new release this was changed without much documentation to:</p>
  
  <pre><code>typedef   signed long sint32;
  typedef unsigned long uint32;
  </code></pre>
  
  <p>I can see why this would be a good thing: Integers have a conversion rank between <code>short</code> and <code>long</code>, so theoretically extra conversions can apply when using the first set of definitions.</p>
  
  <p>My question: Given the above change forced upon us by the package authors, is there a situation imaginable where such a change would change the compiled code, correctly leading to a different result?</p>
  
  <p>I'm familiar with the "usual unary conversions" and the "usual binary conversions", but I have a hard time coming up with a concrete situation where this could really ruin my existing code. But is it really irrelevant?</p>
  
  <p>I'm currently working in a pure C environment, using C89/C94, but I'd be interested in both C and C++ issues.</p>
  
  <p>EDIT: I know that mixing <code>int</code> with <code>sint32</code> may produce different results when it's redefined. But we're not allowed to use the original C types directly, only the typedef'ed ones.<br>
  I'm looking for a sample (expression or snippet) using constants, unary/binary operators, casts, etc. with a different but correct compilation result based on the changed type definition.</p>