int64_t and printf

[Ben Laurie]

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);

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"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