Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Going long long on time_t

openbsd.org

Post reply on HN
Print view View original

51–60 of 92 posts

Re: Going long long on time_t

#51

Post by lloeki »

mistercow wrote: post #24
parennoob wrote: post #5

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…

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.

Re: Going long long on time_t

#52

Post by cbsmith »

dietrichepp wrote: post #46
Peaker wrote: post #12

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

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.

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

Re: Going long long on time_t

#53

Post by masklinn »

Peaker wrote: post #37
dmm wrote: post #25

Earlier quoted context omitted.

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.

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.

> you could use that for the format specifier.

And end up with even more horrible and less readable format strings.

Re: Going long long on time_t

#54

Post by cbsmith »

Peaker wrote: post #35
tedunangst wrote: post #27

Earlier quoted context omitted.

It's ugly.

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

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

Re: Going long long on time_t

#55

Post by cbsmith »

mrb wrote: post #36
sirclueless wrote: post #8

Earlier quoted context omitted.

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

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

Yes... as a typedef in . In other words, "a userspace libc typedef" as the previous post said...

Re: Going long long on time_t

#57

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

Re: Going long long on time_t

#58

Post by Peaker »

masklinn wrote: post #53
Peaker wrote: post #37

Earlier quoted context omitted.

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.

> you could use that for the format specifier. And end up with even more horrible and less readable format strings.

So we should use unportable format strings or cast all the values to long long? Is that better?

I personally find inttypes format strings readable.

Re: Going long long on time_t

#59

Post by spongle »

p1mrx wrote: post #19
parennoob wrote: post #5

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…

> What's so horrible about it? It's Comic Sans with JPEG artifacts. The only consolation is that it doesn't blink.

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

Re: Going long long on time_t

#60

Post by lmm »

cbsmith wrote: post #52
dietrichepp wrote: post #46

Earlier quoted context omitted.

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.

> 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 you repeat that macro in every file? Or you assume you can somehow persuade other OSes to add it to their headers?

printf("%lld\n", (long long) x); is ugly but it works on every system, including existing systems with 32-bit time_t that don't make any changes to their headers.

Post reply on HN