C/C++ Can Array Overruns Lead to Catastrophic Failures?

[Lillyotv]

Can over running of array lead to the catastrophic failures?
If ‘Yes’ then why does not C++ provide bound checking on array operations and who is responsible to prevent array overruns?

 

[Sojourner01]

First question: definitely. Obviously if you need a piece of data that doesn't exist, some operations will fail. My experience is in C# and not C++, but my understanding is that C-type languages can't ever be expected to catch all array bounding errors.

It's always better to write solid code that behaves in the way the programmer intended than to expect the compiler to catch errors for you.

 

[Hurkyl]

Can over running of array lead to the catastrophic failures?

Yes, or worse. See http://en.wikipedia.org/wiki/Buffer_overflow

If ‘Yes’ then why does not C++ provide bound checking on array operations

Bounds checking is inefficient. C++, like C, is intended to allow the programmer to write efficient code, and so it would be inappropriate for standard C++ to enforce bounds checking.

and who is responsible to prevent array overruns?

It's the programmer's job to write correct code. If you are worried about this error, then you shouldn't use raw arrays; you should write a customized array class that does provide bounds checking.

In fact, the C++ standard std::vector class does provide bounds checking if you use the at member to access data.

 

[Hurkyl]

C-type languages can't ever be expected to catch all array bounding errors.

Java does. Wikipedia suggests that C# does too.

 

[CompuChip]

Also, IIRC, the following is valid C++ code

int intarray[20];
int* ptr = intarray; 
// equivalently:
ptr = &intarray[0];
ptr += 4;
// now ptr points at either &intarray[1] or &intarray[4]

I can imagine it is hard for the compiler to check on every pointer assignment if it happens to point at an array, if the assignment would cause it to point outside it, and if the programmer didn't just mean to do it, as in

... // above code, then
int someInt;
ptr = &someInt; 
// should the compiler warn or not?

 

[D H]

The compiler cannot always determine whether an array access is out of bounds. Consider the cases of an array index formed from an argument passed to a function. How can the compiler possibly determine at compile time whether use of this computed index entails an out-of-bounds access? In languages that do check for out-of-bounds conditions, the check is almost always performed at execution time.

While C/C++ arrays are not accompanied with any bounds checking, the vector template in the C++ standard template library does provide this ability.

 

[Dale]

Bounds checking is inefficient. C++, like C, is intended to allow the programmer to write efficient code, and so it would be inappropriate for standard C++ to enforce bounds checking.

This is exactly correct. C/C++ is intended to allow the programmer to write efficient code, not to efficiently write code!

 

[Inquisitus]

Java does. Wikipedia suggests that C# does too.

There's a world of difference between C/C++ and Java/C#, though

 

[Sojourner01]

Wikipedia suggests that C# does too.

Not the case. I've been grappling with out-of-bounds issues for some time with a project of mine. I'm fortunate that my project will come across one every runtime if any are present, so they're relatively easy to find.

 

[Inquisitus]

Not the case. I've been grappling with out-of-bounds issues for some time with a project of mine. I'm fortunate that my project will come across one every runtime if any are present, so they're relatively easy to find.

Yes it does. Bounds checking means that array access attempts are checked at runtime to make sure an access to a memory location outside the array's bounds doesn't occur. If such an access is attempted, a runtime error will occur (specifically, an IndexOutOfRangeException will be thrown, in the case of C#), rather than the access going through, which would cause unpredictable results.

You're thinking of compile-time bounds checking, which is largely impossible.

 

[Lillyotv]

Thanks a lot. I have the concept clear in my head now.
Cheers:)