How long does it take you to code a program if you are being bogged down by such simple problems? Use ints and do bounds checking when it's necessary to do so. Is every single bucket of information a reinvention of types?

int, long. The standard specifies their minimum sizes.

Or include cstdint and use the fast or least types as needed.

It specifies the minimum sizes, in the sense that sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) etc... but no requirements on how big they actually are. You could (in theory) end up with all of those being 9 bits wide on some weird platform.

No, they cannot all be 9 bits, they have higher minimums.

https://en.wikipedia.org/wiki/C_data_types#Basic_types

X86 has also had saturation arithmetic since MMX was introduced.

.... However, unless you use non portable intrinsics, you can't make the compiler use MMX. So in practice you get wrap on overflow.

Worse, the compiler is entitled to use saturation arithmetic if you've assumed wrapping.

> Worse, the compiler is entitled to use saturation arithmetic if you've assumed wrapping.

C89 (draft[1], because the actual spec is not public) section 3.1.2.5 states:

> ... a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting unsigned integer type.

So, unless I'm misunderstanding, the compiler is not entitled to use saturation arithmetic on unsigned integers.

[1] http://port70.net/~nsz/c/c89/c89-draft.html

signed and unsigned have different semantics.

The compiler is allowed to do literally anything on signed overflow, including launching the missiles, and not running the program. Or both.

You can build portable libraries on top of nonportable primitives.

You should never rely on the underlying CPU architecture's behavior on integer overflow when you write C or C++. It is undefined and not unspecified or implementation defined.

Undefined behaviour is undefined only by the standard - an implementation may choose to handle undefined behaviour in some documented, specific fashion. Undefined behaviour exists to give implementations exactly this flexibility.

> an implementation may choose to handle undefined behaviour in some documented, specific fashion

Or they can leave it undefined and not make any guarantees. I do not think that any compilers on any platform makes any guarantee on signed overflow.

true, but the behavior of unsigned integers is defined such that they can't overflow. the "wrapping" behavior of unsigned ints is defined: you get the arithmetic result modulo the max value for that width.

You can store year 1850-2050 in a byte.

I've been programming in C and C++ for almost 30 years. This has never been a problem for me.

> I agree with that statement. How can you use type when you don't know range of values.

That might be a question for developers of the billons of lines of C++ in production. Asking them, you'd discover how they they actually use the builtin types.