Well, yes native word size being the pointer size, now that the 16-bit model is out of the picture. We defined ACPI_NATIVE_UINT in order to have an integer data type that is 32 bits in 32-bit mode, and 64 bits in 64-bit mode (and originally, 16 bits in 16-bit mode). There is no corresponding C type that can accomplish this across all compilation models. Yes, ACPI_NATIVE_UINT has issues with printf because there is unfortunately no printf formatting operator other than %p that goes 32 bits in 32-bit mode and 64 bits in 64-bit mode. I think there may be cases in ACPICA where we just cast an ACPI_NATIVE_UINT to a pointer to use it with printf. >-----Original Message----- >From: Alexey Starikovskiy [mailto:astarikovskiy@xxxxxxx] >Sent: Tuesday, April 15, 2008 2:12 PM >To: Moore, Robert >Cc: Alexey Starikovskiy; Len Brown; linux-acpi@xxxxxxxxxxxxxxx >Subject: Re: [PATCH 65/73] ACPICA: Fix for extraneous debug message for >packages > >Moore, Robert wrote: >> Native word size of the machine. >> >> As I remember, lint especially really likes array indexes that use the >> word size of the machine, and of course it is the most efficient >> usually. However, there is no C data type that represents the native >> word size across all compilation models. >and native word size being sizeof(void *)? > >Let's look on that from the other perspective. int is intended by C authors >as least expensive to use integer type. long is intended to be least >expensive >integer type of maximum capacity. Both types play nice with printf() and >Co. > >Now we introduce new typedef to annoy printf(), C, and Linux bosses only to >please lint? > >Regards, >Alex. >> >> >>> -----Original Message----- >>> From: Alexey Starikovskiy [mailto:aystarik@xxxxxxxxx] >>> Sent: Tuesday, April 15, 2008 1:40 PM >>> To: Moore, Robert >>> Cc: Alexey Starikovskiy; Len Brown; linux-acpi@xxxxxxxxxxxxxxx >>> Subject: Re: [PATCH 65/73] ACPICA: Fix for extraneous debug message for >>> packages >>> >>> Moore, Robert wrote: >>>> I think one of the reasons we introduced ACPI_NATIVE_UINT is that >> "int" >>>> is in fact not "native" under all compilation models. >>>> >>>> Here is the table from actypes.h >>>> >>>> * Datatype LP64 ILP64 LLP64 ILP32 LP32 16bit >>>> * char 8 8 8 8 8 8 >>>> * short 16 16 16 16 16 16 >>>> * _int32 32 >>>> * int 32 64 32 32 16 16 >>>> * long 64 64 32 32 32 32 >>>> * long long 64 64 >>>> * pointer 64 64 64 32 32 32 >>>> >>>> >>> Sorry, what do you mean by "not native" ? >>> sizeof(int) != sizeof(void *) or something else? >>> How does it change applicability as array index? >> -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html