lkml.org 
[lkml]   [2004]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: kernel/microcode.c error from new 64bit code
Date
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/

\
 
 \ /
  Last update: 2005-03-22 14:01    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site