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

61–70 of 92 posts

Re: Going long long on time_t

#61

Post by lmm »

drdaeman wrote: post #49
gilgoomesh wrote: post #44

Earlier quoted context omitted.

You need to realize that the size of most types in C have been perverted by history. When possible, it's best to use the few types that are unambiguous in all of C89, LLP64 and LP64. > int64_t is a much nicer type than "long long". Yes, except that "long long" has been part of the standard for longer. in64_t was part of C99 but is tricky to include in software up to the mid 2000's due to slow adoption of the standard…

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?

It's not the kernel that's the issue, we're talking about basic, cross-platform userland utilities like "ping" here. Some of those do have a policy that they have to be able to build on Irix 5.8 or whatever.

Re: Going long long on time_t

#62

Post by cbsmith »

lmm wrote: post #60
cbsmith wrote: post #52

Earlier quoted context omitted.

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

> And you repeat that macro in every file?

You are familiar with the concept of headers, right? ;-)

Just put that in the project's common header (which if it is dealing with so many different OS's, invariably already have a bunch of platform abstractions). I deliberately structured the solution so the only "extra work" that is needed is for whatever platform has created a long long time_t (and if you really wanted to, you could probably get rid of even that work and base the entire thing off of sizeof(long long) even without using something like autoconf).

> printf("%lld\n", (long long) x); is ugly

Wow, we couldn't be of more different opinions. I'd argue the virtue of that approach is it is less ugly are more likely to be easily accepted as a change for crufty old 32-bit code in some embedded system that everyone has forgotten about.

Re: Going long long on time_t

#63

Post by enneff »

simias wrote: post #3
throwaway_yy2Di wrote: post #2

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

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.

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

Re: Going long long on time_t

#64

Post by rjsw »

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

Re: Going long long on time_t

#65

Post by drdaeman »

lmm wrote: post #61
drdaeman wrote: post #49

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?

It's not the kernel that's the issue, we're talking about basic, cross-platform userland utilities like "ping" here. Some of those do have a policy that they have to be able to build on Irix 5.8 or whatever.

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.

Re: Going long long on time_t

#66

Post by mrb »

cbsmith wrote: post #55
mrb wrote: post #36

Earlier quoted context omitted.

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

sirclueless implied that int64_t was not C99, which is wrong.

Re: Going long long on time_t

#67

Post by cbsmith »

mrb wrote: post #66
cbsmith wrote: post #55

Earlier quoted context omitted.

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

sirclueless implied that int64_t was not C99, which is wrong.

I think if you re-read what was written, what you think was implied was not.

Re: Going long long on time_t

#68

Post by lmm »

drdaeman wrote: post #65
lmm wrote: post #61

Earlier quoted context omitted.

It's not the kernel that's the issue, we're talking about basic, cross-platform userland utilities like "ping" here. Some of those do have a policy that they have to be able to build on Irix 5.8 or whatever.

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.

Re: Going long long on time_t

#70

Post by coldpie »

drdaeman wrote: post #49
gilgoomesh wrote: post #44

Earlier quoted context omitted.

You need to realize that the size of most types in C have been perverted by history. When possible, it's best to use the few types that are unambiguous in all of C89, LLP64 and LP64. > int64_t is a much nicer type than "long long". Yes, except that "long long" has been part of the standard for longer. in64_t was part of C99 but is tricky to include in software up to the mid 2000's due to slow adoption of the standard…

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