Why, warning: comparison between signed and unsigned integer expressions?

On 05/31/2012 01:09 PM, Joe Pfeiffer wrote:
> Ike Naar <ike@iceland.freeshell.org> writes:
>
>> On 2012-05-31, Lox <skolpojken72@yahoo.se> wrote:
>>> Sorry, two typos (wrote to fast). :-P
>>>
>>> uint32_t x;
>>> uint8_t y;
>>>
>>> x = 255;
>>> y = x + UINT8_C(1);
>>>
>>> y is 256 and not 0 as one would think (if assuming 8 bit
>>> calculations).
>>
>> Again, y can only hold values from 0 to 255 inclusive,
>> so it cannot be 256. How did you come to that conclusion?
>> Can you show the code?
>
> If I'm reading the standard correctly, an unsigned char is large
> enough to hold values from 0 to 255 (actually "any member of the basic
> execution character set"). ...

Actually, the key requirement is that UCHAR_MAX >= 255 (5.2.4.2.1p1).

> ... It doesn't say that it can't be larger than
> that.

While that's all perfectly true, it's not relevant. The type used in
this example was uint8_t, not char. uint8_t is required by the standard
to have exactly 8 values bits, no more, and no less; and no padding bits
(7.20.1.1p2). On any implementation where uint8_t can be implemented,
it's likely (but not required) to be the same type as unsigned char.
However, uint8_t is an optional type, for precisely the reason that it
cannot be implemented as specified on any implementation where CHAR_BIT > 8.

James Kuyper <jameskuyper@verizon.net> writes:

> On 05/31/2012 01:09 PM, Joe Pfeiffer wrote:
>> Ike Naar <ike@iceland.freeshell.org> writes:
>>
>>> On 2012-05-31, Lox <skolpojken72@yahoo.se> wrote:
>>>> Sorry, two typos (wrote to fast). :-P
>>>>
>>>> uint32_t x;
>>>> uint8_t y;
>>>>
>>>> x = 255;
>>>> y = x + UINT8_C(1);
>>>>
>>>> y is 256 and not 0 as one would think (if assuming 8 bit
>>>> calculations).
>>>
>>> Again, y can only hold values from 0 to 255 inclusive,
>>> so it cannot be 256. How did you come to that conclusion?
>>> Can you show the code?
>>
>> If I'm reading the standard correctly, an unsigned char is large
>> enough to hold values from 0 to 255 (actually "any member of the basic
>> execution character set"). ...
>
> Actually, the key requirement is that UCHAR_MAX >= 255 (5.2.4.2.1p1).
>
>> ... It doesn't say that it can't be larger than
>> that.
>
> While that's all perfectly true, it's not relevant. The type used in
> this example was uint8_t, not char. uint8_t is required by the standard
> to have exactly 8 values bits, no more, and no less; and no padding bits
> (7.20.1.1p2). On any implementation where uint8_t can be implemented,
> it's likely (but not required) to be the same type as unsigned char.
> However, uint8_t is an optional type, for precisely the reason that it
> cannot be implemented as specified on any implementation where CHAR_BIT > 8.

Ah. I was looking for the string uint8_t in the standard and not
finding it... You are correct.