On 2024-01-22 16:00, Paul Gilmartin via tz wrote:
Is there a format specification for printing such a type or must it first be converted to long long by either cast or arithmetic? I'm uneasy with the idea of an integral type that can't be printed.
A similar problem occurs for lots of other POSIX types, such as off_t. For off_t one way to work around the problem is to convert to intmax_t and format with %jd. For time_t it's a bit more complicated as it might or might not be signed, but one can use %jd and intmax_t if time_t is signed, %ju and uintmax_t otherwise.
And what does time_t[] look like? Might there be slack bits between members of the array?
Sure, just like most types. Neither POSIX nor C prohibit padding bits in 'time_t' and similar types. The only types guaranteed to be free of padding bits are signed char, unsigned char, and (if they exist) the intN_t and uintN_t types. In the C standard the intN_t and uintN_t types are optional; POSIX requires them only for N equal to 8, 16, and 32. This stuff is relevant only for unusual machines like the Unisys ClearPath Dorado (36-bit one's complement but 'unsigned' doesn't always work right) and the Unisys Clearpath Libra (40-bit unsigned int and 41-bit signed-magnitude int). You can still buy these two platforms; the hardware, if memory serves, contains Intel Xeons with special microcode. Although I hope tzcode would run on these legacy platforms, it's never been tested to my knowledge and my guess is that there would be porting bugs. C2x will require two's complement so the C committee has stopped worrying about these two dinosaurs.