On Tue, Apr 05, 2011 at 10:01:00AM +0100, Russell King - ARM Linux wrote: > On Tue, Apr 05, 2011 at 10:31:44AM +0200, Uwe Kleine-König wrote: > > On Tue, Apr 05, 2011 at 08:56:22AM +0100, Russell King - ARM Linux wrote: > > > On Tue, Apr 05, 2011 at 09:43:21AM +0200, Jan Weitzel wrote: > > > > parameter "u32 mask" type cast befor inversion > > s/befor/before/ > > > > > Nak. I want a 32-bit all ones quantity. > > > > > > unsigned long long vali = (unsigned short)~0; > > > unsigned long long vall = ~(unsigned short)0; > > > > > BTW, the definiton of vall is equivalent to > > > > unsigned long long valu = ~(unsigned int)0; > > > > because ~ converts the unsigned short to unsigned int. > > No. The value gets promoted to int not unsigned int. > > > > compiles to: > > > > > > vali: > > > .word 65535 > > > .word 0 > > > > > > vall: > > > .word -1 > > > .word -1 > > I really wonder about that. If I take a value of 0xffffffff (i.e. a 32 > > bit wide int == ~0U) and assign that to an 64-bit unsigned long long I'd > > expect it to get the value 0x00000000ffffffffULL, not > > 0xffffffffffffffffULL. What's wrong? > > See above. int not unsigned int. And it makes a difference: > > unsigned long long vals = ~(int)0; > unsigned long long valu = ~(unsigned int)0; > > vals: > .word -1 > .word -1 > valu: > .word -1 > .word 0 > ah, ok, makes sense and actually is consistent with my book. (After knowing what I search I found it. The rules are: - A signed type of rank less than int -> int - An unsigned type of rank less than int, all of whose values can be represented in type int -> int - An unsigned type of rank less than int, all of whose values cannot be represented in type int -> unsigned int ). So the maximal correct variant is (u32)(int)~0U or alternatively (u32)(-1), right? Thanks for your answer, best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
