arch/i386/kernel/mpparse.c warning fixes

Quoted 5 lines

arch/i386/kernel/mpparse.c +1 -1

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

Quoted 5 lines · William Lee Irwin III

arch/i386/kernel/mpparse.c void __init MP_processor_info (struct mp · line 177

Quoted 5 lines

arch/i386/kernel/mpparse.c +1 -1

-	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, [email protected] wrote:

Quoted 2 lines

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.

Quoted 2 lines

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?

Quoted 3 lines

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.

Quoted 2 lines · William Lee Irwin III

Quoted 2 lines

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

Quoted 4 lines · On Thu, May 22, 2003 at 08:29:41PM +0200, [email protected] 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.

Quoted 4 lines · On Thu, May 22, 2003 at 08:49:33PM +0200, [email protected] 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.