Is there any way to compute the width of an integer type at compile-time?
Solution 1:
There is a function-like macro that can determine the value bits of an integer type, but only if you already know that type's maximum value. Whether or not you'll get a compile-time constant depends on your compiler but I would guess in most cases the answer is yes.
Credit to Hallvard B. Furuseth for his IMAX_BITS() function-like macro that he posted in reply to a question on comp.lang.c
/* Number of bits in inttype_MAX, or in any (1<<b)-1 where 0 <= b < 3E+10 */
#define IMAX_BITS(m) ((m) /((m)%0x3fffffffL+1) /0x3fffffffL %0x3fffffffL *30 \
+ (m)%0x3fffffffL /((m)%31+1)/31%31*5 + 4-12/((m)%31+3))
IMAX_BITS(INT_MAX) computes the number of bits in an int, and IMAX_BITS((unsigned_type)-1) computes the number of bits in an unsigned_type. Until someone implements 4-gigabyte integers, anyway:-)
And
/* Number of bits in inttype_MAX, or in any (1<<k)-1 where 0 <= k < 2040 */
#define IMAX_BITS(m) ((m)/((m)%255+1) / 255%255*8 + 7-86/((m)%255+12))
**Remember that although the width of an unsigned integer type is equal to the number of value bits, the width of a signed integer type is one greater (§6.2.6.2/6).** This is of special importance as in my original comment to your question I had incorrectly stated that the IMAX_BITS() macro calculates the width when it actually calculates the number of value bits. Sorry about that!
So for example IMAX_BITS(INT64_MAX) will create a compile-time constant of 63. However, in this example, we are dealing with a signed type so you must add 1 to account for the sign bit if you want the actual width of an int64_t, which is of course 64.
In a separate comp.lang.c discussion a user named blargg gives a breakdown of how the macro works:
Re: using pre-processor to count bits in integer types...
Note that the macro only works with 2^n-1 values (ie all 1s in binary), as would be expected with any MAX value. Also note that while it is easy to get a compile-time constant for the maximum value of an unsigned integer type (IMAX_BITS((unsigned type)-1)), at the time of this writing I don't know any way to do the same thing for a signed integer type without invoking implementation-defined behavior. If I ever find out I'll answer my own related SO question, here:
C question: off_t (and other signed integer types) minimum and maximum values - Stack Overflow
Solution 2:
Compare the macros from <limits.h> against known max values for specific integer widths:
#include <limits.h>
#if UINT_MAX == 0xFFFF
#define INT_WIDTH 16
#elif UINT_MAX == 0xFFFFFF
#define INT_WIDTH 24
#elif ...
#else
#error "unsupported integer width"
#endif
Solution 3:
First approach, if you know what standard type you have (so your type is no typedef) go with the {U}INT_MAX macros and check against the possible sizes.
If you don't have that, for unsigned types this is relatively easy conceptually. For your favorite type T, just do (T)-1 and do a monster test macro that checks against all possible values with ?:. Since these then are only compile time constant expressions, any decent compiler will optimize that out a leave you with just the value that you are interested in.
This wouldn't work in #if etc, because of the type cast, but this can't be avoided in a simple way.
For signed types this is more complicated. For types at least as wide as int you can hope to do a trick to promote to the corresponding unsigned type and get the width of that type then. But to know whether or not your signed type has just one value bit less or not, no I don't think that there is a generic expression to know that.
Edit: Just to illustrate this a bit, I give some extracts of what you can do to make this approach (for unsigned types) not generate too large expressions in P99 I have something like
#ifndef P99_HIGH2
# if P99_UINTMAX_WIDTH == 64
# define P99_HIGH2(X) \
((((X) & P00_B0) ? P00_S0 : 0u) \
| (((X) & P00_B1) ? P00_S1 : 0u) \
| (((X) & P00_B2) ? P00_S2 : 0u) \
| (((X) & P00_B3) ? P00_S3 : 0u) \
| (((X) & P00_B4) ? P00_S4 : 0u) \
| (((X) & P00_B5) ? P00_S5 : 0u))
# endif
#endif
#ifndef P99_HIGH2
# if P99_UINTMAX_WIDTH <= 128
# define P99_HIGH2(X) \
((((X) & P00_B0) ? P00_S0 : 0u) \
| (((X) & P00_B1) ? P00_S1 : 0u) \
| (((X) & P00_B2) ? P00_S2 : 0u) \
| (((X) & P00_B3) ? P00_S3 : 0u) \
| (((X) & P00_B4) ? P00_S4 : 0u) \
| (((X) & P00_B5) ? P00_S5 : 0u) \
| (((X) & P00_B6) ? P00_S6 : 0u))
# endif
#endif
where the magic constants are defined with a sequence of #if at the beginning. There it is important to not to expose too large constants for compilers that can't handle them.
/* The preprocessor always computes with the precision of uintmax_t */
/* so for the preprocessor this is equivalent to UINTMAX_MAX */
#define P00_UNSIGNED_MAX ~0u
#define P00_S0 0x01
#define P00_S1 0x02
#define P00_S2 0x04
#define P00_S3 0x08
#define P00_S4 0x10
#define P00_S5 0x20
#define P00_S6 0x40
/* This has to be such ugly #if/#else to ensure that the */
/* preprocessor never sees a constant that is too large. */
#ifndef P99_UINTMAX_MAX
# if P00_UNSIGNED_MAX == 0xFFFFFFFFFFFFFFFF
# define P99_UINTMAX_WIDTH 64
# define P99_UINTMAX_MAX 0xFFFFFFFFFFFFFFFFU
# define P00_B0 0xAAAAAAAAAAAAAAAAU
# define P00_B1 0xCCCCCCCCCCCCCCCCU
# define P00_B2 0xF0F0F0F0F0F0F0F0U
# define P00_B3 0xFF00FF00FF00FF00U
# define P00_B4 0xFFFF0000FFFF0000U
# define P00_B5 0xFFFFFFFF00000000U
# define P00_B6 0x0U
# endif /* P00_UNSIGNED_MAX */
#endif /* P99_UINTMAX_MAX */
#ifndef P99_UINTMAX_MAX
# if P00_UNSIGNED_MAX == 0x1FFFFFFFFFFFFFFFF
# define P99_UINTMAX_WIDTH 65
# define P99_UINTMAX_MAX 0x1FFFFFFFFFFFFFFFFU
# define P00_B0 0xAAAAAAAAAAAAAAAAU
# define P00_B1 0xCCCCCCCCCCCCCCCCU
# define P00_B2 0xF0F0F0F0F0F0F0F0U
# define P00_B3 0xFF00FF00FF00FF00U
# define P00_B4 0xFFFF0000FFFF0000U
# define P00_B5 0xFFFFFFFF00000000U
# define P00_B6 0x10000000000000000U
# endif /* P00_UNSIGNED_MAX */
#endif /* P99_UINTMAX_MAX */
.
.
.
Solution 4:
A general observation is that if you rely on the width of a data type in your calculations, you should use the explicit width data types defined in <stdint.h> e.g. uint32_t.
Trying to count the bytes in the standard types is begging the question of what your 'portable' code would do in the event of an overflow.