On Wed, 2 Feb 2011, Rick Mann wrote:
On Feb 2, 2011, at 08:15:40, Michael Hennebry wrote:
On Wed, 2 Feb 2011, Rick Mann wrote:
I was working with some uint32_t variables, using shifts, like this:
uint32_t foo = 0;
for (...)
{
uint32_t v = // some value between [0, 31)
foo |= 1 << v;
^
The type of RHS is int regardless of the type of v.
}
This didn't work correctly for values of v greater than 15 until I changed the
line to:
foo |= 1UL << v;
^^^
The type of RHS is unsigned long regardless of the type of v.
From what I understand of C, it should've promoted 1 to long, but maybe it's a
signed-vs-unsigned issue? What's happening on an ATmega644A with this code?
'Twas a quiet change.
the type of x<<y is now the type of x after the usual integer promotions.
So, it looks like this?
foo = (int) ((long) 1 << v)
If foo is still uint32_t, don't coerce to int.
Not only is it not what you want,
it's not guaranteed to produce anything in particular.
It's an example of the general rule that
non-value-preserving conversions to a
signed integer have no guaranteed semantics.
--
Michael [email protected]
"Pessimist: The glass is half empty.
Optimist: The glass is half full.
Engineer: The glass is twice as big as it needs to be."
_______________________________________________
AVR-chat mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-chat
