> I don't think, personally, that any of this is reason enough to worry about > it. Using an int64_t for time_t is IMO a perfectly reasonable default for > 32-bit and up targets. and possibly for all targets. Offering a kconfig > option to support 32-bit (signed or unsigned) time_t offers an easy > work-around should anyone find that the couple of percent increase in code > size and execution time causes their project to fail - or if anyone is in > the unfortunate situation where they depend on code that's made assumptions > about size or signedness.
ideally, we should use int64_t for all targets unconditionally, IMO. however, in practice, 64-bit integers don't seem available for some of our targets. (ez80, z8, z16) maybe someone can add 64-bit integer support to their toolchains. but i suppose we don't want to wait for it to happen.
