On Mon, Sep 18, 2017 at 05:46:34PM +0100, Ian Jackson wrote: >Steve McIntyre writes ("Re: Summary of the 2038 BoF at DC17"): >> It depends on how/where/why you're embedding 64-bit time, >> basically. If you're embedding a time_t (or a struct including a >> time_t) in your ABI and want to keep to something similar, it's worth >> waiting to see what's going to be standardised then using that. > >Are you saying that if I am designing an API/ABI now I should write: > > typedef struct { > blah blah; > time_t whenever; > blah blah; > } MyAPIThing; > >rather than > > typedef struct { > blah blah; > uint64_t whenever; > blah blah; > } MyAPIThing; > >? Really ? > >I think that's bad advice.
Yes, really. You've now hidden that you're storing time data by using another data type, which makes things much harder to find if anybody else is scanning for time-handling code. And you've made assumptions about how new time-handling APIs are likely to look in the near-ish future when people have worked everything out and agreed new standards. If the new stuff ends up using a different representation with 96 or even 128 bits in total, I'd argue that it's cleaner to wait for that and not gamble. >I would do the latter. Even though that means writing library code >internally that checks whether the supplied value of `whenever' fits >in whatever the system calls a time_t. Your code, your choice... -- Steve McIntyre, Cambridge, UK. st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty