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
