svn commit: r211252 - head/usr.sbin/acpi/acpidump
Bruce Evans
brde at optusnet.com.au
Fri Aug 13 09:06:53 UTC 2010
On Fri, 13 Aug 2010, Takanori Watanabe wrote:
> Log:
> Fix build on amd64 and ia64.
Why not fix it on all arches?
> Modified: head/usr.sbin/acpi/acpidump/acpi.c
> ==============================================================================
> --- head/usr.sbin/acpi/acpidump/acpi.c Fri Aug 13 00:21:32 2010 (r211251)
> +++ head/usr.sbin/acpi/acpidump/acpi.c Fri Aug 13 00:45:30 2010 (r211252)
> ...
> @@ -623,7 +622,7 @@ acpi_handle_tcpa(ACPI_TABLE_HEADER *sdp)
> {
> struct TCPAbody *tcpa;
> struct TCPAevent *event;
> - u_int64_t len, paddr;
> + uint64_t len, paddr;
> unsigned char *vaddr = NULL;
> unsigned char *vend = NULL;
>
> @@ -647,7 +646,7 @@ acpi_handle_tcpa(ACPI_TABLE_HEADER *sdp)
> printf(END_COMMENT);
> return;
> }
> - printf("\tClass %d Base Address 0x%jx Length %" PRIu64 "\n\n",
> + printf("\tClass %u Base Address 0x%jx Length %ju\n\n",
> tcpa->platform_class, paddr, len);
>
> if (len == 0) {
For `len', this used to assume that variables of type u_int64_t can
be printed using PRIu64. Why the PRIu64 abomination should never be
used, this assumption is valid.
For `len', this now assumes that variables of type uint64_t can be
printed using %ju format. %ju format is for printing variables of
type uintmax_t, so this assumption is invalid unless uint64_t is the
same as uintmax_t. This assumption happens to be valid on all supported
arches, although it should not be (e.g., on amd64, uint64_t and uintmax_t
both happen to be u_long, but this is illogical since uintmax_t is
supposed to be the largest unsigned integer type but u_long is logically
shorter than unsigned long long). Fixing these arches might expose
many printf format errors like the above.
For `paddr', this used to and still invalidly assumes that variables of
type uint64_t can be printed using %ju format.
PRIu64 is "lu" on both amd64 and ia64, and __uint64_t is u_long on both
amd64 and ia64, so I don't see how the original version failed. In fact,
it doesn't fail for me.
__uintmax_t is u_long on both amd64 and ia64, so the modified version
should work too, though accidentally, just like the unmodified version
works accidentally for `paddr'.
To expose even more printf format errors like the above, make __uintmax_t
unsigned long long on amd64 and keep it as the illogical u_long on amd64.
Bruce
More information about the svn-src-all
mailing list