Date: Sun, 02 Nov 2014 09:35:40 -0700 From: Ian Lepore <ian@FreeBSD.org> To: Julian Elischer <julian@freebsd.org> Cc: Freebsd hackers list <freebsd-hackers@freebsd.org>, Rick Macklem <rmacklem@uoguelph.ca> Subject: Re: how to kernel printf a int64_t? Message-ID: <1414946140.67444.0.camel@revolution.hippie.lan> In-Reply-To: <54565604.2030208@freebsd.org> References: <1123726553.4004621.1414932491616.JavaMail.root@uoguelph.ca> <54565604.2030208@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <rmacklem@uoguelph.ca>
> >>>>> 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 <machine/_inttypes.h>, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1414946140.67444.0.camel>