title: Different results between a 16-bit int machine and a 32-bit int machine in a subtraction
body: <p>When the code below is run against a 16-bit integer machine like MSP430 micro controller, <code>s32</code> yields 65446</p>
  
  <pre><code>#include &lt;stdint.h&gt;
  
  uint16_t   u16c;
  int32_t    s32;
  
  int main()
  {
      u16c = 100U;
      s32  = 10 - u16c;
  }
  </code></pre>
  
  <p>My understanding is that <code>10 - u16c</code> gets implicit type promotion to unsigned int.  Mathematically <code>10 - u16c</code> equals to -90.  But how is it possible to represent a negative number as an unsigned int?</p>
  
  <p>When -90 gets promoted to unsigned int, does it mean that the sign of a number is ignored?  </p>
  
  <p>Lets suppose, the sign of a number is ignored.<br>
  The binary representation of 90 is <code>00000000 01011010</code>.
  When this gets assigned to <code>s32</code> which is 32-bit wide signed integer variable,
  how does the transformation take place?</p>
  
  <p>In order for <code>s32</code> equal to 65446,  90 has to take 2's complement.
  That would be <code>00000000 10100110</code>.  </p>
  
  <p>I  am not confident in understand the process of <code>s32</code> becoming 65446.</p>
  
  <p>In a 32-bit wide integer machine like ARM CORTEX, <code>s32</code> is -90, which is correct.</p>
  
  <p>To fix this situation in 16-bit integer machine, there needs a typecast of <code>(int16_t)</code> for <code>u16c</code>.  How does this remedy this problem?</p>
  
  <p>Added hexa data representation of <code>s32</code> as shown from IAR Workbench (Lower right corner).
  It is shown that <code>s32</code> becomes <code>0x0000FFA6</code>.
  So for MSP430, the machine implementation of converting from unsigned 16 bit to signed 32 bit, it simply prepends 16 0's bits.</p>
  
  <p><a href="https://i.stack.imgur.com/qIQ3r.jpg" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/qIQ3r.jpg" alt="enter image description here"></a></p>