Going long long on time_t

http://www.openbsd.org/papers/eurobsdcon_2013_time_t/

by hebz0rl • 13 years ago

130 88 13 years ago

openbsd.org

throwaway_yy2Di• 13 years ago

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...

etc.

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

https://gist.github.com/anonymous/6757266/raw/3469464cb802e7...

simias• 13 years ago

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.

tiziano88• 13 years ago

Comic saaaaaaaaans!

parennoob• 13 years ago

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).

jensenbox• 13 years ago

No humor at all, it is real and frankly, I am worried for my children. http://y2038.com/

enneff• 13 years ago

WTF. I'm not sure I want to live in a world where plain text should elicit such a reaction!

alextingle3• 13 years ago

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

sirclueless• 13 years ago

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

alextingle3• 13 years ago

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

_kst_4• 13 years ago

<time.h> is userspace. It's at least theoretically possible for long long to be more than 64 bits. Why use long long (potentially, say, 128 bits) rather than int64_t for time_t?

And why wouldn't int64_t be available in kernel space?

mrb2• 13 years ago

int64_t is in the ICO C(C99) standard: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n869/n869.pd...

tedunangst8• 13 years ago

How do you think the int64_t type is constructed? Few problems are solved by endless stacks of typedefs.

Peaker6• 13 years ago

int64_t is a much nicer type than "long long".

"int" makes some sense. Word-size of the machine.

"short", "long", "long long" are all non-sensical. You use them when you want to trade size and range. When you want to make that trade-off, you care what their sizes are.

Instead of lower/upper bounds on their sizes, which aren't very useful, they should just have specific sizes. At which point, you might as well use uint32_t, and uint64_t in place of long and long long.

Prefer the sized int types over the "long"/"long long" ones when you can, for saner coding.

Use uintptr_t and such when you need a ptr-sized int, rather than a specific size.

dmm4• 13 years ago

Imagine you just called time(2) and got a time_t value. Something like:

    time_t asdf = time();

And now you want to use printf to print that value to the screen. You can cast to 'long long', which is guaranteed to be at at least 64 bits wide, and ensure no loss of precision occurs:

    printf("%lld", (long long)asdf);

That will work whether time_t is 32 bit or 64 bit.

Peaker6• 13 years ago

If they just added a macro to inttypes.h, you could use that for the format specifier. If you want to print a uint32_t, you just use PRIu32.

cbsmith9• 13 years ago

So, this slide confused/troubled me: http://www.openbsd.org/papers/eurobsdcon_2013_time_t/mgp0002...

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) which correctness verification easier.

dmm4• 13 years ago

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.

cbsmith9• 13 years ago

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• 13 years ago

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

tedunangst8• 13 years ago

Introducing a new format specifier for every typedef will quickly exhaust the alphabet.

dmm4• 13 years ago

In 292 billion years when we overflow a 'long long' time_t humanity is really going to regret that flippant attitude.

cbsmith9• 13 years ago

I agree, and consider that one of the inherent problems with the string formatter approach to IO. That said, time is perhaps one of the data types that is universal enough and general enough to the C runtime that you could make a case for it.

rjsw• 13 years ago

The slides are confusing to me too, another slide [1] states that they will change time_t to be "long long" in a future release so the tagged type will still be there.

I'm also not sure why the OpenBSD people think that there will be lots of problems with ports [2], I'm typing this on a NetBSD system with 64 bit time_t, things that broke have had patches pushed upstream.

[1] http://www.openbsd.org/papers/eurobsdcon_2013_time_t/mgp0003... [2] http://www.openbsd.org/papers/eurobsdcon_2013_time_t/mgp0003...

Peaker6• 13 years ago

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

  "%" PRI_TIME_T

tedunangst8• 13 years ago

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

aidenn0• 13 years ago

Any idea of the motivation behind that?

dietrichepp• 13 years ago

It doesn't solve the problem.

    time_t x = ...;
    printf("%lld\n", (long long) x);

The above code works on any platform, as long as time_t contains no values that do not fit in long long. Using a macro for the format specifier would require defining such a macro on other systems, because they have to be able to compile much of this code on Linux, OS X, or even Windows in some cases.

cbsmith9• 13 years ago

Using a macro for the format specifier would require defining such a macro on other systems, because they have to be able to compile much of this code on Linux, OS X, or even Windows in some cases.

    #ifdef LONG_LONG_TIME_T
    #define PRI_TIME_T "lld"
    #else
    #define PRI_TIME_T "ld"
    #endif

There, I just made it so that you can do:

    time_t x = ...;
    printf("%" PRI_TIME_T "\n", x);

I don't much like how it looks, but it works and it'd be easy to make portable code with it. All you need is a preprocessor flag to indicate when you were using long long.

The real problem is that it'd be easier to get old embedded systems upgraded to 64-bit in the next 25 years than to get those old systems retrofitted with such an annoying syntax. Forcing everything to a know and use a "wide enough" integer width is probably the best you can really do with format strings anyway.

pjbringer• 13 years ago

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.

snoonan• 13 years ago

It's going to be a long long time_t.

(sorry.)

liveoneggs• 13 years ago

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

gizzlon2• 13 years ago

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".

JoachimS• 13 years ago

Yes, and that some embedded 32-bit systems deployed today will be in service come 2038. And quite probably some 16-bit, 8-bit ones too.

thaumaturgy• 13 years ago

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."

gizzlon2• 13 years ago

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 =/

dllthomas• 13 years ago

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

meshko2• 13 years ago

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

tedunangst8• 13 years ago

How did they resolve compatibility issues with existing code?

meshko2• 13 years ago

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...)

eliteraspberrie• 13 years ago

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/

Going long long on time_t

Related Stories