Warum ist Out-of-Bounds-Zeiger arithmetisch undefiniertes Verhalten?

Das folgende Beispiel ist aus Wikipedia.

int arr[4] = {0, 1, 2, 3};
int* p = arr + 5;  // undefined behavior

Wenn ich p nie dereferenziere, warum ist dann arr + 5 allein undefiniertes Verhalten? Ich erwarte, dass sich Zeiger als Ganzzahlen verhalten – mit der Ausnahme, dass der Wert eines Zeigers beim Dereferenzieren als Speicheradresse betrachtet wird.

Das liegt daran, dass sich Zeiger nicht wie ganze Zahlen verhalten. Es ist ein undefiniertes Verhalten, weil der Standard es so vorschreibt.

Auf den meisten Plattformen (wenn nicht allen) kommt es jedoch nicht zu einem Absturz oder zweifelhaftem Verhalten, wenn Sie das Array nicht dereferenzieren. Aber wenn Sie es nicht dereferenzieren, wozu dann die Addition?

Beachten Sie jedoch, dass ein Ausdruck, der eins über das Ende eines Arrays geht, technisch zu 100 % „korrekt“ ist und gemäß §5.7 Abs. 5 der C++11-Spezifikation garantiert nicht abstürzt. Das Ergebnis dieses Ausdrucks ist jedoch nicht spezifiziert (nur garantiert kein Überlauf); während jeder andere Ausdruck, der mehr als eins über die Array-Grenzen hinausgeht, explizit ist nicht definiert Verhalten.

Hinweis: Das bedeutet nicht, dass es sicher ist, von einem Over-by-One-Offset zu lesen und zu schreiben. Sie wahrscheinlich Wille Daten bearbeiten, die nicht zu diesem Array gehören, und Wille Zustands-/Speicherbeschädigung verursachen. Sie werden einfach keine Überlaufausnahme verursachen.

Ich vermute, dass es so ist, weil nicht nur die Dereferenzierung falsch ist. Auch Zeigerarithmetik, Vergleichen von Zeigern usw. So ist es einfach einfacher zu sagen mach das nicht anstatt die Situationen aufzuzählen, in denen es kann sei gefährlich.

Das ursprüngliche x86 kann Probleme mit solchen Aussagen haben. Bei 16-Bit-Code sind Zeiger 16 + 16 Bit. Wenn Sie den unteren 16 Bits einen Offset hinzufügen, müssen Sie möglicherweise mit dem Überlauf umgehen und die oberen 16 Bits ändern. Das war eine langsame Operation und sollte am besten vermieden werden.

Auf diesen Systemen array_base+offset wurde garantiert nicht überlaufen, wenn Offset im Bereich war (<=Array-Größe). Aber array+5 würde überlaufen, wenn das Array nur 3 Elemente enthält.

Die Folge dieses Überlaufs ist, dass Sie einen Zeiger erhalten, der nicht zeigt hinter das Array, aber vor. Und das ist möglicherweise nicht einmal RAM, sondern speicherabgebildete Hardware. Der C++-Standard versucht nicht einzuschränken, was passiert, wenn Sie Zeiger auf zufällige Hardwarekomponenten konstruieren, dh es ist undefiniertes Verhalten auf realen Systemen.

Wenn arr befindet sich dann zufällig ganz am Ende des Speicherplatzes der Maschine arr+5 möglicherweise außerhalb dieses Speicherplatzes, sodass der Zeigertyp möglicherweise nicht in der Lage ist, den Wert darzustellen, dh er könnte überlaufen, und der Überlauf ist undefiniert.

“Undefiniertes Verhalten” bedeutet nicht, dass es in dieser Codezeile abstürzen muss, aber es bedeutet, dass Sie das Ergebnis nicht garantieren können. Zum Beispiel:

int arr[4] = {0, 1, 2, 3};
int* p = arr + 5; // I guess this is allowed to crash, but that would be a rather 
                  // unusual implementation choice on most machines.

*p; //may cause a crash, or it may read data out of some other data structure
assert(arr < p); // this statement may not be true
                 // (arr may be so close to the end of the address space that 
                 //  adding 5 overflowed the address space and wrapped around)
assert(p - arr == 5); //this statement may not be true
                      //the compiler may have assigned p some other value

Ich bin sicher, es gibt viele andere Beispiele, die Sie hier einwerfen können.

Einige Systeme, sehr seltene Systeme und ich kann keins nennen, werden Fallen verursachen, wenn Sie solche Grenzen überschreiten. Darüber hinaus ermöglicht es eine Implementierung, die den Grenzschutz bietet … wieder, obwohl mir keine einfällt.

Im Wesentlichen sollten Sie es nicht tun, und daher gibt es keinen Grund, anzugeben, was passiert, wenn Sie es tun. Zu spezifizieren, was passiert, bedeutet eine ungerechtfertigte Belastung für den Implementierungsanbieter.

Dieses Ergebnis, das Sie sehen, ist auf den segmentbasierten Speicherschutz von x86 zurückzuführen. Ich finde diesen Schutz gerechtfertigt, da Sie beim Erhöhen der Zeigeradresse und Speichern zu einem späteren Zeitpunkt in Ihrem Code den Zeiger dereferenzieren und den Wert verwenden. Der Compiler möchte also solche Situationen vermeiden, in denen Sie am Ende den Speicherort eines anderen ändern oder den Speicher löschen, der einem anderen in Ihrem Code gehört. Um ein solches Szenario zu vermeiden, hat der Compiler die Einschränkung vorgenommen.

Neben Hardwareproblemen war ein weiterer Faktor das Aufkommen von Implementierungen, die versuchten, verschiedene Arten von Programmierfehlern abzufangen. Obwohl viele solcher Implementierungen am nützlichsten sein könnten, wenn sie so konfiguriert würden, dass sie Konstrukte abfangen, die ein Programm bekanntermaßen nicht verwendet, obwohl sie durch den C-Standard definiert sind, wollten die Autoren des Standards das Verhalten von Konstrukten nicht definieren, die –in vielen Programmierbereichen– symptomatisch für Fehler sein.

In vielen Fällen ist es viel einfacher, Aktionen abzufangen, die Zeigerarithmetik verwenden, um die Adresse unbeabsichtigter Objekte zu berechnen, als irgendwie die Tatsache aufzuzeichnen, dass die Zeiger nicht für den Zugriff auf den von ihnen identifizierten Speicher verwendet werden können, aber so modifiziert werden könnten, dass sie dies könnten Zugriff auf andere Speicher. Außer im Fall von Arrays innerhalb größerer (zweidimensionaler) Arrays wäre es einer Implementierung erlaubt, Platz zu reservieren, der “kurz hinter” dem Ende jedes Objekts liegt. Angesichts so etwas wie doSomethingWithItem(someArray+i);, könnte eine Implementierung jeden Versuch abfangen, eine Adresse zu übergeben, die weder auf ein Element des Arrays noch auf das Leerzeichen direkt hinter dem letzten Element zeigt. Wenn die Zuteilung von someArray reservierter Platz für ein zusätzliches ungenutztes Element, und doSomethingWithItem() nur auf das Element zugreift, auf das es einen Zeiger erhält, könnte die Implementierung relativ kostengünstig sicherstellen, dass jede nicht abgefangene Ausführung des obigen Codes – im schlimmsten Fall – auf ansonsten ungenutzten Speicher zugreifen könnte.

Die Fähigkeit, “gerade vorbei”-Adressen zu berechnen, macht die Überprüfung der Grenzen schwieriger, als es sonst der Fall wäre (die häufigste fehlerhafte Situation wäre Passing doSomethingWithItem() ein Zeiger direkt hinter dem Ende des Arrays, aber das Verhalten wäre definiert, es sei denn doSomethingWithItem würde versuchen, diesen Zeiger zu dereferenzieren – etwas, das der Aufrufer möglicherweise nicht beweisen kann). Da der Standard es Compilern jedoch in den meisten Fällen erlauben würde, Platz direkt hinter dem Array zu reservieren, würde eine solche Erlaubnis es Implementierungen ermöglichen, den durch nicht abgefangene Fehler verursachten Schaden zu begrenzen – etwas, das wahrscheinlich nicht praktikabel wäre, wenn eine allgemeinere Zeigerarithmetik erlaubt wäre.