------- Comment #8 from roberto dot gordo at gmail dot com 2007-03-14 12:29 ------- I'm still unable to match the behavior of gcc with the ISO C standard. I will try to explain myself.
The reason for which gcc produces different results with hex constants is now clear. Also, in the following quotation: "The result of the unary - operator is the negative of its (promoted) operand. The integer promotions are performed on the operand, and the result has the promoted type." I acknowledge that I've failed to note that given this code long long ll; ll = -0x80000000; the operand for the unary - operator is promoted first, and the operation is done next. The result may fit on an int, but according to the standard, the result has the promoted type (which has been already calculated as unsigned). BUT.. you said > Integer promotion is only performed on types smaller than int. and I would want to comment on this. I do not claim to have good understanding of English, so I may be interpreting the ISO C standard on a wrong way. Before reopening the bug, I would appreciate comments on this. This are the relevant parts: Section: Conversions -> Arithmetic operands -> Boolean, characters, and integers "The following may be used in an expression wherever an int or unsigned int may be used: - An object or expression with an integer type whose integer conversion rank is less than or equal to the rank of int and unsigned int." [...] If an int can represent all values of the original type, the value is converted to an int; otherwise, it is converted to an unsigned int." Please, note the wording: "less than *or equal*". As I read it, I understand that promotion rules are applied to int, unsigned int, or other types with less rank. And any unsigned int small enough to fit on a signed int is converted. These rules appears to be valid also for the unary - , and even when operator is unsigned. I would be happy to change my mind if you point to any section of the standard stating that unsigned operands should never be touched, but currently the text I see appears to say the opposite. So, in the way I view it, the expression: -10U should return an int instead of unsigned, and it should be safe to assign it to a bigger integer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31166
