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

81–90 of 92 posts

Re: Going long long on time_t

#81

Post by lmm »

drdaeman wrote: post #80
lmm wrote: post #68

Earlier quoted context omitted.

printf("%lld", (int64_t) t); wouldn't build on a system that doesn't have int64_t, so one needs to use long long.

Why cast to `int64_t` here? Just because `time_t` could be `int64_t` under the hood doesn't mean it must be casted to this exact type for string formatting/presentation purposes. And I thought `%lld` actually means `long long`... So, http://ideone.com/SJJFPs seems like a proper approach to me. That said, if compiler supports %lld (an %I64d or alike might be required for older compilers), so a better cross-compiler ap…

Assuming we don't want to maintain a set of per-platform macros, we need to use an existing, standard format specifier. There isn't one that takes a time_t. So we have to cast time_t to a type big enough to contain it, use the format specifier for that type, and we want this to be as cross-platform as possible, i.e. we use the oldest, most widely-supported type which can definitely hold at least 64 bits and has a standard printf specifier available. i.e. "long long", exactly as in your example code.

So that's why we prefer "long long" rather than "int64_t", which I thought was your original question.

Re: Going long long on time_t

#82

Post by drdaeman »

lmm wrote: post #81
drdaeman wrote: post #80

Earlier quoted context omitted.

Why cast to `int64_t` here? Just because `time_t` could be `int64_t` under the hood doesn't mean it must be casted to this exact type for string formatting/presentation purposes. And I thought `%lld` actually means `long long`... So, http://ideone.com/SJJFPs seems like a proper approach to me. That said, if compiler supports %lld (an %I64d or alike might be required for older compilers), so a better cross-compiler ap…

Assuming we don't want to maintain a set of per-platform macros, we need to use an existing, standard format specifier. There isn't one that takes a time_t. So we have to cast time_t to a type big enough to contain it, use the format specifier for that type, and we want this to be as cross-platform as possible, i.e. we use the oldest, most widely-supported type which can definitely hold at least 64 bits and has a sta…

Oh. I thought the discussion was not about what type to cast when using printf (I agree, only `%lld`/`long long` fits perfectly), but what type to use for `time_t` internally. Sorry if I misunderstood and missed the point.

Re: Going long long on time_t

#83

Post by JoachimS »

gizzlon wrote: 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…

Yes, and that some embedded 32-bit systems deployed today will be in service come 2038. And quite probably some 16-bit, 8-bit ones too.

Re: Going long long on time_t

#84

Post by _kst_ »

alayne wrote: post #33
_kst_ wrote: post #16

Earlier quoted context omitted.

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

The OpenBSD kernel probably doesn't use Linux headers.

Yeah, good point.

I'm not familiar with the OpenBSD kernel. Is there any good reason (for OpenBSD or any other kernel) why shouldn't be available -- or at least why int64_t shouldn't be available in some header?

Re: Going long long on time_t

#85

Post by _kst_ »

asveikau wrote: post #45
alayne wrote: post #33

Earlier quoted context omitted.

The OpenBSD kernel probably doesn't use Linux headers.

A few times I got flamed on this site for complaining that the average HNer can't have reasonable discussions about C. I think the comment that the OpenBSD team should just #include pretty well shows that I was right. :-)

Just a silly mistake on my part.

Re: Going long long on time_t

#86

Post by Peaker »

tedunangst wrote: post #74
cmccabe wrote: 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.

You're whooshing.

You don't want to use "long long" because that's not necessarily 64-bits. You want to use int64_t which guarantees it is 64-bits.

And then, the correct format specifier for that is PRIi64, and not "%ld" or "%lld" which will break in different platforms.

Re: Going long long on time_t

#87

Post by thaumaturgy »

gizzlon wrote: 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've gotten their paychecks, report cards would not have worked, DNS would have stopped working for the entire school network, and finance & budget would have had some really crazy errors in the output -- those are the systems I still remember requiring the most attention.

Y2K was a "debacle" because a bunch of people busted their asses fixing old code.

It feels a lot like pulling two consecutive all-nighters as an engineer on a project, to bring the project up to its deadline on-time and under-budget, only to have your department manager the next morning stroll in, well-rested, coffee cup in hand, and say, "See? Told you it was no big deal."

Re: Going long long on time_t

#88

Post by [deleted] »

thaumaturgy wrote: post #87
gizzlon wrote: 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…

[deleted]

Re: Going long long on time_t

#89

Post by yew »

tedunangst wrote: post #73
yew wrote: post #41

Earlier quoted context omitted.

I've always felt that the 'right' solution was to emulate glibc and provide facilities for registering new format specifiers[1]. Then libraries could provide specifiers for everything that made sense and users could pick and choose. Of course, there would be performance implications - not to mention the added complexity for implementors. [1] http://www.gnu.org/software/libc/manual/html_node/Customizin...

What happens when your graphics library and your network library pick the same letter?

The simplest solution (from the implementor's perspective) is probably to leave it to the user to reassign one. Allowing multiple-letter specifiers helps here. Coming from a C perspective, that's what I would prefer.

You could work out all sorts of namespacing and automatic reassignment schemes, of course.

I can't think of anything without trade-offs off the top of my head (I double that anything exists), but in my (limited) experience it's very workable.

Re: Going long long on time_t

#90

Post by eddieh »

spongle wrote: post #59
p1mrx wrote: post #19

Earlier quoted context omitted.

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

True, but the font detracts from the technical content. Presentation of information is important. There are cognitive and psychologic implications that your reader will incur when reading a document written in Comic Sans. There is nothing to be gained from using Comic Sans and it's not difficult to simply not use the font.
Post reply on HN