Odd behavior from border checking

Question

Any tire experts out there? I am trying to use splint to statically analyze a large project that I have. I see an excessive amount of border validation errors that do not explicitly limit errors. I wrote a small test program to try to isolate the problem, and noticed some really strange warnings when I ran the code bus. I have 3 different examples. Here is the first one:

int arr[3]; int main(void) { int i; int var; arr[3] = 0; // (1) warning with +bounds, no warning with +likely-bounds return 0; } 

The assignment arr[3] generates a warning when using +bounds , as expected, but does nothing when I use +likely-bounds . What does +likely-bounds even do? This does not seem to work. Second example:

 int arr[3]; int main(void) { int i; int var; for (i = 0; i < 3; i++) var = arr[i]; // (2) warning, even though I'm within the bounds. return 0; } 

In this example, splint complains about what I read outside the array ("Memory memory reads memory outside of the allocated storage.") For var = arr[i] , although I obviously do not. This should be a warning, as the values ​​in the array are not initialized, but this is not the warning I get. Initializing the last value in the array will clear the error (but initializing the first or second will not). Am I doing something wrong? In the third example:

 int arr[3]; int main(void) { int i; int var; arr[3] = 0; // warning for (i = 0; i < 4; i++) var = arr[i]; // (3) no warning because arr[3] = 0 statement. return 0; } 

A warning is generated for arr[3] = 0 , but not var = arr[i] , although it is obvious that the loop goes beyond the array. It seems that writing to the end of the array extends how the big bus thinks the array is. How is this possible?

In short, my questions are:

• What does a probability flag do?
• Is there any way that I can make splint give me legitimate errors related to going beyond?
• Is there a way to make the bus not increase the size of the arrays that are accessed outside of them? Currently, the bus reports more than 750 warnings, and I do not have time to check each warning in turn.

Answer 1

Upstairs: I don’t know the "bus", but I know that methods use PC Lint very well intensively and discuss several problems with its creators.

That said:

• In the first example, arr[3] marked only with +bounds , because one element after the last is a special case: it is allowed to create and use a pointer to the element that was the last, but it is not allowed to dereference such a pointer. Therefore, in the syntactic steps (QA-C also) it quite often happens that such warnings are less serious for N + 1. Have you tried arr[4] ? I assume there will be +likely_bounds for this.
• The second example is probably caused by a somewhat confusing "bus". I saw similar errors in early versions of PC Lint and QA-C, since "value tracking" is far from simple. However, I cannot say why the schism complains.
• Third example: "splint" correctly complains about the initialization of arr[3] , but for the purpose of tracking values, he suggested that arr[3] is valid and refrains from complaining about the loop. I would suggest that you can initialize arr[100] and let the loop run to 100 without complaint!