Date: Sun, 2 Nov 2014 09:23:48 -0800 From: Tim Kientzle <tim@kientzle.com> To: Paul Koch <paul.koch@akips.com> Cc: Freebsd hackers list <freebsd-hackers@freebsd.org> Subject: Re: how to kernel printf a int64_t? Message-ID: <3E8C7E0D-5858-4BFF-8C09-FAA68200B988@kientzle.com> In-Reply-To: <20141102114614.38aa9034@akips.com> References: <439339249.2551223.1414702876172.JavaMail.root@uoguelph.ca> <97A82163-E78D-457E-B649-B243B41A6C6F@kientzle.com> <54558778.7050500@freebsd.org> <20141102114614.38aa9034@akips.com>
index | next in thread | previous in thread | raw e-mail
> On Nov 1, 2014, at 6:46 PM, Paul Koch <paul.koch@akips.com> wrote:
>
> On Sun, 02 Nov 2014 09:23:04 +0800
> Julian Elischer <julian@freebsd.org> wrote:
>
>> On 10/31/14, 1:09 PM, Tim Kientzle wrote:
>>> On Oct 30, 2014, at 2:01 PM, Rick Macklem <rmacklem@uoguelph.ca> wrote:
>>>
>>>> int64_t i;
>>>>
>>>> printf("%qd\n", (u_quad_t)i);
>>>>
>>>> Is there a better way to printf() a int64_t in the kernel?
>>>
>>> printf(“%jd\n”, (intmax_t)i);
>
> We've always used the PRIxxx types when coding for both 32/64 platforms,
> but it would have been really nice to have a standard way for time_t.
> Something like PRItt
This is the major reason I prefer the intmax_t cast approach: the PRI* macros only support a small handful of basic integer types.
The intmax_t cast approach only requires you to know whether it's signed (%jd with intmax_t) or unsigned (%ju with uintmax_t).
> On Nov 1, 2014, at 7:14 PM, Rick Macklem <rmacklem@uoguelph.ca> wrote:
> Oh, and is intmax_t going to be int64_t on all arches?
Yes, until we start supporting 128-bit arithmetic. So the only runtime cost for this approach is that it might have to widen the value. (Given the cost of printf in general, that's likely not a problem.)
Tim
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E8C7E0D-5858-4BFF-8C09-FAA68200B988>