Date: Thu, 12 Aug 2010 19:15:01 +0200 From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> To: John Baldwin <jhb@FreeBSD.org> Cc: svn-src-head@freebsd.org, Takanori Watanabe <takawata@FreeBSD.org>, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r211221 - head/usr.sbin/acpi/acpidump Message-ID: <868w4bda7e.fsf@ds4.des.no> In-Reply-To: <4C6414A7.6020306@FreeBSD.org> (John Baldwin's message of "Thu, 12 Aug 2010 11:35:03 -0400") References: <201008121358.o7CDwk0d098768@svn.freebsd.org> <86pqxn50vr.fsf@ds4.des.no> <4C6414A7.6020306@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin <jhb@FreeBSD.org> writes:
> Dag-Erling Sm=C3=B8rgrav <des@des.no> writes:
> > Slightly better:
> >
> > printf("\tClass %u Base Address 0x%jx Length %ju\n\n",
> > (unsigned int)tcpa->platform_class, (uintmax_t)paddr, (uintmax_t=
)len);
> >
> > but it would probably be easier to define paddr and len as unsigned long
> > long instead of the misspelled u_int64_t, and use %llx and %llu.
> Depends. If the table defines a field to be a 64-bit integer, it is
> better to use an explicitly-64-bit integer type such as uint64_t
> rather than assuming that 'long long' is 64-bit.
Actually, paddr and len are a memory address and an object size,
respectively, so the logical thing would be to use uintptr_t and size_t
with uintmax_t casts...
DES
--=20
Dag-Erling Sm=C3=B8rgrav - des@des.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?868w4bda7e.fsf>