title: Does the C99 standard guaranteed the binary representation of unsigned int?
body: <h2>C99 (ISO/IEC 9899:1999)</h2>
  <blockquote>
  <h3>6.2.6.2/1 Integer types</h3>
  <p>The values of any padding bits are unspeciﬁed.<sup>45)</sup> A valid
  (non-trap) object representation of a signed integer type where the
  sign bit is zero is a valid object representation of the corresponding
  unsigned type, and shall represent the same value.</p>
  <p><strong>For any integer
  type, the object representation where all the bits are zero shall be a
  representation of the value zero in that type.</strong></p>
  </blockquote>
  <p>In the C99 standard, an integer type where all the bits are zero is guaranteed to represent the value <code>0</code> in that respective type. However, does this guarantee that the underlying binary value is what we expect it to be?</p>
  <p>For example:</p>
  <pre><code>unsigned x = 42;
  </code></pre>
  <p>We'd normally expect a machine to store this decimal <code>42</code> value in memory as the binary <code>101010</code> value.</p>
  <p>However, could some eccentric machine architecture store the same decimal <code>42</code> value as the binary <code>011011</code> value (not necessarily for a practical reason but simply because it can)?</p>
  <p>If so, consider the following code utilizing a right shift operation:</p>
  <pre><code>unsigned y = x&gt;&gt;1;    /* 101010&gt;&gt;1 or 011011&gt;&gt;1 */
  </code></pre>
  <p>Would <code>y</code> hold the decimal value <code>21</code> (<code>10101</code> in binary), or the decimal value <code>13</code> (<code>01101</code> in binary)?</p>
  <p>Does the C99 standard make any guarantee about the decimal representation of an unsigned integer type after a bitwise operation -- e.g. is a right shift guaranteed to be equivalent to an integer division by <code>2</code> on all machine architectures?</p>