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

41–50 of 92 posts

Re: Going long long on time_t

#41

Post by yew »

cbsmith wrote: post #32
tedunangst wrote: post #20

Earlier quoted context omitted.

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.

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

Re: Going long long on time_t

#43

Post by asveikau »

Peaker wrote: post #35
tedunangst wrote: post #27

Earlier quoted context omitted.

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

> rejecting a standard C header file because it is "ugly"

I just checked an OpenBSD machine's inttypes.h. Some of the format macros (I presume the ones present in the standard) are there. So I can't say they rejected the header.

It would probably be weird to introduce one there that isn't in the standard. OTOH %lld for long long is in the standard.

Re: Going long long on time_t

#44

Post by gilgoomesh »

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…

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.

You can use "long long" without headers in most C compilers from the last 20 years. int64_t when present is usually just a typedef to "long long". Keep it simple.

> "int" makes some sense. Word-size of the machine.

Except that it isn't. That was its original intent but for historical reasons, it is a 32 bit integer in almost all cases now, regardless of machine word size.

Re: Going long long on time_t

#45

Post by asveikau »

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.

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

Re: Going long long on time_t

#46

Post by dietrichepp »

Peaker wrote: post #12

For format strings, why not do the inttypes.h thing, and define a macro for the format specifier of (time_t)? "%" PRI_TIME_T

It doesn't solve the problem.

    time_t x = ...;
    printf("%lld\n", (long long) x);
The above code works on any platform, as long as time_t contains no values that do not fit in long long. 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.

Re: Going long long on time_t

#47

Post by justincormack »

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…

Yes that's about right. The videos will be up at some point but it was a two phase process like that.

Re: Going long long on time_t

#48

Post by cmccabe »

tedunangst wrote: post #40
Peaker wrote: post #38

Earlier quoted context omitted.

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.

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

Re: Going long long on time_t

#49

Post by drdaeman »

gilgoomesh wrote: post #44
Peaker wrote: post #38

Earlier quoted context omitted.

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…

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?

Re: Going long long on time_t

#50

Post by rwmj »

ciupicri wrote: post #29
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…

It's 2013 and there are tons of programs that can generate a decent HTML based presentation from a text file. Heck, I've encountered one just today while looking at the slides for "fedmsg - The Fedora Infrastructure Message Bus" [1]; the tool is named hovercraft [2]. Another nice tool is landslide [3]. [1]: http://threebean.org/presentations/fedmsg-flock13/ [2]: http://hovercraft.readthedocs.org/ [3]: https://github.…

Or just use HTML (rendered with Webkit):

http://rwmj.wordpress.com/2012/01/31/tech-talk-pse-1-1-0/#co...

and embed terminals and other programs along the way.

Post reply on HN