[email protected] schrieb am 05.04.2011 10:31:44:
> Von: Uwe Kleine-König <[email protected]> > An: Russell King - ARM Linux <[email protected]> > Kopie: [email protected], [email protected], > [email protected], [email protected], [email protected], Jan > Weitzel <[email protected]>, [email protected], linux- > [email protected], [email protected], > [email protected], [email protected], > [email protected], [email protected], [email protected] > Datum: 05.04.2011 10:33 > Betreff: Re: [PATCH] ARM: type casts update_sched_clock > cyc_to_sched_clock cyc_to_fixed_sched_clock > Gesendet von: [email protected] > > 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. > > > 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? > > > So moving the ~ to be evaluated after the cast has the effect of making > > the cast pointless, and produces wrong values. (u32)~0 does the 32-bit > My C-Book tells that using ~ on a signed it produces implementation > defined behaviour. That's what I pointed out to Jan and I guess that's > the reason why he created the patch. That's right. I tested it and got for both static unsigned long long valuica = (unsigned int)~0; static unsigned long long valuicb = ~(unsigned int)0; the same: .word 0xffffffff .word 0x00000000 With unsigned short I see the problem. Sorry for the noise. Kind regards Jan -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
