Any guaranteed minimum sizes for types in C?

This is covered in the Wikipedia article:

A short int must not be larger than an int.
An int must not be larger than a long int.

A short int must be at least 16 bits long.
An int must be at least 16 bits long.
A long int must be at least 32 bits long.
A long long int must be at least 64 bits long.

The standard does not require that any of these sizes be necessarily different. It is perfectly valid, for example, if all four types are 64 bits long.

Yes, the values in float.h and limits.h are system dependent. You should never make assumptions about the width of a type, but the standard does lay down some minimums. See §6.2.5 and §5.2.4.2.1 in the C99 standard.

For example, the standard only says that a char should be large enough to hold every character in the execution character set. It doesn't say how wide it is.

For the floating-point case, the standard hints at the order in which the widths of the types are given:

§6.2.5.10

There are three real floating types, designated as float, double, and long double. ³²⁾ The set of values of the type float is a subset of the set of values of the type double; the set of values of the type double is a subset of the set of values of the type long double.

They implicitly defined which is wider than the other, but not specifically how wide they are. "Subset" itself is vague, because a long double can have the exact same range of a double and satisfy this clause.

This is pretty typical of how C goes, and a lot is left to each individual environment. You can't assume, you have to ask the compiler.

Nine years and still no direct answer about the minimum size for float, double, long double.

Any guaranteed minimum sizes for types in C?

For floating point type ...

From a practical point-of-view, float minimum size is 32-bits and double is 64- bits. C allows double and long double to share similar characteristics, so a long double could be as small as a double: Example¹ or 80-bit or 128-bit or ...

I could imagine a C compliant 48-bit double may have existed – yet do not know of any.

Now, let us imagine our rich uncle dies and left us a fortune to pay for the development and cultural promotion for www.smallest_C_float.com.

C specifies:

1. float finite range is at least [1E-37… 1E+37]. See FLT_MIN, FLT_MAX

2. (1.0f + FLT_EPSILON) – 1.0f <= 1E-5.

3. float supports positive and negative values.

   Let X: Digit 1-9 Let Y: Digit 0-9 Let E: value -37 to 36 Let S: + or - Let b: 0 or 1

Our float could minimally represent all the combinations, using base 10, of SX.YYYYY*10^E.

0.0 and ±1E+37 are also needed (3 more). We do not need -0.0, sub-normals, ±infinity nor not-a-numbers.

That is 2910^5*74 + 3 combinations or 133,200,003 which needs at least 27 bits to encode - somehow. Recall the goal is minimal size.

With a classic base 2 approach, we can assume an implied 1 and get S1.bbbb_bbbb_bbbb_bbbb_b2^e or 22^17*226 combinations or 26 bits.

If we try base 16, we then need about 21516^(4 or 5)*57 combinations or at least 26 to 30 bits.

Conclusion: A C float needs at least 26 bits of encoding.

A C’s double need not express a greater exponential range than float, it only has a different minimal precision requirement. 1E-9.

S1.bbbb_bbbb_bbbb_bbbb_ bbbb_ bbbb_ bbbb_bb2^e --> 22^30*226 combinations or 39 bits.

On our imagine-if-you-will computer, we could have a 13-bit char and so encode float, double, long double without padding. Thus we can realize a non-padded 26-bit float and 39-bit double, long double.

¹: Microsoft Visual C++ for x86, which makes long double a synonym for double

[Edit] 2020

Additional double requirements may require 41 bits. May have to use 42-bit double and 28-bit float. Will need to review. Uncle will not be happy.

However, the new C99 specifies (in stdint.h) optional types of minimal sizes, like uint_least8_t, int_least32_t, and so on..
(see en_wikipedia_Stdint_h)

Often developers asking this kind of question are dealing with arranging a packed struct to match a defined memory layout (as for a message protocol). The assumption is that the language should directly specify laying out 16-, 24-, 32-bit, etc. fields for the purpose.

That is routine and acceptable for assembly languages and other application-specific languages closely tied to a particular CPU architecture, but is sometimes a problem in a general purpose language which might be targeted at who-knows-what kind of architecture.

In fact, the C language was not intended for a particular hardware implementation. It was specified generally so a C compiler implementer could properly adapt to the realities of a particular CPU. A Frankenstein hardware architecture consisting of 9 bit bytes, 54 bit words, and 72 bit memory addresses is easily—and unambiguously—mapped to C features. (char is 9 bits; short int, int, and long int are 54 bits.)

This generality is why the C specification says something to the effect of "don't expect much about the sizes of ints beyond sizeof (char) <= sizeof (short int) <= sizeof (int) <= sizeof (long int)." That implies that chars could be the same size as longs!

The current reality is—and the future seems to hold—that software demands architectures provide 8-bit bytes and that memory words addressable as individual bytes. This wasn't always so. Not too long ago, I worked on an the CDC Cyber architecture which features 6 bit "bytes" and 60 bit words. A C implementation on that would be interesting. In fact, that architecture is responsible for the weird packing semantics of Pascal—if anyone remembers that.