5

Reading about the integer promotion and integer conversion rank I found this link

  • 1.If both operands have the same type, then no further conversion is needed.

  • 2.Otherwise, if both operands have signed integer types or both have unsigned integer types, the operand with the type of lesser integer conversion rank is converted to the type of the operand with greater rank.

  • 3.Otherwise, if the operand that has unsigned integer type has rank greater or equal to the rank of the type of the other operand, then the operand with signed integer type is converted to the type of the operand with unsigned integer type.

  • 4.Otherwise, if the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, then the operand with unsigned integer type is converted to the type of the operand with signed integer type.

  • 5.Otherwise, both operands are converted to the unsigned integer type corresponding to the type of the operand with signed integer type.

The points 1 2 3 are totally clear but I still not come up with example for the case 4 and 5. Can someone provide please an example concerning any implementation ?

As I know the integer conversion rank is:

_Bool < char < short < int < long < long long int

Whatever the size of bytes related to the types are equal or higher. Right?

Concerning the promotion or conversion from one type to the other. Are the bits added to the lowest type zero or 1 or the left extreme bit has effect on that ?

I want to know how is the process in the bits view especially for conversion.

For the integer promotion it can always conserve the value and the sign without a doubt.

Community
  • 1
  • 1
rondino
  • 395
  • 2
  • 3
  • 10
  • 1
    It wouldn't make much sense in the *bits view*, as the bit pattern is mostly unchanged in integer promotions. – Eugene Sh. Aug 09 '16 at 15:23
  • 1
    they will be filled always with zero bits this is what you want to say and it is not implementation defined? @EugeneSh. – rondino Aug 09 '16 at 15:24
  • If that is from the standard (it is not), cite the paragraph, etc. Just linking some site is quite useless. That differs significantly from the standard. Also note that C standard is C11 only. – too honest for this site Aug 09 '16 at 15:35
  • 1
    @Olaf: As you have more knowledge about the standard than me you can give us the wrong parts of the site which are not conform to the standard. You can help us by that definitely. – rondino Aug 09 '16 at 15:46
  • I don't see it is my task to correct arbitrary sites on the internet. Just write the authors they should RTFStandard. – too honest for this site Aug 09 '16 at 16:52

1 Answers1

9

Case 4 applies if you have an unsigned type that is smaller in rank than the signed type it is operating with and they have different sizes. Case 5 then if the two are the same size.

For example, on my system int is 32-bit, long is 64-bit, and long long is 64-bit. If you then have the following:

unsigned int a;      // range: 0 to 4294967295
long b;              // range: -9223372036854775808 to 9223372036854775807

unsigned long c;     // range: 0 to 18446744073709551615
long long d;         // range: -9223372036854775808 to 9223372036854775807

For an expression involving a and b, which are unsigned int and long, any valid unsigned int can fit in a long. So a is converted to long in that situation.

Conversely, For an expression involving c and d, which are unsigned long and long long, a long long cannot hold all values of an unsigned long. So both operands are converted to unsigned long long.

Regarding what happens during a promotion / conversion on the bit level, let's first assume that the lower rank type is smaller than the higher rank type, and that signed types use 2's complement representation.

For a conversion from a 32 bit int to a 64 bit long, if the value is positive, 4 bytes containing all 0 bits are added on the left. If the value is negative, 4 bytes containing all 1 bits are added on the left. For example, the representation of value 5 changes from 0x00000005 to 0x0000000000000005. For the value -5, the representation changes from 0xfffffffb to 0xfffffffffffffffb.

dbush
  • 205,898
  • 23
  • 218
  • 273
  • 2
    For the second example it is the case 3. `if the operand that has unsigned integer type has rank greater or equal to the rank of the type of the other operand` you can see that ***equal*** is also included and `unsigned long` and `long` have the same conversion rank ! – rondino Aug 09 '16 at 15:27
  • 1
    Any type of lower conversion rank than `int` is irrelevant: C11 draft standard n1570: *6.3.1.8 Usual arithmetic conversions 1 [talk about floating point] Otherwise, the integer promotions are performed on both operands. Then the following rules are applied to the promoted operands:[...]* So by the time the common real type is to be determined, everything is `int` or higher. – EOF Aug 09 '16 at 15:33
  • I totally agree on that. first promotion then conversion. – rondino Aug 09 '16 at 15:35
  • 1
    @rondino I've corrected both cases to reflect the comments. – dbush Aug 09 '16 at 15:46
  • @dbush Thanks it answers ***a part of my question***. Your example treats very well both cases. (upvote) – rondino Aug 09 '16 at 16:08
  • @rondino I added a part regarding the change in representation during conversion. – dbush Aug 09 '16 at 16:24
  • @dbush your explanation doesn't applies on `=` right ? – rondino Aug 10 '16 at 19:37
  • 1
    @rondino Correct. For assignment, the right side is converted to the type of the left side for assignment, and the type of the assignment expression is the type of the left side. – dbush Aug 10 '16 at 19:40
  • Exactly because there are also other rules for signed and unsigned integers. I wanted to check :). Thanks a lot ! – rondino Aug 10 '16 at 19:43