Re: Confusion about integer promotions.

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


"John Carson" <jcarson_n_o_sp_am_@xxxxxxxxxxxxxxx> wrote in message
news:OiWrMp$bFHA.3184@xxxxxxxxxxxxxxxxxxxxxxx
> "BigMan" <fn42551@xxxxxxxxxxxxxxxx> wrote in message
> news:OHANMG$bFHA.2984@xxxxxxxxxxxxxxxxxxxx
>> Let's consider this piece of code:
>>
>> unsigned short A = 0;
>> unsigned int B = 0;
>> signed int C = 0;
>>
>> // For each of these line, should A be promoted to int or to unsigned
>> int according to the C++ standard if an int can represent all the
>> values of an unsigned short?
>>
>> bool d = A < B;
>> bool e = A < C;
>
> Section 4.5/1 of the C++ standard:
>
> "An rvalue of type char, signed char, unsigned char, short int, or
> unsigned short int can be converted to an rvalue of type int if int can
> represent all the values of the source type; otherwise, the source rvalue
> can be converted to an rvalue of type unsigned int."
>
> i.e., promotion is always to the signed version if it is large enough,
> otherwise to the unsigned version.
>
> Mixing signed and unsigned integers is very hazardous. I have been bitten
> by it more than once and avoid such situations if at all possible.
>
> --
> John Carson

First, signed int is large enough on x86 (4 bytes) to hold all values of an
unsigned short (2 bytes), so values of the latter type should be promoted to
signed int and not to unsigned int. But VC++.NET seem to promote unsigned
short either to signed int or to unsigned int regardless of what 4.5/1 says,
since it does not issue a singed/unsigned mismatch warning when compiling
the above code with the /W4 switch (highest warning level). Is this
non-conformant behaviour or what?

Second, using only unsigned integers (but of different types) is also
hazardous, since an unsigned short or unsigned char may be promoted to
signed int, which again leads to mixing signed and unsigned integers.
Probably, a more generic rule should read something like: "Do not mix
integers of different types", where signedness should also be taken into
account.

Could you, please, mention some of the problems you have come upon when
mixing signed and unsigned integers?


.

Relevant Pages

  • Re: A generic interface for numeric variables
    ... int and long, ... unsigned char uc = UCHAR_MAX; ... For printing values, you can use a table of format strings, indexed by the type tag of a variable. ... However, if the limit check is built-in to set_variable (which will itself deal with signedness), then increment can be just: ...
    (comp.lang.c)
  • Re: Linux / NASM equivalent of Iczelions Win32 assembly tuts
    ... _explicitly_ state int is signed. ... Size and signedness are unrelated ... if the architecture only supports unsigned types? ... terms of characters and character pointers - if you wish or need be - to be ...
    (alt.lang.asm)
  • Re: why display is ffffff82 instead of 82 ??
    ... > but after i use the following commands, the last byte 82 is displayed as ... char is a signed integer type. ... Casting to int retains this ... signedness and extends the sign-bit into all available "negativity" ...
    (comp.lang.cpp)
  • Re: Bit-fields vs integral promotions
    ... State of the Standard, which I think boils down to "nobody seems ... to plain, i.e., signed, int, I think the rule should apply only to ... apply to bitfields as well, since the signedness of bitfields is ...
    (comp.lang.c)
  • Re: How could a char be signed?
    ... one or another of either signed char or unsigned char, ... It is not always the case that a plain char ... whether a plain int bit field is signed int or unsigned int. ... I can think of to make the signedness implementation-defined is to ...
    (comp.lang.c)