Re: Summary of the 2038 BoF at DC17

[Steve McIntyre <steve@einval.com>]

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.                                steve@einval.com
  Mature Sporty Personal
  More Innovation More Adult
  A Man in Dandism
  Powered Midship Specialty