We probably need to differentiate between "ACPICA" and "ACPICA on Linux" ACPICA needs to be highly portable, across different C compilers, machine architectures, and operating systems. To the matter at hand, it is of course nice to have an integer data type that is the same as the native bit width of the machine/mode. This is the same definition as the "size_t" type, is it not? "long" is not 64-bit under LLP64, which ACPICA claims to support. >-----Original Message----- >From: Alexey Starikovskiy [mailto:astarikovskiy@xxxxxxx] >Sent: Tuesday, April 15, 2008 2:57 PM >To: Tomas Carnecky >Cc: Moore, Robert; Alexey Starikovskiy; Len Brown; linux- >acpi@xxxxxxxxxxxxxxx >Subject: Re: [PATCH 65/73] ACPICA: Fix for extraneous debug message for >packages > >Tomas Carnecky wrote: >> Moore, Robert wrote: >>> 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. >> >> What's wrong with '%l'? The kernel printf seems to support it, and the >> printf manpage says: >> >> A following integer conversion corresponds to a long int or unsigned >> long int argument. >> >> And since long is 32bit on 32bit platforms and 64bit on 64bit platforms, >> it should work out fine. Or did I miss something? >Yes. You missed the fact that long is not 64 bit on Windows 64, and ACPICA >appears to >care about that. > >Regards, >Alex. -- 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
