StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>To understand why <code>buffer[0] == 0xef</code> triggers a warning, and <code>buffer[0] == 0xffffffef</code> does not, you need to understand exactly what's happening in that expression.</p> <p>Firstly, the <code>==</code> operator compares the <em>value</em> of two expressions, not the underlying representation - <code>0xef</code> is the number 239, and will only compare equal to that number; likewise <code>0xffffffef</code> is the number 4294967279 and will only compare equal to that.</p> <p>There is no difference between the constants <code>0xef</code> and <code>239</code> in C: both have type <code>int</code> and the same value. If your <code>char</code> has the range -128 to 127, then when you evaluate <code>buffer[0] == 0xef</code> the <code>buffer[0]</code> is promoted to <code>int</code>, which leaves its value unchanged. It can therefore never compare equal to <code>0xef</code>, so the warning is correct.</p> <p>However, there <em>is</em> potentially a difference between the constants <code>0xffffffef</code> and 4294967279; decimal constants are always signed, but hexadecimal constant may be unsigned. On your system, it appears to have an unsigned type - probably <code>unsigned int</code> (because the value is too large to store in an <code>int</code>, but small enough to store in an <code>unsigned int</code>). When you evaluate <code>buffer[0] == 0xffffffef</code>, the <code>buffer[0]</code> is promoted to <code>unsigned int</code>. This leaves any positive value unchanged, but negative values are converted by adding <code>UINT_MAX + 1</code> to them; with a <code>char</code> that has range -128 to 127, the promoted values are in either of the ranges 0 to 127 or 4294967168 to 4294967295. <code>0xffffffef</code> lies within this range, so it is possible for the comparison to return true.</p> <hr> <p>If you are storing bit patterns rather than numbers, then you should be using <code>unsigned char</code> in the first place. Alternatively, you may inspect the bit pattern of an object by casting a pointer to it to <code>unsigned char *</code>:</p> <pre><code>if (((unsigned char *)buffer)[0] == 0xef) </code></pre> <p>(This is obviously more conveniently done by using a separate variable of type <code>unsigned char *</code>).</p> <p>As <a href="https://stackoverflow.com/questions/6647100/how-do-i-represent-negative-char-values-in-hexadecimal/6647126#6647126">PaulR</a> says, you can also use <code>buffer[0] == '\xef'</code> - this works because <code>'\xef'</code> is defined to be an <code>int</code> constant with the value that a <code>char</code> object with the bit pattern 0xef would have when converted to an int; eg. on a 2s complement system with signed chars, <code>'\xef'</code> is a constant with the value -17.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload