title: Is casting uint8_t to signed int at least sometimes incorrect?
body: <p>While reading the answer to the following question</p>
  
  <p><a href="https://stackoverflow.com/questions/7639656/getting-a-buffer-into-a-stringstream-in-hex-representation">Getting a buffer into a stringstream in hex representation:</a></p>
  
  <p>I did not understand why there is a necessity to cast <code>uint8_t</code> to <code>unsigned</code> (or, as written in comments, even to <code>unsigned char</code> before that), while casting just to <code>int</code> is incorrect.</p>
  
  <p>As I understand, no conversions at all would lead to interpreting <code>uint8_t</code> as an underlying type which can (must?) be some of 3 <code>char</code> variations and thus printing it as a character.</p>
  
  <p>But what's wrong with casting to <code>int</code>? Any <code>uint8_t</code> value should always fit in <code>int</code>, so the conversion seems to be straightforward. Why sign-extension would make the code incorrect (mentioned in comments)?</p>
  
  <p><strong>UPD</strong>:</p>
  
  <p>Just for reference, I figured what was talked about in the question I referred to is a case for <code>signed char</code>:</p>
  
  <pre><code>signed char num = -1;
  std::cout &lt;&lt; std::hex &lt;&lt; static_cast&lt;unsigned int&gt;(static_cast&lt;unsigned char&gt;(num));
  </code></pre>
  
  <p>This would be written as more than 2 <code>f</code>s in absence of the second cast.</p>
  
  <p>The point about 2's complement system seems to be incorrect though, as an integral conversion should apply to convert -1 to <code>unsigned &lt;smth&gt;</code>, and it adheres to the 2's complement system (i.e. when converting to e.g. <code>uint8_t</code> the result should always be 255 and thus be printed as <code>0xff</code>, even having a different bit pattern).</p>