Tom St Denis wrote:
But it isn't.
That's no news. I am interested in _why_ it is not. I have yet to see a plausible explanation for the original algebraic statement why a does not contain a _negative_ value although a's type allows it and the compiler is given enough freedom to allocate a temporary large enough and actually technically available (which is both the case) to hold such a result.
Numerically, that's what it does.
This is what is done _technically_. In pure algebraic terms and given the original expression, a = 4294967280UL is a colossal screw-up which I actually expected the compiler to warn me about.
you took 8, doubled it, then negated it as a 32-bit two's complement.
Actually, that's what the compiler did and _not_ what the expression suggested.
I ask again. Why would that be sign extended?
You are missing the point. The result of b * 2u is to be multiplied by -1 and stored in a. How such a simple algebraic statement can possibly be interpreted as some sick type conversion operation was the point of the original post. Bottom line: If I wanted to use modulo arithmetic I'd be _explicit_ about it.
You're right that a conversion is applied before being stored, but the conversion rule applies to the = operator, nothing else.
Interesting. Can you point me to the section(s) in the standard(s) where temporary expressions are explicitly left out from integral conversions ?
And the rule states that from a 32-bit unsigned value that it will
> be zero extended. Otherwise, the above statement ends with -16 in > a which is not what you're doing. Ironically, that is what I was saying _algebraically_. And I was exclusively interested in the rationale behind the technical result.
I have no idea what you're talking about.
You will in a couple of years.
b = 0xFFFFFFFF * 2
b = 0xffffffff * 2 isn't the same as b = 0xffffffff * 2u. 2 is an integer constant while 2u is a constant for a natural number.
Using your logic ... float a = 3; int b; b = a / 1.5;
That's a completely different problem dealing with _floating point_ conversions (C++ 4.8) and irrelevant to the one I was describing.
I suggest you read either the C standard or at least the K&R C book
> and learn about conversion rules, variable promotions, etc... It appears that you did not read the original post thoroughly as that contained explicit references to the C++ standard.
This is also totally off-topic for this list, as you're not
> discussing a GCC bug. This is gcc-help and not gcc-bugs. Cheers, Christian
