
Going long long on time_t - hebz0rl
http://www.openbsd.org/papers/eurobsdcon_2013_time_t/
======
throwaway_yy2Di
If anyone has trouble reading this, there's also plain text versions of
individual slides:

[http://www.openbsd.org/papers/eurobsdcon_2013_time_t/mgp0000...](http://www.openbsd.org/papers/eurobsdcon_2013_time_t/mgp00002.txt)

[http://www.openbsd.org/papers/eurobsdcon_2013_time_t/mgp0000...](http://www.openbsd.org/papers/eurobsdcon_2013_time_t/mgp00003.txt)

etc.

Here's the whole thing in one page, minus images:

[https://gist.github.com/anonymous/6757266/raw/3469464cb802e7...](https://gist.github.com/anonymous/6757266/raw/3469464cb802e7c9a6cbe7c2508b252f7ad8ebdd/Theo+de+Raadt%3A+Going+long+long+on+time_t+to+cope+with+2%2C147%2C483%2C647%2B1)

~~~
simias
My god, I'm not a fan of reading slides in general but this... this is a new
dimension of horror. I can't shake the feeling that there's some sick humour
in this.

~~~
parennoob
What's _so_ horrible about it? Obviously, it isn't on the same level as any of
the slide decks web designers put up that are in a sane format (HTML5+js /
PDF) which don't require you to actually click through, but then

a) Theo De Raadt works much further down the stack

b) This is probably something put up by the EuroBSDCon folks after converting
his slides (can someone who was at the Con weigh in on this? If he actually
presented his talk like this, that's extra bad).

~~~
p1mrx
> What's so horrible about it?

It's Comic Sans with JPEG artifacts. The only consolation is that it doesn't
blink.

~~~
spongle
The content was good though which after all is the main thing...

~~~
eddieh
True, but the font detracts from the technical content. Presentation of
information is important. There are cognitive and psychologic implications
that your reader will incur when reading a document written in Comic Sans.
There is nothing to be gained from using Comic Sans and it's not difficult to
simply not use the font.

------
gizzlon
Good read, even if you, like me, don't care too much about the low-level
stuff..

A few takeaways:

\- Embedded 32bit is everywhere. Sure they'll fix the obvious ones, but I'm
sure some things will be forgotten about. This problem might not be taken
seriously after the Y2K debacle.

\- The OpenBSD guys & gals like to do implement new designs and ideas.
Sometimes radical. (but I already knew that)

\- A transitional solution can end up being _the_ solution ans stick around
forever :(

\- Theorem "In operating systems, increased popularity leads to greater
resistance to change". Probably true in most "products".

~~~
thaumaturgy
> _This problem might not be taken seriously after the Y2K debacle._

I wish people would stop saying things like that. I was one of _many_
programmers who spent some overtime over the course of about a year on fixing
code in 1998-9. I was just the junior programmer at the time; the head guy in
the department had some nearly sleepless nights around then.

I can promise you that in one East Bay school district, nobody would've gotten
their paychecks, report cards would not have worked, DNS would have stopped
working for the _entire_ school network, and finance & budget would have had
some really crazy errors in the output -- those are the systems I still
remember requiring the most attention.

Y2K was a "debacle" because a bunch of people busted their asses fixing old
code.

It feels a lot like pulling two consecutive all-nighters as an engineer on a
project, to bring the project up to its deadline on-time and under-budget,
only to have your department manager the next morning stroll in, well-rested,
coffee cup in hand, and say, "See? Told you it was no big deal."

~~~
gizzlon
Fair enough, it's not the most fitting term.

I _remember_ a lot of hype and no actual problems. I suspect others do as
well, and this could lead to people thinking about the whole problem as over-
hyped and a non-issue.

Not saying that it's correct, but that's the catch-22 of preventing problems:
If you do a too good job, nobody will notice =/

------
Peaker
For format strings, why not do the inttypes.h thing, and define a macro for
the format specifier of (time_t)?

    
    
      "%" PRI_TIME_T

~~~
tedunangst
Openbsd does not believe in the use of the format string macros.

~~~
aidenn0
Any idea of the motivation behind that?

~~~
tedunangst
It's ugly.

~~~
Peaker
It's _superficially_ ugly.

It's _deeply_ ugly to have to maintain "%llu", "%lu", and various other format
strings for a single (uint64_t) or indeed (time_t). It's also ugly to up-cast
everything to the largest potential size whenever you use format strings.

This seems like a case of choosing deep ugliness over superficial ugliness...

    
    
      "%" PRIu64 ": The time is: %" PRI_TIME_T, x, y
    

Seems nicer to me than:

    
    
      "%llu: The time is: %lld", (long long unsigned)x, (long long)y /* time_t is signed? Who knows? */
    

What type would you use if you wanted to print uint128_t? %llld ?

Finally, I think rejecting a standard C header file because it is "ugly" and
coming up with your own solution is unnecessarily fragmenting things,
especially when it isn't clearly better (IMO it is clearly worse).

~~~
cbsmith
> It's also ugly to up-cast everything to the largest potential size whenever
> you use format strings.

I'm not sure that is true. It accurately captures the reality that you don't
know the size of the type, but that you have determined what the maximum size
can be and hopefully made considerations for it.

I should think there isn't even necessarily a performance cost, as it wouldn't
be hard to trick out a compiler to recognize what was going on and optimize
accordingly.

> What type would you use if you wanted to print uint128_t? %llld ?

IIRC, there is no standard portable format string length modifier for 128-bits
(I think some platforms used %q for it, but that's definitely not portable),
so literally nothing. Format strings suck.

> Finally, I think rejecting a standard C header file because it is "ugly" and
> coming up with your own solution is unnecessarily fragmenting things,
> especially when it isn't clearly better (IMO it is clearly worse).

Note that as the presentation points out, the better thing to do is whatever
is going to easily adopted. In this case, where people are already using
format strings, and already working with a time_t that might be only 32-bits
wide, this might actually be that solution.

------
cbsmith
So, this slide confused/troubled me:
[http://www.openbsd.org/papers/eurobsdcon_2013_time_t/mgp0002...](http://www.openbsd.org/papers/eurobsdcon_2013_time_t/mgp00029.html)

I don't see why it would be a good idea to convert "time_t" to "long long".
Having an alias specifically for time_t is part of what makes this kind of
work doable. I could see maybe introducing another alias like "time64_t" or
something, but once you convert it to "long long" the type is no longer tagged
in a way that makes it easy to find and more importantly suggests to the
programmer they ought to NOT make assumptions about its size. Heck, in a
perfect world I'd either introduce a new % symbol specifically for time_t
width or have a macro that expands to represent its width (not to mention make
it mandatory to use compiler warnings about string formats not matching
argument widths).

I also found the comment about "would love better compiler tools -- none found
so far". Certainly there are things like Sparse
([https://sparse.wiki.kernel.org/index.php/Main_Page](https://sparse.wiki.kernel.org/index.php/Main_Page))
which correctness verification easier.

~~~
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...](http://www.openbsd.org/cgi-
bin/cvsweb/src/sys/kern/kern_clock.c.diff?r1=1.81;r2=1.82)

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.

------
pjbringer
I notice the ideas that it is not the number of contributors that matter, but
the number of sufficiently skilled ones, and the that popularity impedes
change. I can't help draw a parallel with the advice that you should listen to
your most valuable customers, and potential customers, and that the rest of
your users will expect free stuff, and complain loudly when you pivot.

------
liveoneggs
NetBSD did this a while ago, but was better about binary compatibility and
things.

[http://www.netbsd.org/changes/changes-6.0.html#time_t](http://www.netbsd.org/changes/changes-6.0.html#time_t)

------
alextingle
Any idea why they would use long long rather than int64_t?

~~~
sirclueless
int64_t is a userspace libc typedef. long long is ICO C (C99) and guaranteed
to be 64 bits or more.

~~~
alextingle
So stdint.h not available to kernel programmers. Thanks.

~~~
_kst_
stdint.h may not be available, but int64_t is; it's defined in
include/linux/types.h.

~~~
alayne
The OpenBSD kernel probably doesn't use Linux headers.

~~~
asveikau
A few times I got flamed on this site for complaining that the average HNer
can't have reasonable discussions about C. I think the comment that the
OpenBSD team should just #include <linux/types.h> pretty well shows that I was
right. :-)

~~~
_kst_
Just a silly mistake on my part.

------
eliteraspberrie
The C standard only states that time_t is an integer (or floating-point) type,
and POSIX further states it represents seconds since the epoch, so a 64-bit
time_t is a good solution.

In order to find and change occurrences of time_t in ports more easily, they
could use the Coccinelle tool.[1] The following semantic patch would find and
replace variable declarations of type time_t:

    
    
        @sys_types@
        @@
        #include <sys/types.h>
        
        @time_t depends on sys_types@
        identifier x;
        @@
        - time_t x
        + long long int x
          ;
    

Replacing printf format specifiers is more difficult, so the following
semantic patch will find printf statements which use time_t variables, which
can then be edited manually:

    
    
        @sys_types@
        @@
        #include <sys/types.h>
        
        @stdio@
        @@
        #include <stdio.h>
        
        @printf depends on sys_types && stdio@
        identifier x;
        @@
          time_t x;
          ...
        * printf(..., x, ...);
    

These can be used as follows:

    
    
        $ spatch --sp-file foo.cocci --dir /path/to/ports
    

where `foo.cocci` is the name of one of the semantic patches above.

[1] [http://coccinelle.lip6.fr/](http://coccinelle.lip6.fr/)

------
meshko
Funny they don't mention that starting Visual Studio 2005 time_t is 64bit on
32bit builds.

~~~
tedunangst
How did they resolve compatibility issues with existing code?

~~~
meshko
I assume the same exact way that the presentation describes? Plus they added a
macro you can define to go back to 32bit time_t (which is probably what most
app devs did...)

------
snoonan
It's going to be a long long time_t.

(sorry.)

------
dllthomas
... and I think it's gonna be a long long time.

