Consider the following program:
struct abc
{
int x[5];
int y[5];
};
int main()
{
struct abc test;
test.y[0] = 10;
printf("%d", test.x[5]);
}
(borrowed from Is it legal to overrun one element of a struct to view another?)
BoundsChecker does not detect this as an overflow. Are there any programs that will detect this type of programming error?
clang does, even with no special flags turned on:
$ clang example.c -o example
example.c:13:18: warning: array index of '5' indexes past the end of an array
(that contains 5 elements) [-Warray-bounds]
printf("%d", test.x[5]);
^ ~
example.c:5:5: note: array 'x' declared here
int x[5];
^
1 warning generated.
The same warning is printed when compiling as C++.
What we are seeing here is a nasty, little known secret about BoundsChecker: it gives you no visibility into structure members at all. If you declare an array as part of a structure, whether that structure is allocated automatically or dynamically, BoundsChecker sees the structure as a blob. If you overrun the boundaries of that structure, it will report the problem. Otherwise, no.
That said, several years ago we wrote some code which ships with the product currently, and which may be invoked with a hidden configuration option. If you were to manually insert the line EnableStructureMemberEnumeration=1 into the [BC MemoryTracker] section of the project configuration file (.dpbcd), then you would find that the product can see a structure's members (structures and arrays, principally), as long as that structure is allocated automatically (on the stack).
This option is not fully ready for prime-time, though. It has issues with very complex classes and structures such as are found in STL. Furthermore, in the specific test case given above, there is another problem. It cannot distinguish in general between an array that starts a structure/class, and the class object itself. Both have the same address in memory. But consider this code:
struct _Type {
int Array[5];
} Objects[10];
struct _Type *pObject = &Objects[5];
int *pInt = &Objects[0].Array[5];
In both cases, we see the same address, the first time with an offset of 100, the second time with an offset of 20. The first, if evaluated with respect to Array, is invalid, but if evaluated with respect to Objects, is valid. What's a poor program to do?
Oh, and one more thing: BoundsChecker generally ignores access to the first element past the end of the array. This is because so much code exists out there where an iterator will go just one element past the end. This was a huge source of false errors, so somebody altered it to complain only if the overrun went to the next location (and beyond). The problem here is, you've incremented the iterator, but are you really going to use it?
So, the answer, for the moment, to the question is that BoundsChecker does indeed support this kind of check, but not without using an undocumented "feature" and not without problems still.
