From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 2 16:35:49 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 96938E0D; Sun, 2 Nov 2014 16:35:49 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 56B44870; Sun, 2 Nov 2014 16:35:48 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Xky7y-000LO6-1a; Sun, 02 Nov 2014 16:35:42 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sA2GZf1T089792; Sun, 2 Nov 2014 09:35:41 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+u57BPOU90azeREyMClh0B X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: how to kernel printf a int64_t? From: Ian Lepore To: Julian Elischer In-Reply-To: <54565604.2030208@freebsd.org> References: <1123726553.4004621.1414932491616.JavaMail.root@uoguelph.ca> <54565604.2030208@freebsd.org> Content-Type: text/plain; charset="iso-8859-13" Date: Sun, 02 Nov 2014 09:35:40 -0700 Message-ID: <1414946140.67444.0.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id sA2GZf1T089792 Cc: Freebsd hackers list , Rick Macklem 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:35:49 -0000 On Mon, 2014-11-03 at 00:04 +0800, Julian Elischer wrote:=20 > 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(=B4%jd\n=A1, (intmax_t)i); the "cannonical' way is t= o > >>>>> 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 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. > PRIu64 specifies that the value will always be 64 bits (unsigned) on=20 > every architecture. > If that's NOT true then yes, use a type (e.g. %d) that varies here and=20 > there. > If your value will ALWAYS be 64 but then PRIu64 describes what it is=20 > much better than > %j, because you need to know what %j expects on every architecture your > code may ever run on. >=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. > In my own opinion, PRIu64 is much more readable than %j because the siz= e > and expected signed/unsigned characterisitics are right there, where > %randomletter is exactly that.. completely random, requiring that the=20 > reader go > consult a man page first before reading code for any given architecture. >=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). -- Ian