Thread: Referencing outside the bounds of an array does not generate an error

There is not really any such thing as a (generic, automatic, built-in) run-time error in C, because it is a 100% compiled language. There is no interpreter or virtual machine to generate such a thing. Of course, you can code fatal errors in yourself.

There is the possibility of the OS killing the process while running, eg, if it tries to access memory it doesn't have, you get a segmentation fault. Going out of bounds on an array does not guarantee that, however, because the "out of bounds" may still be within the program's own memory. This is actually worse, because it means you may have overwritten some of your own data, but there is no way to detect that and the consequences may be very strange.

Which is why it is very important in C to keep track of what you are doing and not go out of bounds.

WRT to compile time, the C standard does not require the compiler to keep track of your allocations (only very simple violations could be caught then anyway) -- that's your job. There are some memory profiling tools around that can detect some out of bounds errors, and you may find an IDE or code validator that will also find some hard-coded violations. However, most probably happen at runtime due to faulty logic, so unless you are running the process inside a debugger or something, again, it's on its own. Short story: the only thing you can rely on in this regard is careful programming.

Relying on GDB to catch your out-of-bound errors is not an effective way to go about things. If you need to make sure you don't access out of bounds, you need to code the test for yourself on every access (by having a wrapper function when you want to access an element of the array, etc.) - that's what C doesn't do for you and why it's faster than other languages (all those other languages DO check every access for correct array indices, even if you don't see it, hence why they are slower than C for tasks like this). C is the Ferrari-without-seatbelts: Faster than your other car but a lot more dangerous if you don't use it properly.

GDB may or may not catch the error, as you've noticed, and that depends on how it compiles (the compiler is free to throw away all sorts of junk if it likes), what options you have turned on, where you're looking and where the compiler decided to store variables. You can look into the ASM if you're really interested in why it missed being a global but most probably you just don't have relevant options turned on.

C is NOT a safe language - it always relies on you being safe and taking precautions where necessary. You will *not* get compiler warnings about this. The syntax of the source is PERFECTLY valid (and that's all the compiler cares about), it just happens to access out of bounds when actually executed (and without executing the program and trying EVERY SINGLE CODEPATH in an automated fashion, there's no way for a language to detect such instances just from a compile - it's related to the Halting problem). The statement given may or may not execute correctly depending on things like the resolution of memory allocations (i.e. does malloc / the stack allocator always give you a 1k block no matter what you ask for below that size, thus even writing out of bounds actually writes in "writable" memory and thus no error?), whether DEP etc. are available on the system and turned on, and so on. Basically, C writes to the block because you told it to and only the OS / processor can say "Oi, you can't do that!" and when they do, C can't do anything to deal with it but terminate the program. In other languages, they would check the bounds every time you read from / write to the array and throw exceptions, etc. at great computational expense.

If you're expecting GCC to hold your hand on this, you're mistaken. Yes, in other languages you'd get errors but NOT here. C is *designed* to have enough access to the computer that you can shoot yourself in the foot quite easily while it plays dumb. It's not C's job to guard against things like this or even look for them. That's your job and the OS's job. Be thankful that GCC warns about many things that it has no obligation to do so. This is a case where it doesn't warn because the syntax of the source is entirely valid - there are cases where it falsely warns too.