Codeblocks.

I was told to compile the following to see what errors the compiler gives when you try to compile a program that goes past the upper bound of an array. However codeblocks did not give me any errors. Now my question is if it is possible for codeblocks to do this by changing something in it's setting?

If you are on Linux, an open source tool that seems to work well (I just tried it on this problem for the first time) is called cppcheck. If you are on a Debian or Ubuntu type install, just do a <sudo if needed> apt-get install cppcheck. I created a demo project with no fancy switches to gcc (same thing CodeBlocks use I think) and inserted your test code into it, then ran cppcheck against the buggy file. Here is the output:

An interesting (to me, who has no life I guess) update on this problem:

First, the cppcheck tool I used above is a static source code checker which means it analyzes the source code as-is; you don't have to compile anything into the app, you don't have to run it, etc. This I think is more on the lines of what the OP was looking for WRT CodeBlocks.

However one of my favorite tools for finding non-obvious memory and resource issues is Valgrind. Valgrind falls into the category of tools that examine a running app and watch for memory leaks, overruns, etc that way. Normally this approach is some powerful mojo but in this particular case it fell on its face. When run as written above (well in my source I just made the test a separate function and called it from main()), when the app gets to the first actual bug (for loop that iterates beyond the end of the array) the program just stops, requiring a Ctrl-C to break it. GDB acted the same way and electric fence acted the same way as well. The print statement just before it never resulted in something going to the screen. This is and of itself is a bug too when viewed in the context of debugging this app because there is no endl at the end so the buffers are not flushed and since the next line stops the program, the line of text never appears (endl, in addition to supplying a carriage return/line feed also flushes your buffers). Now here is the interesting part: to problem of the end-of-array overwrite means that the address of array[24+1] is somewhere in the code so by overwriting that, you are likely stepping on other code preventing the app from finishing. As a sort of test, I added the following just after that for loop:

Code:

int dodgyIndex =-1;
TargetArray[dodgyIndex] = 20;

Slightly altering the memory footprint of the app and even with the bad for() loop it ran to completion, probably because I gave it a non-essential bit of code to step on. The same or similar results could have been achieved by allocating TargetArray on the heap via new or making it static. This points to a subtle yet nice bullet to have in your debugging armament: if you suspect a memory block is being violated in any way, change where it is being allocated. If it is an automatic variable like this, create it on the heap via new and see if your symptoms change. If it is created with malloc/new, change it to a stack-based variable and see what happens.

This can give you some simple yet vital clues as to what is going on. Interestingly enough, if you look at the original code and insert my dodgyIndex test immediately after the for loop (but before any of the output lines) TargetArray[25] reports a value of -1, not 20 as you would expect...however even though the app can make it to the finish line, because of the way the long array is allocated valgrind and electric fence cannot see the bugs. However I altered the test a little to push the array onto the heap by allocating it with new and passing it to the test function, rebuilt and ran it under valgrind once again and got the following output (extraneous output removed):

So depending on your situaion, Valgrind can hand you the bugs on a silver platter or provide a false sense of security.
Electric fence did a little better and a lot worse; yes it detected the first memory overwrite but didn't tell you where it was but it did through a segfault which stinks if thats all you have but if you ran the same app in GDB the segfault would cause a stack trace dump which would be helpful plus it more or less pointed out the first line with an error on it: