In his November 1, 2005 C++ column, Herb Sutter writes ...
int A[17];
int* endA = A + 17;
for( int* ptr = A; ptr < endA; ptr += 5 )
{
// ...
}
[O]n some CPU architectures, including current ones, the aforementioned code can cause a hardware trap to occur at the point where the three-past-the-end pointer is created, whether that pointer is ever dereferenced or not.
How does a CPU trap on a bitpattern? What about ...
int A[17];
// (i) hardware will trap this ?
int *pUgly = A + 18;
// (ii) hardware will trap this, too?
int *pEnd = A + 17;
++pEnd;
// (iii) will this fool it?
int *precious = A + 17;
unsigned long tricksy = reinterpret_cast<unsigned long>(precious) ;
++tricksy;
int *pHobbits = reinterpret_cast<int *>(tricksy);
Bonus question: Should the phrase "some current CPU architectures" be ordinarily understood to refer to shipping products only, or does it include imaginary architectures as well if the work of fiction in which they are described or alluded to has a recent publication date?
Pointer operations are implementation-dependent.
It can happen that on some platform only specific registers are allowed for storing pointer values (only specific registers can serve as index registers) and the value written into such register by a non-priviledged program code is immediately checked for being a valid address. In this case if the pointer value corresponds to an address not present in the address space of the program the hardware trap will certainly occur.
If that's the case any code not optimized out by the compiler that assigns a new value to a pointer can potentially cause a trap.
You might to google "speculative reading". As soon as an address is formed, it may be smart for the cache architecture to bring the corresponding dataline into cache. Normally, this should be harmless, but if you're significantly out of bounds (e.g. onto the next page) this might no longer be true.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With