6

For example, If I have,

 int a = 42;
 unsigned b = 10;
 int c = a + b;

For this statement, int c = a + b; Would a be first converted to an unsigned int or would it be b that will be converted to a signed int? Both unsigned int and signed have the same conversion rank so how do we know which one will be converted? Is there a Standard rule?

user963241
  • 6,758
  • 19
  • 65
  • 93
  • possible duplicate of [Signed to unsigned conversion in C - is it always safe?](http://stackoverflow.com/questions/50605/signed-to-unsigned-conversion-in-c-is-it-always-safe) – Jay Nov 30 '12 at 04:46
  • @Jay: This is not a duplicate of that; this question asks what the rules are for selecting conversions, while that question asks whether a signed to unsigned conversion is safe. – Eric Postpischil Nov 30 '12 at 04:50

1 Answers1

10

Short answer: Per C99 6.3.1.8-p1, as value will be converted to an unsigned int by, per C99 6.3.1.3-p2, having UINT_MAX+1 added to it until it falls in the range allowed by unsigned int. Since it is already in that range, no addition will be performed. By C99 6.3.1.3-p3, the results assigned back to int c would be implementation defined if (p1) and (p2) didn't apply. But in this case note the "value" clause of 6.3.1.3-p1. The value (52) in this case can be represented by int, so it is not changed, and is defined.

C99 6.3.1.3 Signed and unsigned integers

  1. When a value with integer type is converted to another integer type other than _Bool, if the value can be represented by the new type, it is unchanged.

  2. Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type.60)

  3. Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation-defined signal is raised.

C99 6.3.1.8 Usual arithmetic conversions

Many operators that expect operands of arithmetic type cause conversions and yield result types in a similar way. The purpose is to determine a common real type for the operands and result. For the specified operands, each operand is converted, without change of type domain, to a type whose corresponding real type is the common real type. Unless explicitly stated otherwise, the common real type is also the corresponding real type of the result, whose type domain is the type domain of the operands if they are the same, and complex otherwise. This pattern is called the usual arithmetic conversions:

First, if the corresponding real type of either operand is long double, the other operand is converted, without change of type domain, to a type whose corresponding real type is long double.

Otherwise, if the corresponding real type of either operand is double, the other operand is converted, without change of type domain, to a type whose corresponding real type is double.

Otherwise, if the corresponding real type of either operand is float, the other operand is converted, without change of type domain, to a type whose corresponding real type is float.62)

Otherwise, the integer promotions are performed on both operands. Then the following rules are applied to the promoted operands:

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

  • 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.

  • 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.

  • 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.

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

WhozCraig
  • 65,258
  • 11
  • 75
  • 141
  • In general, the result of converting to signed may be implementation defined. In this specific case, it is defined, since the value of the right-hand side, 52, is representable as an `int`. – Eric Postpischil Nov 30 '12 at 04:57
  • @EricPostpischil yessir. I just remembered that and was updating about the same time you posted this. I'm only familiar with that section of the standard because of [this recent answer](http://stackoverflow.com/questions/13600991/why-is-a-negative-int-greater-than-unsigned-int/13601259#13601259) to another question. – WhozCraig Nov 30 '12 at 04:58
  • @EricPostpischil: Unfortunately, the user deleted his answer to this question while I was reading your comment on that. Can you please post it as an answer or comment? – user963241 Nov 30 '12 at 05:03
  • @user963241: this answer appears sufficient; I do not mind if you accept it, unless you need additional clarification. – Eric Postpischil Nov 30 '12 at 10:31
  • @WhozCraig: What about the second paragraph from **C99 6.3.1.8-p1**? It says an `unsigned int` type is converted to `signed int` if it's value can represented by `signed int` type but this never happened in this case. Why did we choose the first paragraph in this case? – user963241 Nov 30 '12 at 21:13
  • @user963241 because they're presented in order of precedence. If the first paragraph did not *apply* to this prospect conversion, it would have been skipped and the second paragraph would be the fallback. There is actually at least one case in the standard before the first one presented here (note the ...Otherwise) but I didn't bother showing it because it was not qualified for a prospect conversion in this particular case. I could update the answer to show *all* of them if you desire. – WhozCraig Nov 30 '12 at 21:23
  • @WhozCraig: Yes please, it would be great if you can show them. I'm thinking about the case where `unsigned` type is converted `signed` type to be something like where we have `unsigned short s = 42;` and `int i = 10`. So, when `int c = s + i` happens, `s` is converted to `signed` type. – user963241 Nov 30 '12 at 21:48
  • @user963241 I'll update to include them all. I'll also refer you to [this answer](http://stackoverflow.com/questions/13600991/why-is-a-negative-int-greater-than-unsigned-int/13601259#13601259) to a question dealing with the very thing you're talking about. It is fresh in my head only because I wrote it a day before I answered your question. Pay particular attention to the last part of the answer and the test program's comparison of an `unsigned char` and a `signed int`. – WhozCraig Nov 30 '12 at 21:53
  • 1
    @WhozCraig: What is required with regard to "implementation defined"? For example, could a conforming implementation explicitly specify that the effect of setting an `signed char` to a value outside the range -128 to +127 will be a value whose lower bits will be correct and whose upper bits could vary arbitrarily, or would an implementation required to do something consistent with the upper bits? – supercat Jan 01 '13 at 05:53
  • 1
    @WhozCraig: My understanding of "implementation defined" at least in earlier versions of the spec was that implementations were supposed to be consistent, but requiring a compiler to perform out-of-bounds conversions consistently could impair performance. Consider `shortVar = uvar1 + uvar2;`. If `shortVar` is in RAM, such a statement would naturally lop off the upper bits, but if it's in a register, having it lop off the upper bits may require an extra couple instructions. Would a standards-conforming compiler be required to add such instructions? – supercat Jan 01 '13 at 05:57
  • @supercat I've up-ticked both of those comments because I honestly don't know the answer without doing some homework on the matter. I find it interesting how 6.3.1.3-p3 decides the **type** is signed *and* the value cannot be held within it. Thus, implementation-defined, and the standard does not specify the resulting value. In my understanding, this means the standard makes no warrants on the value represented. Therefore neither can your code. I see no reason a standards-conforming compiler should meet any bar in this case whatsoever beyond designation of the signed-ness of the type. – WhozCraig Jan 01 '13 at 07:16