Live data from Hacker News

Going long long on time_t

openbsd.org

91–92 of 92 posts

Re: Going long long on time_t

#91
post #57

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…

> This problem might not be taken seriously after the Y2K debacle. I wish people would stop saying things like that. I was one of many programmers who spent some overtime over the course of about a year on fixing code in 1998-9. I was just the junior programmer at the time; the head guy in the department had some nearly sleepless nights around then. I can promise you that in one East Bay school district, nobody would…

Fair enough, it's not the most fitting term.

I remember a lot of hype and no actual problems. I suspect others do as well, and this could lead to people thinking about the whole problem as over-hyped and a non-issue.

Not saying that it's correct, but that's the catch-22 of preventing problems: If you do a too good job, nobody will notice =/

Re: Going long long on time_t

#92
post #48

Earlier quoted context omitted.

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.

Please don't be disingenuous. We both know that using #defines, you can get a type which is exactly 64 bits on any modern architecture. The fact that long long and long int are a builtin types and int64_t is implemented in terms of them, rather than the other way around, is just an implementation detail.
Post reply on HN