I've always assumed that byte swapping of constants would be optimized where a variable would not :-) I have confirmed in assembler output of the compiler that constant merely become byte reversed constants optimized or no in at least one architectural case. I have *not* confirmed that a variable byte reversal requires processing overhead, as one could possibly expect the compiler to instead optimize by byte reversing the constant when comparing. However, I will guarantee you that if optimization is turned off in the compiler that such an optimization will not take place... I do not think this turns into a readability issue in either case and view this as a simple cosmetic coding precaution much like likely()/unlikely() offers hints to the compiler on code intent... Sincerely -- Mark Salyzyn > -----Original Message----- > From: Grant Grundler [mailto:grundler@xxxxxxxxxx] > Sent: Tuesday, January 08, 2008 4:17 PM > To: Salyzyn, Mark > Cc: linux-scsi@xxxxxxxxxxxxxxx > Subject: Re: [PATCH 1/1] aacraid: big endian issues > > On Jan 8, 2008 12:48 PM, Salyzyn, Mark > <Mark_Salyzyn@xxxxxxxxxxx> wrote: > > Big endian systems issues discovered in the aacraid driver. > > ... > --- a/drivers/scsi/aacraid/comminit.c 2008-01-08 > 15:32:28.329810853 -0500 > +++ b/drivers/scsi/aacraid/comminit.c 2008-01-08 > 15:37:35.633163607 -0500 > @@ -301,10 +301,10 @@ > if ((!aac_adapter_sync_cmd(dev, GET_ADAPTER_PROPERTIES, > 0, 0, 0, 0, 0, 0, status+0, status+1, > status+2, NULL, NULL)) && > (status[0] == 0x00000001)) { > - if (status[1] & AAC_OPT_NEW_COMM_64) > + if (status[1] & le32_to_cpu(AAC_OPT_NEW_COMM_64)) > ... > > Why apply le32_to_cpu() to the constant instead of the variable? > On systems were le32_to_cpu() is doing something, can gcc or > preprocessor optimize the constant? > I've always assumed it could not but that might be wrong. > > thanks, > grant - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html