From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 2 16:04:33 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7CF93C2; Sun, 2 Nov 2014 16:04:32 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B6647380; Sun, 2 Nov 2014 16:04:31 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-239-104.lns20.per1.internode.on.net [121.45.239.104]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id sA2G4RvG019224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 2 Nov 2014 08:04:29 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54565604.2030208@freebsd.org> Date: Mon, 03 Nov 2014 00:04:20 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Rick Macklem , Ian Lepore Subject: Re: how to kernel printf a int64_t? References: <1123726553.4004621.1414932491616.JavaMail.root@uoguelph.ca> In-Reply-To: <1123726553.4004621.1414932491616.JavaMail.root@uoguelph.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Freebsd hackers list X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 16:04:33 -0000 On 11/2/14, 8:48 PM, Rick Macklem wrote: > Ian Lepore wrote: >> On Sun, 2014-11-02 at 11:20 +0800, Julian Elischer wrote: >>> On 11/2/14, 10:14 AM, Rick Macklem wrote: >>>> Julian Elischer wrote: >>>>> On 10/31/14, 1:09 PM, Tim Kientzle wrote: >>>>> >>>>> >>>>> On Oct 30, 2014, at 2:01 PM, Rick Macklem >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I feel kinda dumb asking this, but... >>>>> int64_t i; >>>>> >>>>> printf("%qd\n", (u_quad_t)i); >>>>> >>>>> works but looks dorky, to put it technically;-). >>>>> Is there a better way to printf() a int64_t in the kernel? I >>>>> often >>>>> use the following to print large integers: >>>>> >>>>> printf(“%jd\n”, (intmax_t)i); the "cannonical' way is to >>>>> use >>>>> PRIu64 and friends, but some people seem to have a problem >>>>> with >>>>> doing that. >>>>> >>>> Ok, so now I need to ask another dumb question. >>>> How do you do this in the kernel? >>>> (I can see them defines in , but including >>>> that >>>> doesn't help, which isn't surprising since PRIu64 is in a >>>> string >>>> and won't be recognized as a macro.) >>> you use it with string concatenation. >>> like: >>> >>> printf (" this is a 64 it unsigned value: %" PRIu64 " and I >>> just >>> printed it\n", thingy64); >>> >>> After substitution the compiler sees >>> " this is a 64 it unsigned value: %" "llu" " and I just printed >>> it\n" >>> which simplifies to: >>> " this is a 64 it unsigned value: %llu and I just printed it\n" >>> >>> due to concatenation. (note I didn't actually look what PRIu64 >>> evaluates to) >>> >>> >> Which is exactly the explanation for why "some people seem to have a >> problem with doing that." "Some people" would be "anyone who thinks >> it >> should be possible to read code as well as write it." This may be >> more >> correct in some pedantic sense, but %j and a cast is more readable. >> > Yes, thanks. I'll admit to thinking exactly the same thing. > I guess I'll use %j. then your code could be wrong in some cases.. PRIu64 specifies that the value will always be 64 bits (unsigned) on every architecture. If that's NOT true then yes, use a type (e.g. %d) that varies here and there. If your value will ALWAYS be 64 but then PRIu64 describes what it is much better than %j, because you need to know what %j expects on every architecture your code may ever run on. In my own opinion, PRIu64 is much more readable than %j because the size and expected signed/unsigned characterisitics are right there, where %randomletter is exactly that.. completely random, requiring that the reader go consult a man page first before reading code for any given architecture. > > Thanks everyone for your help, rick > >> -- Ian >> >>>> Oh, and is intmax_t going to be int64_t on all arches? >>>> >>>> Thanks, rick >>>> >>>>> Tim >>>>> >>>>> _______________________________________________ >>>>> freebsd-hackers@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To >>>>> unsubscribe, send any mail to >>>>> "freebsd-hackers-unsubscribe@freebsd.org" >>>>> >>>> >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to >>> "freebsd-hackers-unsubscribe@freebsd.org" >>> >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" >> > >