Referencing invalid memory locations with C++ Iterators

Question

I am a big fan of GCC, but recently I noticed a vague anomaly. Using __gnu_cxx::__normal_iterator (ie, the most common iterator type used in libstdc++, the C++ STL) it is possible to refer to an arbitrary memory location and even change its value without causing an exception! Is this expected behavior? If so, isn't a security loophole?

Here's an example:

#include <iostream>
using namespace std;

int main() {
        basic_string<char> str("Hello world!");
        basic_string<char>::iterator iter = str.end();



        iter += str.capacity() + 99999;
        *iter = 'x';

        cout << "Value: " << *iter << endl;
}

Answer 1

C++ generally has a philosophy of not making you pay for what you don't use. It is up to you to validate that you're using iterators properly. For a random-access iterator, you can always test it:

if (iter < str.begin() || iter >= str.end())
    throw something;

Answer 2

Dereferencing an iterator beyond the end of the container from which it was obtained is undefined behavior, and doing nothing is just a possibility there.

Note that this is a question of compromise, it is nice having iterators check for validity for development, but that adds extra operations to the code. In MSVS iterators are by default checked (they will verify that they are valid and fail hard when they are used in a wrong way=. But that also has an impact in runtime performance.

The solution that Dinkumware (STL inside VS) provides (checked by default, can be unchecked through compiler options) is in fact a good choice, the user selects whether he wants slow safe iterators or fast unsafe versions of it. But from the point of view of the language, both are valid.

Answer 3

You got lucky. Or unlucky. Using your exact example, I segfaulted.

$ ./a.exe
  11754 [main] a 4992 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack)
Segmentation fault (core dumped)

Undefined behavior can mean different things on different compiles, platforms, days. Perhaps when you ran it, the address created by all that adding ended up in some other valid memory space, just by chance. Maybe you incremented from the stack to the heap for example.

Answer 4

No, this is not a problem. Keep in mind that typical iterator usage is:

for ( type::const_iterator it = obj.begin(); it != obj.end(); ++it ){
    // Refer to element using (*it)
}

Proper iterator usage requires one to check against the end() iterator. With random access iterators such as the one you are using, you can also use < and > with the iterators against end(). C and C++ don't typically do bounds checking as in Java, and it is your place to ensure that you do so.