------- Comment #2 from roberto dot gordo at gmail dot com 2007-03-13 22:27
-------
I do not agree at all. Please, read.
So 0x80000000 is unsigned because does not fit on an int type. That's OK. If
negating it gives an unsigned int of the same value, then, how do you explain
that the following code prints "n1 = -2147483648"
int n1;
n1 = -0x80000000;
printf("n1 = %d\n", n1);
It works because the expression should not be unsigned. This is a quotation
from ISO/IEC 9899:1999 standard:
"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."
and...
"Several operators convert operand values from one type to another
automatically [...] 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. These are called the integer promotions."
The unary - operator can (and should) apply again the promotion rules, and
should choose int.
So the expression -0x80000000 shall promote to a signed integer type in which
it fits, which happens to be an int (on c99 and c90). And as you can see, gcc
works correcly here, just as the standard says. But if fails when the lvalue is
long long instead of int, as here:
long long n1;
n1 = -0x80000000;
In case we have an int expression at the right, it should be converted as long
long without problems. In case we have a long long at the right, it should also
work without problems (at least for c99). And if we have an unsigned int at the
right, as you said, it should have not worked with an int and it is a bug by
itself in the way I understand the standard.
--
roberto dot gordo at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |roberto dot gordo at gmail
| |dot com
Status|RESOLVED |UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31166
