how to kernel printf a int64_t?

[Rick Macklem]

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 at 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(“%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 <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..
> > 
> 
> 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.
> 
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.
> > 
> 
> 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
> > 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.
> > 
> 
> 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
> 
> 
> 
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to
> "freebsd-hackers-unsubscribe at freebsd.org"
>