From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 2 23:02:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7077EADC; Sun, 2 Nov 2014 23:02:35 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 00C2BE0; Sun, 2 Nov 2014 23:02:34 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAIALq3VlSDaFve/2dsb2JhbABcg2JYBIMCyggKhnlUAoEKIwEBAQEBfYQCAQEBAwEBAQEgKyALGxIGAgINGQIpAQkYDgYIBwQBHASIFwkNtGOUGQEBAQcBAQEBAQEBARqBLY8SAQEbATMHgneBVAWLdopzhBKENz2GQoRJhU6ECYQWHy8HgQg5gQMBAQE X-IronPort-AV: E=Sophos;i="5.07,303,1413259200"; d="scan'208";a="165379853" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 02 Nov 2014 18:02:07 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 90E87B406F; Sun, 2 Nov 2014 18:02:07 -0500 (EST) Date: Sun, 2 Nov 2014 18:02:07 -0500 (EST) From: Rick Macklem To: Ian Lepore Message-ID: <1581914338.4217211.1414969327581.JavaMail.root@uoguelph.ca> In-Reply-To: <1414946140.67444.0.camel@revolution.hippie.lan> Subject: Re: how to kernel printf a int64_t? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) 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 23:02:35 -0000 Ian Lepore wrote: > On Mon, 2014-11-03 at 00:04 +0800, Julian Elischer wrote: > > 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(=E2=80=9C%jd\n=E2=80=9D, (intmax_t)i); the "cannonic= al' 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.. > >=20 >=20 > The recommendation was "%j and a cast" not just %j. The cast will > ensure that the size of the argument matches the size of the format. >=20 Yes, I understood that (just didn't state it in the above). Thanks, rick > > 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. > >=20 >=20 > It is well-known what the %j size modifier expects on every > architecture: the size of a value of type [u]intmax_t, which is what > the corresponding argument cast provides. It is a given that > [u]intmax_t is able to represent all other integer types of the > corresponding signedness. >=20 > > 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. > >=20 >=20 > I'm willing to be proven wrong that %j and the corresponding > [u]intmax_t > cast will provide the wrong result in some case. But the proof has > to > be in the form of something other than "I disagree with you on which > one > is more readable". You seem to be conflating correctness of > operation > with stylistic opinion in your reply (sorry if that's not your intent > and the conflation is only in my head). >=20 > -- Ian >=20 >=20 >=20 > _______________________________________________ > 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" >=20