[Peaker]

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 uint32_t, and uint64_t in place of long and long long.

Prefer the sized int types over the "long"/"long long" ones when you can, for saner coding.

Use uintptr_t and such when you need a ptr-sized int, rather than a specific size.

[gilgoomesh]

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.

[drdaeman]

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?

[lmm]

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.

[drdaeman]

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.

[lmm]

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

[drdaeman]

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 approach would be in lines of `printf("test: " TIME_FMT "\n", (TIME_FMT_CAST)t)`. Or, ahem, maybe, `print_time(t)`.

[coldpie]

Microsoft's C compiler doesn't have C99 support.

[alextingle]

Microsoft don't make a C compiler.

[tedunangst]

once again, how do the headers conjure up the int64_t type? it's not a keyword.

[cmccabe]

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

[tedunangst]

Wait. You just typed long long. You're not allowed to do that.

[Peaker]

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.

[cmccabe]

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.