An important point during the port of a software solution on the new platform is succession to the existing data exchange protocol. It is necessary to provide the read of the existing projects formats, to carry out the data exchange between 32-bit and 64-bit processes etc.

Mostly the errors of this kind consist in the serialization of memsize types and data exchange operations using them.

1) size_t PixelCount;
   fread(&PixelCount, sizeof(PixelCount), 1, inFile);

2) __int32 value_1;
   SSIZE_T value_2;
   inputStream >> value_1 >> value_2;

3) time_t time;
   PackToBuffer(MemoryBuf, &time, sizeof(time));

The use of types of volatile size

It is unacceptably to use types which change their size depending on the development environment in binary interfaces of data exchange. In C++ language all the types don’t have distinct sizes and consequently it is not possible to use them all for these aims. That’s why the developers of the development means and programmers themselves develop data types which have an exact size such as __int8, __int16, INT32, word64 etc.

The use of such types provides data portability between programs on different platforms although it needs the use of odd ones. The three shown examples are written inaccurately and this will show up on the changing of the capacity of some data types from 32-bit to 64-bit. Taking into account the necessity to support old data formats the correction may look as follows.

1) size_t PixelCount;
   __uint32 tmp;
   fread(&tmp, sizeof(tmp), 1, inFile);
   PixelCount = static_cast(tmp);

2) __int32 value_1;
   __int32 value_2;
   inputStream >> value_1 >> value_2;

3) time_t time;
   __uint32 tmp = static_cast<__uint32>(time);
   PackToBuffer(MemoryBuf, &tmp, sizeof(tmp));

Ignoring of the byte order

Even after the correction of volatile type sizes you may face the incompatibility of binary formats. The reason is a different data presentation. Most frequently it is related to a different byte order.

The byte order is a method of recording of bytes of multibyte numbers (see also picture 4). The little-endian order means that the recording begins with the lowest byte and ends with the highest one. This record order was acceptable in the memory of PCs with x86-processors. The big-endian order – the recording begins with the highest byte and ends with the lowest one. This order is a standard for TCP/IP protocols. That’s why the big-endian byte order is often called the network byte order. This byte order is used by processors Motorola 68000, SPARC.

_{Picture 4. Byte order in a 64-bit type on little-endian and big-endian systems.}

While developing the binary interface or data format you should remember about the byte order. If the 64-bit system on which you are porting a 32-bit application has a different byte order you’ll just have to take it into account in your code. For conversion between the big-endian byte order and the little-endian one you may use functions htonl(), htons(), bswap_64 etc.

11. Bit fields

If you use bit fields you should keep in mind that the use of memsize types will cause the change of sizes of structures and alignment. For example, the structure shown further will have size 4 bytes on the 32-bit system and 8 bytes on the 64-bit one.

struct MyStruct {
  size_t r : 5;
};

struct BitFieldStruct {
  unsigned short a:15;
  unsigned short b:13;
};
BitFieldStruct obj;
obj.a = 0x4000;
size_t addr = obj.a << 17; //Sign Extension
printf("addr 0x%Ix\n", addr);

//Output on 32-bit system: 0x80000000
//Output on 64-bit system: 0xffffffff80000000

• A member of obj.a is converted from a bit field of unsigned short type into int. We get int type and not unsigned int because the 15-bit field can be located in the 32-bit sign integer.
• "obj.a << 17" expression has int type but it is converted into ptrdiff_t and then into size_t before it will be assigned to variable addr. The sign extension occurs during the conversion from int into ptrdiff_t.

_{Picture 5. Expression calculation on different systems.}

So be attentive while working with bit fields. To avoid the described effect in our example we can simply use the explicit conversion from obj.a type to size_t type.

...
size_t addr = size_t(obj.a) << 17;
printf("addr 0x%Ix\n", addr);

//Output on 32-bit system: 0x80000000
//Output on 64-bit system: 0x80000000

The first example.

unsigned short a16, b16, c16;
char *pointer;
…
pointer += a16 * b16 * c16;

One should take care to avoid possible overflows in pointer arithmetic. For this purpose it’s better to use memsize types or the explicit type conversion in expressions which carry pointers. Using the explicit type conversion we can rewrite the code in the following way.

short a16, b16, c16;
char *pointer;
…
pointer += static_cast(a16) *
           static_cast(b16) *
           static_cast(c16);

int A = -2;
unsigned B = 1;
int array[5] = { 1, 2, 3, 4, 5 };
int *ptr = array + 3;
ptr = ptr + (A + B); //Invalid pointer value on 64-bit platform
printf("%i\n", *ptr); //Access violation on 64-bit platform

• According to C++ rules variable A of int type is converted to unsigned type.
• Addition of A and B occurs. The result we get is value 0xFFFFFFFF of unsigned type.

In a 64-bit program 0xFFFFFFFFu value will be added fairly to the pointer and the result will be that the pointer will be outbound of the array. And while getting access to the item of this pointer we’ll face troubles.

To avoid the shown situation, as well as in the first case, we advise you to use only memsize types in pointer arithmetic. Here are two variants of the code correction:

ptr = ptr + (ptrdiff_t(A) + ptrdiff_t(B));

ptrdiff_t A = -2;
size_t B = 1;
...
ptr = ptr + (A + B);

int A = -2;
int B = 1;
...
ptr = ptr + (A + B);

1. It will teach you inaccurate work with pointers. After a while you may forget nuances and made a mistake by making one of the variables of unsigned type.
2. Using of non-memsize types together with pointers is potentially dangerous. Suppose variable Delta of int type participates in the expression with a pointer. This expression is absolutely correct. But the error may hide in the calculation of the variable Delta itself for 32-bit may be not enough to make the necessary calculations while working with large data arrays. The use of memsize type for variable Delta liquidates the danger automatically.

This kind of errors is separated from the others for better structuring of the account because indexing in arrays with the use of square brackets is just a different record of address arithmetic observed before.

In programming in language C and then C++ a practice formed to use in the constructions of the following kind variables of int/unsigned types:

unsigned Index = 0;
while (MyBigNumberField[Index] != id)
  Index++;

The given code won’t process in a 64-bit program an array containing more than UINT_MAX items. After the access to the item with UNIT_MAX index an overflow of the variable Index will occur and we’ll get infinite loop.

To persuade you entirely in the necessity of using only memsize types for indexing and in the expressions of address arithmetic, I’ll give the last example.

class Region {
  float *array;
  int Width, Height, Depth;
  float Region::GetCell(int x, int y, int z) const;
  ...
};
float Region::GetCell(int x, int y, int z) const {
  return array[x + y * Width + z * Width * Height];
}

Programmers often make a mistake trying to correct the code in the following way:

float Region::GetCell(int x, int y, int z) const {
  return array[static_cast(x) + y * Width +
               z * Width * Height];
}

If you want to correct the code without changing types of the variables participating in the expression you may use the explicit type conversion of every variable memsize type:

float Region::GetCell(int x, int y, int z) const {
  return array[ptrdiff_t(x) +
               ptrdiff_t(y) * ptrdiff_t(Width) +
               ptrdiff_t(z) * ptrdiff_t(Width) *
               ptrdiff_t(Height)];
}

typedef ptrdiff_t TCoord;
class Region {
  float *array;
  TCoord Width, Height, Depth;
  float Region::GetCell(TCoord x, TCoord y, TCoord z) const;
  ...
};
float Region::GetCell(TCoord x, TCoord y, TCoord z) const {
  return array[x + y * Width + z * Width * Height];
}

Mixed use of memsize and non-memsize types in expressions may cause incorrect results on 64-bit systems and be related to the change of the input values rate. Let’s study some examples.

size_t Count = BigValue;
for (unsigned Index = 0; Index != Count; ++Index)
{ ... }  

Another frequent error is a record of the expressions of the following kind:

int x, y, z;
intptr_t SizeValue = x * y * z;

Let’s give an example of a small code which shows the danger of inaccurate expressions with mixed types (the results are got with the use Microsoft Visual C++ 2005, 64-bit compilation mode).

int x = 100000;
int y = 100000;
int z = 100000;
intptr_t size = 1;                  // Result:
intptr_t v1 = x * y * z;            // -1530494976
intptr_t v2 = intptr_t(x) * y * z;  // 1000000000000000
intptr_t v3 = x * y * intptr_t(z);  // 141006540800000
intptr_t v4 = size * x * y * z;     // 1000000000000000
intptr_t v5 = x * y * z * size;     // -1530494976
intptr_t v6 = size * (x * y * z);   // -1530494976
intptr_t v7 = size * (x * y) * z;   // 141006540800000
intptr_t v8 = ((size * x) * y) * z; // 1000000000000000
intptr_t v9 = size * (x * (y * z)); // -1530494976

intptr_t v2 = intptr_t(x) * y * z;

The order of the calculation of an expression with operators of the same priority is not defined. To be more exact, the compiler can calculate sub-expressions in such an order which it considers to be more efficient even if sub-expressions cause (side effect). The order of the appearing of side effects is not defined. Expressions including communicative and association operations (*, +, &, |, ^), may be converted in a free way even if there are brackets. To assign the strict order of the calculation of the expression it is necessary to use the explicit temporary variable.

That’s why if the result of the expression should be of memsize type, only memsize types must participate in the expression. The right variant:

intptr_t v2 = intptr_t(x) * intptr_t(y) * intptr_t(z); // OK!

Mixed use of types may occur in the change of the program logic.

ptrdiff_t val_1 = -1;
unsigned int val_2 = 1;
if (val_1 > val_2)
  printf ("val_1 is greater than val_2\n");
else
  printf ("val_1 is not greater than val_2\n");

//Output on 32-bit system: "val_1 is greater than val_2"
//Output on 64-bit system: "val_1 is not greater than val_2"

_{Picture 6. Changes occurring in the expression.}

If you need to return the previous behavior you should change the variable val_2 type.

ptrdiff_t val_1 = -1;
size_t val_2 = 1;
if (val_1 > val_2)
  printf ("val_1 is greater than val_2\n");
else
  printf ("val_1 is not greater than val_2\n");

Issues 15-20