Date: Sun, 2 Nov 2014 18:02:07 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: Ian Lepore <ian@FreeBSD.org> Cc: Freebsd hackers list <freebsd-hackers@freebsd.org> Subject: Re: how to kernel printf a int64_t? Message-ID: <1581914338.4217211.1414969327581.JavaMail.root@uoguelph.ca> In-Reply-To: <1414946140.67444.0.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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
> > >>>>> <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(=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 <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
>=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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1581914338.4217211.1414969327581.JavaMail.root>