[dmm]

The typedef 'time_t' is definitely being used, for example is is a patch from sys/kern/kern_clock.c: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/kern/kern_cloc...

That was part of a larger changeset that enabled 64bit time_t on 2013-08-13. The 'long' type is changed to 'time_t', which is now 64bit everywhere on OpenBSD.

I didn't see think talk but I think it's confusing because we are just seeing the slides. Here is what I got from it:

    remove time_t from network/on-disk/database formats

Right now if you have a userspace app that has some kind of binary disk format, say a database, and you use the time_t typedef your binary files will not be portable between systems which have differently sized time_t's. However, if you use 'long long' or 'int64_t' and cast time_t's to those, your files will be portable and 64bit everywhere.

If you're using time_t in network formats, systems with different time_t sizes will confuse each other!

    remove as many (time_t) casts as possible

This is trouble because you don't know the size of time_t, if it's 32bit you might be truncating! It's better to cast to a 64bit size, that will always work, at least for the next 292 billion years.

[cbsmith]

Thanks. This makes much more sense sense now. I'd still be tempted to use some kind of a typedef for the field, but yeah, you'd not want to derive it from the system's time_t structure.

[justincormack]

Yes that's about right. The videos will be up at some point but it was a two phase process like that.