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

11–20 of 92 posts

Re: Going long long on time_t

#13

Post by _kst_ »

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.

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?

Re: Going long long on time_t

#14

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

Re: Going long long on time_t

#15

Post by pslam »

alextingle wrote: post #11
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.

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

I always found this special-casing of headers for kernel vs user unnecessary and complicating. In the many embedded runtimes I maintain, I've moved towards using standard POSIX-y and C(++) standard headers everywhere. I know kernel folks love to believe that their world is special so all the usual C library stuff needs to be done differently, but it's not needed.

It's so much easier to port code between the two worlds when you don't have to litter the #include prelude of every C file with conditionals.

Re: Going long long on time_t

#16

Post by _kst_ »

alextingle wrote: post #11
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.

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

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

Re: Going long long on time_t

#18

Post by dmm »

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

Re: Going long long on time_t

#19

Post by p1mrx »

parennoob wrote: post #5
simias wrote: post #3

Earlier quoted context omitted.

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.

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.

Re: Going long long on time_t

#20

Post by tedunangst »

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.
Post reply on HN