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
