William Lee Irwin III writes:
>> m->mpc_apicid is an 8-bit type; MAX_APICS can be 256. The above fix
>> properly compares two integral expressions of equal width.
On Thu, May 22, 2003 at 08:29:41PM +0200, mikpe@csd.uu.se wrote:
> In the original "_>_", the 8-bit mpc_apicid is implicitly converted to int
> before the comparison, as part of the "integer promotions" in the "usual
> arithmetic conversions" (C standard lingo). The same happens in your "_-_<=0".
> So what's the benefit of the rewrite?
It removes a warning about comparisons being always true or false by
virtue of the limited range of a type.
William Lee Irwin III writes:
>> Also, as MAX_APICS-1 is reserved for the broadcast physical APIC ID
>> (it's 0xF for serial APIC and 0xFF for xAPIC) the small semantic change
>> here is correct.
On Thu, May 22, 2003 at 08:29:41PM +0200, mikpe@csd.uu.se wrote:
> No argument there, except that ">=" gets the job done in a cleaner way.
This is actually massively confused anyway. It gets physical APIC ID
checks wrong for sparse xAPIC's on mach-default. But that's another
issue.
-- wli
-
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/
This archive was generated by hypermail 2b29 : Fri May 23 2003 - 22:00:50 EST