>So, once again, why we used acpi_native_uint there and why we changed that >to uint32 and not unsigned? I think the use of ACPI_NATIVE_UINT was already there. The printf statement is new, that's why the problem shows up now. >-----Original Message----- >From: Alexey Starikovskiy [mailto:astarikovskiy@xxxxxxx] >Sent: Tuesday, April 15, 2008 2:51 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: >> 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. >Ok, let it be obscure type with such properties. >Now back to original patch, where we change from "acpi_native_uint i;" to >"uint32 i;" Both types are not supported by printf(), while the reason of >the patch to gain such support. There is no expectation that i will need to >be 32 bits long to not roll over, let along 64 bit. >So, once again, why we used acpi_native_uint there and why we changed that >to uint32 and not unsigned? > >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
