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

31–40 of 92 posts

Re: Going long long on time_t

#31

Post by cbsmith »

dmm wrote: post #18
cbsmith wrote: post #10

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…

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

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.

Re: Going long long on time_t

#32

Post by cbsmith »

tedunangst wrote: post #20
cbsmith wrote: post #10

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…

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

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.

Re: Going long long on time_t

#35

Post by Peaker »

tedunangst wrote: post #27
aidenn0 wrote: post #26

Earlier quoted context omitted.

Any idea of the motivation behind that?

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

Re: Going long long on time_t

#36

Post by mrb »

sirclueless wrote: post #8
alextingle wrote: post #7

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

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

Re: Going long long on time_t

#37

Post by Peaker »

dmm wrote: post #25
alextingle wrote: post #7

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

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.

Re: Going long long on time_t

#38

Post by Peaker »

tedunangst wrote: post #22
alextingle wrote: post #7

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

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

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.

Re: Going long long on time_t

#39

Post by claudius »

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.

It might have been difficult to combine blinking GIFs with JPEG artefacts – that said, it wasn't all that bad with the mouse on the ‘next’ link and tapping of the left mouse button to read the next slide, at least it works in Opera :)

Re: Going long long on time_t

#40

Post by tedunangst »

Peaker wrote: post #38
tedunangst wrote: post #22

Earlier quoted context omitted.

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

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

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