The four constants have different types and the types are not
necessarily what you'd expect (eg FOO_VALUE3 has been promoted to a
64 bit signed long, FOO_VALUE1 has been demoted to an int)
So the enum is safe, but having different types of the values is
certainly unexpected.
I still think the actual bug is only 1<<31 I pointed out earlier:
enum Foo
{
FOO_VALUE1 = 1,
FOO_VALUE2 = ((uint64_t)2) << 32,
FOO_VALUE3 = 1<<31,
};
uint64_t res = FOO_VALUE1 | FOO_VALUE2 | FOO_VALUE3;
printf("%lx\n",res);
==
ffffffff80000001
Which is clearly wrong. This is because signed int becomes sign
extended when converted to uint64_t, corrupting the upper bits.
Since adding the ULL's doesn't make the enum constants have uniform
type I would not bother with the churn.
tested this with single casting to IB_DEVICE_ON_DEMAND_PAGING (1 << 31)
to (1ULL << 31). works fine.
I'll send another patch today.
Thanks,
Max.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
