int64_t and printf
ben at links.org
Sun Jun 5 20:17:40 UTC 2011
On 05/06/2011 19:21, Poul-Henning Kamp wrote:
> In message <4DEBC741.1020200 at links.org>, Ben Laurie writes:
>> So, for example int64_t has no printf modifier I am aware of. Likewise
>> its many friends.
>> but I have no idea where to put such a thing in FreeBSD. Opinions?
> I have totally given up on this mess.
> At best you get incredibly messy source code, at worst you waste a
> lot of time figuring out why who to define stuff to make some platform
> you have only heard rumours about behave.
> I have therefore resorted to printf'ing any typedefed integer type using
> "%jd" and an explicit cast to (intmax_t):
> printf("%-30s -> %jd -> %s\n", s, (intmax_t)t, buf);
> If some system introduces int512_t that may not be optimal, but
> since printf is a pretty slow operation anyway, I doubt it will
> hurt even half as much as the alternative.
My objection to this approach is the lack of type-safety - t could be
anything and this would continue to work.
Using PRId64 at least ensures that t is of an appropriate type.
One way to get the best of both worlds is to at least ensure that t is
of the type you think it is before casting, but this also leads to messy
code - the best I can think of would look like
printf("%-30s -> %jd -> %s\n", s, cast(int64_t, intmax_t, t), buf);
Is this really better than
printf("%-30s -> %" PRId64 " -> %s\n", s, t, buf);
? Mere character count would suggest not.
Providing a better printf seems like an even smarter idea, e.g.
printf("%-30s -> %I64d -> %s\n", s, t, buf);
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
More information about the freebsd-hackers