Re: kernel/microcode.c error from new 64bit code

[H. Peter Anvin]

Followup to:  <Pine.LNX.4.58.0402210914530.3301@xxxxxxxxxxxxxxx>
By author:    Linus Torvalds <torvalds@xxxxxxxx>
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/