The analyzer found a possible error of indexing large arrays. The error may consist in the incorrect index determination.

The first example.

	Copy Code
extern char *longString; extern bool *isAlnum; ... unsigned i = 0; while (*longString) { isAlnum[i] = isalnum(*longString++); ++i; }

The given code is absolutely correct for the 32-bit platform where it is actually impossible to process arrays more than UINT_MAX bytes (4Gb). On the 64-bit platform it is possible to process an array with the size more than 4 Gb that is sometimes very convenient. The error consists in the use of the variable of unsigned type for indexing the array isAlnum. When we fill the first UINT_MAX of the items the variable i overflow will occur and it will equal zero. As the result we’ll begin to rewrite the array isAlnum items which are situated in the beginning and some items will be left unassigned.

The correction is to replace the variable i type with memsize type:

	Copy Code
size_t i = 0; while (*longString) isAlnum[i++] = isalnum(*longString++);

The second example.

	Copy Code
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]; }

For computational modeling programs the main memory size is an important source, and the possibility to use more than 4 Gb of memory on the 64-bit architecture increases calculating possibilities greatly. In such programs one-dimensional arrays are often used which are then dealt with as three-dimensional ones. There are functions for that which similar to GetCell that provides access to the necessary items of the calculation area. But the given code may deal correctly with arrays containing not more than INT_MAX (2Gb) items. The reason is in the use of 32-bit int types which participate in calculating the item index. If the number of items in the array array excesses INT_MAX (2 Gb) an overflow will occur and the index value will be determined incorrectly. Programmers often make a mistake trying to correct the code in the following way:

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

They know that according to C++ rules the expression for calculating the index will have ptrdiff_t type and because of it hope to avoid the overflow. Unfortunately, the overflow may occur inside the subexpression y * Width or z * Width * Height for to determine them int type is still used.

If you want to correct the code without changing the types of the variables included into the expression you should convert each variable explicitly to memsize type:

	Copy Code
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)]; }

Another decision is to replace the variables types with memsize type:

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

If you use expressions which type is different from memsize type for indexing but are sure about the code correctness, you may use the explicit type conversion to suppress the analyzer’s warning messages as follows:

	Copy Code
const size_t SecondsPerHour = 60 * 60; bool Seconds[SecondsPerHour]; int min, sec; ... bool flag = Seconds[static_cast<size_t>(min * 60 + sec)];

If you suspect that the program may contain errors related to the incorrect explicit type conversion in expressions you may use the Find incorrect explicit type conversion mode.

The analyzer warns only about possibly dangerous constructions of the work with arrays which may occur on the 64-bit platform. That’s why the analyzer considers the following code absolutely correct:

	Copy Code
extern size_t n; ... array[0] = 1; array[n] = 2; array['A'] = 3;

See also:

memsize type

limitations of the analyzer Viva64

implicit type conversion

explicit type conversion

how to find the explicit type conversion