Live data from Hacker News

Going long long on time_t

openbsd.org

71–80 of 92 posts

Re: Going long long on time_t

#71
post #51

Earlier quoted context omitted.

Not having any way to navigate without actually clicking the tiny "next" link is infuriating. I can't actually focus on the subject matter if I have to do that.

> the tiny "next" link Once you zeroed in on the link, it's not like you have to move the mouse away, and its Fitt size becomes essentially infinite past the first slide.

Only if your screen is large enough that you don't have to scroll down.

Re: Going long long on time_t

#73
post #41
post #32

Earlier quoted context omitted.

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.

I've always felt that the 'right' solution was to emulate glibc and provide facilities for registering new format specifiers[1]. Then libraries could provide specifiers for everything that made sense and users could pick and choose. Of course, there would be performance implications - not to mention the added complexity for implementors. [1] http://www.gnu.org/software/libc/manual/html_node/Customizin...

What happens when your graphics library and your network library pick the same letter?

Re: Going long long on time_t

#74
post #48

Earlier quoted context omitted.

once again, how do the headers conjure up the int64_t type? it's not a keyword.

Here is how stdint.h on Linux conjures up the int64_t type. #if __WORDSIZE == 64 typedef long int int64_t; #else typedef long long int int64_t; #endif

Wait. You just typed long long. You're not allowed to do that.

Re: Going long long on time_t

#76
post #70

Earlier quoted context omitted.

I fail to see why it's more reasonable to prefer "long long" to "int64_t" just because the former existed for longer. It's not year 2000 today and C99's not a hot new thing not many compilers support. Or OpenBSD do have some policy that their kernel must be able to build with any C89-compliant compiler?

Microsoft's C compiler doesn't have C99 support.

Microsoft don't make a C compiler.

Re: Going long long on time_t

#77
post #72

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

How did they resolve compatibility issues with existing code?

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

Re: Going long long on time_t

#78

Earlier quoted context omitted.

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 actuall…

It's 2013 and there are tons of programs that can generate a decent HTML based presentation from a text file. Heck, I've encountered one just today while looking at the slides for "fedmsg - The Fedora Infrastructure Message Bus" [1]; the tool is named hovercraft [2]. Another nice tool is landslide [3]. [1]: http://threebean.org/presentations/fedmsg-flock13/ [2]: http://hovercraft.readthedocs.org/ [3]: https://github.…

I've been using dzslides (https://github.com/paulrouget/dzslides) and been pretty happy. I wrote my own tool to take markdown and emit dzslides and I've not been upset yet, but my slides tend to be very minimalistic.

Re: Going long long on time_t

#79
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 
    
    @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 
    
    @stdio@
    @@
    #include 
    
    @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/

Re: Going long long on time_t

#80
post #68

Earlier quoted context omitted.

Is there anything that forbids those utilities from using system-provided headers and time_t? I think they'll build fine on any POSIX.1-compliant system then. Unless they're doing something really weird with time_t values, I don't think there's any reason they should know whenever it's long long or int64_t or whatever under the hood.

printf("%lld", (int64_t) t); wouldn't build on a system that doesn't have int64_t, so one needs to use long long.

Why cast to `int64_t` here? Just because `time_t` could be `int64_t` under the hood doesn't mean it must be casted to this exact type for string formatting/presentation purposes.

And I thought `%lld` actually means `long long`... So, http://ideone.com/SJJFPs seems like a proper approach to me. That said, if compiler supports %lld (an %I64d or alike might be required for older compilers), so a better cross-compiler approach would be in lines of `printf("test: " TIME_FMT "\n", (TIME_FMT_CAST)t)`. Or, ahem, maybe, `print_time(t)`.

Post reply on HN