arch/i386/kernel/mpparse.c warning fixes

arch/i386/kernel/mpparse.c warning fixes

[William Lee Irwin III]

diff -prauN mm8-2.5.69-1/arch/i386/kernel/mpparse.c mm8-2.5.69-2/arch/i386/kernel/mpparse.c
--- mm8-2.5.69-1/arch/i386/kernel/mpparse.c	2003-05-22 04:54:48.000000000 -0700
+++ mm8-2.5.69-2/arch/i386/kernel/mpparse.c	2003-05-22 08:06:13.000000000 -0700
@@ -171,7 +171,7 @@ void __init MP_processor_info (struct mp
 
 	num_processors++;
 
-	if (m->mpc_apicid > MAX_APICS) {
+	if (MAX_APICS - m->mpc_apicid <= 0) {
 		printk(KERN_WARNING "Processor #%d INVALID. (Max ID: %d).\n",
 			m->mpc_apicid, MAX_APICS);
 		--num_processors;
@@ -803,7 +803,7 @@ void __init mp_register_lapic (
 	struct mpc_config_processor processor;
 	int			boot_cpu = 0;
 	
-	if (id >= MAX_APICS) {
+	if (MAX_APICS - id <= 0) {
 		printk(KERN_WARNING "Processor #%d invalid (max %d)\n",
 			id, MAX_APICS);
 		return;

Re: arch/i386/kernel/mpparse.c warning fixes

[mikpe]

William Lee Irwin III writes:
 > diff -prauN mm8-2.5.69-1/arch/i386/kernel/mpparse.c mm8-2.5.69-2/arch/i386/kernel/mpparse.c
 > --- mm8-2.5.69-1/arch/i386/kernel/mpparse.c	2003-05-22 04:54:48.000000000 -0700
 > +++ mm8-2.5.69-2/arch/i386/kernel/mpparse.c	2003-05-22 08:06:13.000000000 -0700
 > @@ -171,7 +171,7 @@ void __init MP_processor_info (struct mp
 >  
 >  	num_processors++;
 >  
 > -	if (m->mpc_apicid > MAX_APICS) {
 > +	if (MAX_APICS - m->mpc_apicid <= 0) {
 >  		printk(KERN_WARNING "Processor #%d INVALID. (Max ID: %d).\n",
 >  			m->mpc_apicid, MAX_APICS);
 >  		--num_processors;

Eeew. Whatever the original problem is, this "fix" is just too obscure and ugly.

Re: arch/i386/kernel/mpparse.c warning fixes

[William Lee Irwin III]

William Lee Irwin III writes:
>> -	if (m->mpc_apicid > MAX_APICS) {
>> +	if (MAX_APICS - m->mpc_apicid <= 0) {
>>  		printk(KERN_WARNING "Processor #%d INVALID. (Max ID: %d).\n",
>>  			m->mpc_apicid, MAX_APICS);
>>  		--num_processors;

On Thu, May 22, 2003 at 06:07:43PM +0200, mikpe@csd.uu.se wrote:
> Eeew. Whatever the original problem is, this "fix" is just too
> obscure and ugly.

m->mpc_apicid is an 8-bit type; MAX_APICS can be 256. The above fix
properly compares two integral expressions of equal width.

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.


-- wli

Re: arch/i386/kernel/mpparse.c warning fixes

[mikpe]

William Lee Irwin III writes:
 > William Lee Irwin III writes:
 > >> -	if (m->mpc_apicid > MAX_APICS) {
 > >> +	if (MAX_APICS - m->mpc_apicid <= 0) {
 > >>  		printk(KERN_WARNING "Processor #%d INVALID. (Max ID: %d).\n",
 > >>  			m->mpc_apicid, MAX_APICS);
 > >>  		--num_processors;
 > 
 > On Thu, May 22, 2003 at 06:07:43PM +0200, mikpe@csd.uu.se wrote:
 > > Eeew. Whatever the original problem is, this "fix" is just too
 > > obscure and ugly.
 > 
 > m->mpc_apicid is an 8-bit type; MAX_APICS can be 256. The above fix
 > properly compares two integral expressions of equal width.

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?

 > 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.

No argument there, except that ">=" gets the job done in a cleaner way.

Re: arch/i386/kernel/mpparse.c warning fixes

[William Lee Irwin III]

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

Re: arch/i386/kernel/mpparse.c warning fixes

[mikpe]

William Lee Irwin III writes:
 > 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.

Ah, so it's a workaround to silence a compiler warning on char > 256.
Frankly, I'd rather see a cast there in this case. I.e.,

	 (unsigned int)m->mpc_apicid >= MAX_APICS

or something like that, with a suitable comment.

Re: arch/i386/kernel/mpparse.c warning fixes

[William Lee Irwin III]

On Thu, May 22, 2003 at 08:49:33PM +0200, mikpe@csd.uu.se wrote:
> Ah, so it's a workaround to silence a compiler warning on char > 256.
> Frankly, I'd rather see a cast there in this case. I.e.,
> 	 (unsigned int)m->mpc_apicid >= MAX_APICS
> or something like that, with a suitable comment.

Already tried it. It does not suffice to silence the compiler.


-- wli

Re: arch/i386/kernel/mpparse.c warning fixes

[mikpe]

William Lee Irwin III writes:
 > On Thu, May 22, 2003 at 08:49:33PM +0200, mikpe@csd.uu.se wrote:
 > > Ah, so it's a workaround to silence a compiler warning on char > 256.
 > > Frankly, I'd rather see a cast there in this case. I.e.,
 > > 	 (unsigned int)m->mpc_apicid >= MAX_APICS
 > > or something like that, with a suitable comment.
 > 
 > Already tried it. It does not suffice to silence the compiler.

Ok, I give up. The stupid POS compiler forces the ugly rewrite...