Messages in this thread |  | | | From | (H. Peter Anvin) | | Subject | Re: kernel/microcode.c error from new 64bit code | | Date | Sun, 22 Feb 2004 20:12:25 +0000 (UTC) |
| |
Followup to: <Pine.LNX.4.58.0402210914530.3301@ppc970.osdl.org> By author: Linus Torvalds <torvalds@osdl.org> In newsgroup: linux.dev.kernel > > > > On Sat, 21 Feb 2004, Pavel Machek wrote: > > > > > + wrmsr(MSR_IA32_UCODE_WRITE, > > > + (unsigned long) uci->mc->bits, > > > + (unsigned long) uci->mc->bits >> 16 >> 16); > > ~~~~~~~~~~~~ > > > > I see what you are doing, but this is evil. At least comment /* ">> 32" > > is undefined on i386 */ ? > > Sorry, but you're wrong. > > ">> 32" is underfined PERIOD! It has nothing to do with x86, it's a C > standards issue. It's undefined on any 32-bit architecture. (shifting by > the wordsize or bigger is simply not a defined C operation). > > The above is not evil. The above is the standard way of doing this in C if > you know the word-size is 32-bits or bigger. >
Actually, what is undefined is shifting with the size of the data type or higher.
If the cast of uci->mc->bits had been an uint64_t (unsigned long long), >> 32 would have been perfectly well-defined.
The above code is just plain wrong: the cast to (unsigned long) has higher precedence than the shift, so on i386 (which I presume this is) it will become an unsigned long, and the shifts will bring it down to zero.
You might as well write zero if that's what you mean.
-hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |