The only type worse than 'int' is 'long'.

it's really a tie between "int", "long" and DWORD (though thankfully DWORD never made it into a language standard).

I would put "char" in the running now that we (thankfully) live in an increasingly UTF-8 world, but at least it's more or less universally understood to mean an 8 bit entity (even though this is not strictly true). It certainly isn't "a character".

long is definitely worse than int. At least you know int is never 64-bit on desktops, and it comes in handy enough for things like logarithms. long being either 32-bit or 64-bit on the same platform depending on the compiler just feels like insanity.

It's absolutely insanity. A cruel question I came up with the other day, based on it - What is the result of:

    std::is_signed<decltype(1L * 2U)>()

?

Why should it be cruel? Promotions are a part of life of an integer in C.

Even programmers who are roughly aware of integral promotion rules may not have connected all the dots to realize the answer is implementation dependent.

If sizeof(long) == sizeof(unsigned int), 1L * 2U results in an unsigned int, meaning the result is "false".

If sizeof(long) > sizeof(unsigned int), 1L * 2U result in a signed long, meaning the result is "true".

Wow that is cruel! Somehow I just assumed int would get promoted to long regardless of their size difference. That this isn't the case almost seems like a language defect!

I used intmax_t just yesterday in an ODBC type conversion test. I wrote a template for use in a Google Test typed test to find the highest and lowest values supported by the client and server type. Something like:

  max(
    static_cast<intmax_t>(
      numeric_limits<T>::lowest()),
    static_cast<intmax_t>(
      numeric_limits<U>::lowest()))

I tried std::common_type first, but it didn't quite do the trick.

Out of curiosity... did you ever fall into the trap of using

    numeric_limits<T>::min()

instead of

    numeric_limits<T>::lowest()

? Because I did.

The distinction is only relevant for floating point types, is it not?

Yes, I believe so.

Yeah, min() returns the most negative int, so it seems like it should do the same for float. Then the float with the least magnitude could have been, say, smallest().

> at least not in code that is intended to be remotely portable across time, space and architecture.

intmax_t exists probably because most integer types in C are not portable. You can't write C code that uses int64_t and expect it to compile, the type doesn't have to exist, neither do int32_t or int16_t. Say you have a generic int lowestBitSet(intmax_t) function and want to make it available, you don't care how large the input integer is as long as you do not truncate the largest type available to whoever ends up using it. Without intmax_t you end up with library developers having to either setting their own upper limit, limiting the portability of their library or checking for the availability of each type themselves.

I don't use int64_t and expect it to exist. I use int64_t and expect compilation to fail if stdint.h doesn't define it. It would be a problem, but much less of a problem than using intWhatever_t, having compilation work, but having no idea what the bounds were.

intmax_t doesn't define an upper limit either, as TFA explains, because you don't know at runtime what the limit really is.

> but having no idea what the bounds were.

The idea for the library writer are that the bounds are large enough for whatever the user needs. User inputs a int64_t? Great the type intmax_t on that system is at least int64_t wide by definition. System doesn't have a int64_t ? Great the user can at best use a int32_t, which intmax_t would once again support.

> intmax_t doesn't define an upper limit either, as TFA explains

Yeah, it would almost be sad that C++ is getting bitten by Cs lack of name mangling. Almost because it is kinda pointless to define a maximum integer in a language where any programmer can add their own fixed sized integer types, so a generic library supporting arbitrary sized integers would have to take template parameters anyway.

The standard requires longs to be at least 32 bits wide. Then how can int32_t not exist?

And C99 requires long longs to be at least 64 bits wide.

While that isn't really relevant as the sizes used by my example could just be larger (if intmax_t worked as intended, which of course it doesn't), the fixed width types are all optional. For example on systems that use ones complement you would have a intmax_t, but no int32_t or any of the others.

When targeting an 8 or 16 bit processor.