It's deeply ugly to have to maintain "%llu", "%lu", and various other format strings for a single (uint64_t) or indeed (time_t). It's also ugly to up-cast everything to the largest potential size whenever you use format strings.
This seems like a case of choosing deep ugliness over superficial ugliness...
"%" PRIu64 ": The time is: %" PRI_TIME_T, x, y
Seems nicer to me than:
"%llu: The time is: %lld", (long long unsigned)x, (long long)y /* time_t is signed? Who knows? */
What type would you use if you wanted to print uint128_t? %llld ?
Finally, I think rejecting a standard C header file because it is "ugly" and coming up with your own solution is unnecessarily fragmenting things, especially when it isn't clearly better (IMO it is clearly worse).
> It's also ugly to up-cast everything to the largest potential size whenever you use format strings.
I'm not sure that is true. It accurately captures the reality that you don't know the size of the type, but that you have determined what the maximum size can be and hopefully made considerations for it.
I should think there isn't even necessarily a performance cost, as it wouldn't be hard to trick out a compiler to recognize what was going on and optimize accordingly.
> What type would you use if you wanted to print uint128_t? %llld ?
IIRC, there is no standard portable format string length modifier for 128-bits (I think some platforms used %q for it, but that's definitely not portable), so literally nothing. Format strings suck.
> Finally, I think rejecting a standard C header file because it is "ugly" and coming up with your own solution is unnecessarily fragmenting things, especially when it isn't clearly better (IMO it is clearly worse).
Note that as the presentation points out, the better thing to do is whatever is going to easily adopted. In this case, where people are already using format strings, and already working with a time_t that might be only 32-bits wide, this might actually be that solution.
> rejecting a standard C header file because it is "ugly"
I just checked an OpenBSD machine's inttypes.h. Some of the format macros (I presume the ones present in the standard) are there. So I can't say they rejected the header.
It would probably be weird to introduce one there that isn't in the standard. OTOH %lld for long long is in the standard.
It's deeply ugly to have to maintain "%llu", "%lu", and various other format strings for a single (uint64_t) or indeed (time_t). It's also ugly to up-cast everything to the largest potential size whenever you use format strings.
This seems like a case of choosing deep ugliness over superficial ugliness...
Seems nicer to me than: What type would you use if you wanted to print uint128_t? %llld ?Finally, I think rejecting a standard C header file because it is "ugly" and coming up with your own solution is unnecessarily fragmenting things, especially when it isn't clearly better (IMO it is clearly worse).