fixed length data types in C/C++

Question

I've heard that size of data types such as int may vary across platforms.

My first question is: can someone bring some example, what goes wrong, when program assumes an int is 4 bytes, but on a different platform it is say 2 bytes?

Another question I had is related. I know people solve this issue with some typedefs, like you have variables like u8,u16,u32 - which are guaranteed to be 8bits, 16bits, 32bits, regardless of the platform -- my question is, how is this achieved usually? (I am not referring to types from stdint library - I am curious manually, how can one enforce that some type is always say 32 bits regardless of the platform??)

Answer 1

I know people solve this issue with some typedefs, like you have variables like u8,u16,u32 - which are guaranteed to be 8bits, 16bits, 32bits, regardless of the platform

There are some platforms, which have no types of certain size (like for example TI's 28xxx, where size of char is 16 bits). In such cases, it is not possible to have an 8-bit type (unless you really want it, but that may introduce performance hit).

how is this achieved usually?

Usually with typedefs. c99 (and c++11) have these typedefs in a header. So, just use them.

can someone bring some example, what goes wrong, when program assumes an int is 4 bytes, but on a different platform it is say 2 bytes?

The best example is a communication between systems with different type size. Sending array of ints from one to another platform, where sizeof(int) is different on two, one has to take extreme care.

Also, saving array of ints in a binary file on 32-bit platform, and reinterpreting it on a 64-bit platform.

Answer 2

In earlier iterations of the C standard, you generally made your own typedef statements to ensure you got a (for example) 16-bit type, based on #define strings passed into the compiler for example:

gcc -DINT16_IS_LONG ...

Nowadays (C99 and above), there are specific types such as uint16_t, the exactly 16-bit wide unsigned integer.

Provided you include stdint.h, you get exact bit width types,at-least-that-width types, fastest types with a given minimum widthand so on, as documented in C99 7.18 Integer types <stdint.h>. If an implementation has compatible types, they are required to provide these.

Also very useful is inttypes.h which adds some other neat features for format conversion of these new types (printf and scanf format strings).

Answer 3

For the first question: Integer Overflow.

For the second question: for example, to typedef an unsigned 32 bits integer, on a platform where int is 4 bytes, use:

 typedef unsigned int u32;

On a platform where int is 2 bytes while long is 4 bytes:

typedef unsigned long u32;

In this way, you only need to modify one header file to make the types cross-platform.

If there are some platform-specific macros, this can be achieved without modifying manually:

#if defined(PLAT1)
typedef unsigned int u32;
#elif defined(PLAT2)
typedef unsigned long u32;
#endif

If C99 stdint.h is supported, it's preferred.

Answer 4

First of all: Never write programs that rely on the width of types like short, int, unsigned int,....

Basically: "never rely on the width, if it isn't guaranteed by the standard".

If you want to be truly platform independent and store e.g. the value 33000 as a signed integer, you can't just assume that an int will hold it. An int has at least the range -32767 to 32767 or -32768 to 32767 (depending on ones/twos complement). That's just not enough, even though it usually is 32bits and therefore capable of storing 33000. For this value you definitively need a >16bit type, hence you simply choose int32_t or int64_t. If this type doesn't exist, the compiler will tell you the error, but it won't be a silent mistake.

Second: C++11 provides a standard header for fixed width integer types. None of these are guaranteed to exist on your platform, but when they exists, they are guaranteed to be of the exact width. See this article on cppreference.com for a reference. The types are named in the format int[n]_t and uint[n]_t where n is 8, 16, 32 or 64. You'll need to include the header <cstdint>. The C header is of course <stdint.h>.

Answer 5

usually, the issue happens when you max out the number or when you're serializing. A less common scenario happens when someone makes an explicit size assumption.

In the first scenario:

int x = 32000;
int y = 32000;
int z = x+y;        // can cause overflow for 2 bytes, but not 4

In the second scenario,

struct header {
int magic;
int w;
int h;
};

then one goes to fwrite:

header h;
// fill in h
fwrite(&h, sizeof(h), 1, fp);

// this is all fine and good until one freads from an architecture with a different int size

In the third scenario:

int* x = new int[100];
char* buff = (char*)x;


// now try to change the 3rd element of x via buff assuming int size of 2
*((int*)(buff+2*2)) = 100;

// (of course, it's easy to fix this with sizeof(int))

If you're using a relatively new compiler, I would use uint8_t, int8_t, etc. in order to be assure of the type size.

In older compilers, typedef is usually defined on a per platform basis. For example, one may do:

 #ifdef _WIN32
      typedef unsigned char uint8_t;
      typedef unsigned short uint16_t;
      // and so on...
 #endif

In this way, there would be a header per platform that defines specifics of that platform.

Answer 6

I am curious manually, how can one enforce that some type is always say 32 bits regardless of the platform??

If you want your (modern) C++ program's compilation to fail if a given type is not the width you expect, add a static_assert somewhere. I'd add this around where the assumptions about the type's width are being made.

static_assert(sizeof(int) == 4, "Expected int to be four chars wide but it was not.");

chars on most commonly used platforms are 8 bits large, but not all platforms work this way.

Answer 7

Well, first example - something like this:

int a = 45000; // both a and b 
int b = 40000; // does not fit in 2 bytes.
int c = a + b; // overflows on 16bits, but not on 32bits

If you look into cstdint header, you will find how all fixed size types (int8_t, uint8_t, etc.) are defined - and only thing differs between different architectures is this header file. So, on one architecture int16_tcould be:

 typedef int int16_t;

and on another:

 typedef short int16_t;

Also, there are other types, which may be useful, like: int_least16_t

Answer 8

1. If a type is smaller than you think then it may not be able to store a value you need to store in it.
2. To create a fixed size types you read the documentation for platforms to be supported and then define typedefs based on #ifdef for the specific platforms.

Answer 9

can someone bring some example, what goes wrong, when program assumes an int is 4 bytes, but on a different platform it is say 2 bytes?

Say you've designed your program to read 100,000 inputs, and you're counting it using an unsigned int assuming a size of 32 bits (32-bit unsigned ints can count till 4,294,967,295). If you compile the code on a platform (or compiler) with 16-bit integers (16-bit unsigned ints can count only till 65,535) the value will wrap-around past 65535 due to the capacity and denote a wrong count.

Answer 10

Compilers are responsible to obey the standard. When you include <cstdint> or <stdint.h> they shall provide types according to standard size.

Compilers know they're compiling the code for what platform, then they can generate some internal macros or magics to build the suitable type. For example, a compiler on a 32-bit machine generates __32BIT__ macro, and previously it has these lines in the stdint header file:

#ifdef __32BIT__
typedef __int32_internal__ int32_t;
typedef __int64_internal__ int64_t;
...
#endif

and you can use it.

Answer 11

bit flags are the trivial example. 0x10000 will cause you problems, you can't mask with it or check if a bit is set in that 17th position if everything is being truncated or smashed to fit into 16-bits.