CODEWITHSUNDEEP
c++
quantum_well
quantum_well

Reputation: 979

Incrementing iterator out of range

Is it illegal to increment random access iterator out of range? It turns out that Visual C++ implementation of vector triggers debug assertion.

std::vector<int> foo(5);
auto iter = foo.begin();
iter += 10;

This should be legal with pointers as long as memory location is not assessed.

Edit: apparently it is illegal even with pointers.

Upvotes: 8

Views: 5130

Answers (2)

James Kanze
James Kanze

Reputation: 153909

It's undefined behavior. Both with iterators and with pointers. With iterators, you'll probable get an assertion failure, at least with iterator debugging turned on. With pointers, it will probably do nothing in most modern architectures, but there have been machines on which it could trigger at trap. You don't have to access the memory location itself, just create the pointer, for undefined behavior to occur.

EDIT:

From the standard (§5.7/5, emphesis added):

When an expression that has integral type is added to or subtracted from a pointer, the result has the type of the pointer operand. If the pointer operand points to an element of an array object, and the array is large enough, the result points to an element offset from the original element such that the difference of the subscripts of the resulting and original array elements equals the integral expression. In other words, if the expression P points to the i-th element of an array object, the expressions (P)+N (equivalently, N+(P)) and (P)-N (where N has the value n) point to, respectively, the i + n-th and i − n-th elements of the array object, provided they exist. Moreover, if the expression P points to the last element of an array object, the expression (P)+1 points one past the last element of the array object, and if the expression Q points one past the last element of an array object, the expression (Q)-1 points to the last element of the array object. If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined.

The corresponding rule for random access iterators (the only ones which support addition) is spread-out over several sections: the += operator is defined in terms of repeated ++ (for the semantics—it is required to have constant time complexity), and ++ has the requirement that “pre: r is dereferenceable. post: r is dereferenceable or r is past-the-end.” (from the definition of input iterators, which is inherited by forward iterators, which is inherited by bidirectional iterators, which is inherited by random access iterators).

Upvotes: 5

Sridhar Nagarajan
Sridhar Nagarajan

Reputation: 1105

This is undefined behavior, which means anything could happen, including segfault, or what you have experienced, or anything else. Basically, you were just lucky it didn't crash (or unlucky, based on the point of view).

The language does not require iterator accesses to be checked, as that would require a run-time check. C++ usually tries to avoid unnecessary run-time overhead, leaving the programmer to perform whatever checks are necessary.

Most modern platforms use paged virtual memory, providing memory protection with a granularity of a few kilobytes. This means that there is often accessible memory after an allocated block (such as the one managed by std::vector), in which case out-of-range accesses will simply stomp on that memory.

Visual Studio is trying to aid in removing dangerous code. In principle a pointer could point anywhere if you didn't dereference it, but iterators are a higher level abstraction and have the ability to detect whether dereference would be valid and thus raise runtime errors. Visual Studio has done this with vector<T>::iterator at least since VS 2007.

Upvotes: 3

Related Questions