Warum hat C ++ 'undefined behaviour' (UB) und andere Sprachen wie C # oder Java nicht?

In diesem Beitrag zum Stapelüberlauf wird eine ziemlich umfassende Liste von Situationen aufgeführt, in denen die C / C ++ - Sprachspezifikation als "undefiniertes Verhalten" deklariert wird. Ich möchte jedoch verstehen, warum andere moderne Sprachen wie C # oder Java nicht das Konzept von "undefiniertem Verhalten" haben. Bedeutet dies, dass der Compiler-Designer alle möglichen Szenarien (C # und Java) steuern kann oder nicht (C und C ++)?

Undefiniertes Verhalten ist eines jener Dinge, die nur im Nachhinein als sehr schlechte Idee erkannt wurden.

Die ersten Compiler waren großartige Erfolge und begrüßten erfreulicherweise Verbesserungen gegenüber der Alternative - Maschinensprache oder Assemblersprachenprogrammierung. Die damit verbundenen Probleme waren bekannt, und Hochsprachen wurden speziell erfunden, um diese bekannten Probleme zu lösen. (Die Begeisterung zu dieser Zeit war so groß, dass HLLs manchmal als "das Ende der Programmierung" bezeichnet wurden - als müssten wir von nun an nur noch trivial aufschreiben, was wir wollten, und der Compiler würde die ganze echte Arbeit erledigen.)

Erst später erkannten wir die neueren Probleme, die mit dem neueren Ansatz einhergingen. Wenn Sie sich nicht auf dem Computer befinden, auf dem der Code ausgeführt wird, besteht die Möglichkeit, dass Dinge stillschweigend nicht das tun, was wir von ihnen erwartet haben. Zum Beispiel würde das Zuweisen einer Variablen typischerweise den Anfangswert undefiniert lassen; Dies wurde nicht als Problem angesehen, da Sie keine Variable zuweisen würden, wenn Sie keinen Wert darin speichern möchten, oder? Sicherlich war es nicht zu viel zu erwarten, dass professionelle Programmierer nicht vergessen würden, den Anfangswert zuzuweisen, oder?

Es stellte sich heraus, dass mit den größeren Codebasen und komplizierteren Strukturen, die mit leistungsfähigeren Programmiersystemen möglich wurden, viele Programmierer tatsächlich von Zeit zu Zeit solche Versehen begehen und das resultierende undefinierte Verhalten zu einem Hauptproblem wurde. Sogar heute ist die Mehrheit der Sicherheitslücken von winzig bis schrecklich das Ergebnis von undefiniertem Verhalten in der einen oder anderen Form. (Der Grund dafür ist, dass undefiniertes Verhalten in der Regel sehr stark von Dingen auf der nächstniedrigeren Computerebene bestimmt wird. Angreifer, die diese Ebene verstehen, können diesen Spielraum nutzen, um ein Programm dazu zu bringen, nicht nur unbeabsichtigte Dinge, sondern genau die Dinge zu tun sie beabsichtigen.)

Seitdem wir dies erkannt haben, gab es einen allgemeinen Drang, undefiniertes Verhalten aus Hochsprachen zu verbannen, und Java war besonders gründlich dabei (was vergleichsweise einfach war, da es ohnehin für die Ausführung auf einer eigens entwickelten virtuellen Maschine ausgelegt war). Ältere Sprachen wie C können nicht einfach so nachgerüstet werden, ohne die Kompatibilität mit der riesigen Menge an vorhandenem Code zu verlieren.

Bearbeiten: Wie bereits erwähnt, ist Effizienz ein weiterer Grund. Undefiniertes Verhalten bedeutet, dass Compiler-Autoren viel Spielraum haben, um die Zielarchitektur auszunutzen, sodass jede Implementierung die schnellstmögliche Implementierung der einzelnen Features erreicht. Dies war bei Maschinen mit geringer Leistung von gestern wichtiger als heute, als das Gehalt der Programmierer häufig der Engpass bei der Softwareentwicklung ist.

Grundsätzlich, weil die Designer von Java und ähnlichen Sprachen kein undefiniertes Verhalten in ihrer Sprache wollten. Dies war ein Kompromiss: Das Zulassen von undefiniertem Verhalten hat das Potenzial, die Leistung zu verbessern, aber die Sprachentwickler legten höheren Wert auf Sicherheit und Vorhersagbarkeit.

Wenn Sie beispielsweise ein Array in C zuweisen, sind die Daten undefiniert. In Java müssen alle Bytes mit 0 (oder einem anderen angegebenen Wert) initialisiert werden. Dies bedeutet, dass die Laufzeit über das Array laufen muss (eine O (n) -Operation), während C die Zuordnung sofort durchführen kann. Daher ist C für solche Operationen immer schneller.

Wenn der Code, der das Array verwendet, es trotzdem vor dem Lesen auffüllt, ist dies für Java im Grunde eine Verschwendung von Aufwand. In dem Fall, in dem der Code zuerst gelesen wird, erhalten Sie in Java vorhersehbare Ergebnisse, in C jedoch unvorhersehbare Ergebnisse.

Undefiniertes Verhalten ermöglicht eine signifikante Optimierung, indem dem Compiler die Möglichkeit gegeben wird, an bestimmten Grenzen oder unter anderen Bedingungen etwas Ungewöhnliches oder Unerwartetes (oder sogar Normales) zu tun.

Siehe http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

Verwendung einer nicht initialisierten Variablen: Dies ist allgemein als Problemquelle in C-Programmen bekannt, und es gibt viele Tools, mit denen diese Probleme behoben werden können: von Compiler-Warnungen bis hin zu statischen und dynamischen Analysatoren. Dies verbessert die Leistung, da nicht alle Variablen beim Erreichen des Gültigkeitsbereichs mit Null initialisiert werden müssen (wie dies bei Java der Fall ist). Für die meisten skalaren Variablen würde dies einen geringen Overhead verursachen, aber Stapelanordnungen und Speicher auf der Malloc-Ebene würden einen Memset des Speichers verursachen, was ziemlich kostspielig sein könnte, insbesondere, da der Speicher normalerweise vollständig überschrieben wird.

Vorzeichenbehafteter Integer-Überlauf: Wenn Arithmetik bei einem Typ 'int' überläuft, ist das Ergebnis undefiniert. Ein Beispiel ist, dass "INT_MAX + 1" nicht garantiert INT_MIN ist. Dieses Verhalten aktiviert bestimmte Optimierungsklassen, die für einen bestimmten Code wichtig sind. Wenn Sie beispielsweise wissen, dass INT_MAX + 1 undefiniert ist, können Sie "X + 1> X" auf "true" optimieren. Wenn Sie wissen, dass die Multiplikation "nicht" überlaufen kann (da dies undefiniert wäre), können Sie "X * 2/2" auf "X" optimieren. Obwohl dies trivial erscheinen mag, werden diese Dinge häufig durch Inlining und Makroexpansion aufgedeckt. Eine wichtigere Optimierung, die dies ermöglicht, ist für "<=" - Schleifen wie diese:

for (i = 0; i <= N; ++i) { ... }

In dieser Schleife kann der Compiler davon ausgehen, dass die Schleife beim Überlauf genau N + 1-mal iteriert, wenn "i" nicht definiert ist, wodurch eine breite Palette von Schleifenoptimierungen möglich ist Beim Überlauf umbrechen, dann muss der Compiler annehmen, dass die Schleife möglicherweise unendlich ist (was passiert, wenn N INT_MAX ist) - wodurch diese wichtigen Schleifenoptimierungen deaktiviert werden. Dies betrifft insbesondere 64-Bit-Plattformen, da so viel Code "int" als Induktionsvariablen verwendet.

In den frühen Tagen von C herrschte viel Chaos. Verschiedene Compiler haben die Sprache unterschiedlich behandelt. Wenn es Interesse gab, eine Spezifikation für die Sprache zu schreiben, musste diese Spezifikation ziemlich abwärtskompatibel mit dem C sein, auf das sich Programmierer bei ihren Compilern stützten. Einige dieser Details sind jedoch nicht portierbar und im Allgemeinen nicht sinnvoll, beispielsweise wenn eine bestimmte Endianess oder ein bestimmtes Datenlayout vorausgesetzt wird. Der C-Standard behält sich daher viele Details als undefiniertes oder implementierungsspezifisches Verhalten vor, was den Compiler-Autoren viel Flexibilität lässt. C ++ baut auf C auf und bietet auch undefiniertes Verhalten.

Java versuchte eine viel sicherere und viel einfachere Sprache als C ++ zu sein. Java definiert die Sprachsemantik im Sinne einer vollständigen virtuellen Maschine. Dies lässt wenig Raum für undefiniertes Verhalten, stellt jedoch Anforderungen, die für eine Java-Implementierung schwierig sein können (z. B. dass Referenzzuweisungen atomar sein müssen oder wie Ganzzahlen funktionieren). Wenn Java potenziell unsichere Vorgänge unterstützt, werden diese normalerweise zur Laufzeit von der virtuellen Maschine überprüft (z. B. einige Casts).

JVM- und .NET-Sprachen haben es einfach:

1. Sie müssen nicht in der Lage sein, direkt mit Hardware zu arbeiten.
2. Sie müssen nur mit modernen Desktop- und Serversystemen oder vernünftigerweise ähnlichen Geräten oder zumindest für sie entwickelten Geräten zusammenarbeiten.
3. Sie können die Garbage-Collection für den gesamten Speicher und die erzwungene Initialisierung festlegen, wodurch die Zeigersicherheit erhöht wird.
4. Sie wurden von einem einzelnen Akteur spezifiziert, der auch die endgültige Umsetzung lieferte.
5. Sie können Sicherheit vor Leistung entscheiden.

Es gibt jedoch gute Punkte für die Auswahl:

1. Die Systemprogrammierung ist ein ganz anderes Spiel, und es ist vernünftig, die Anwendungsprogrammierung kompromisslos zu optimieren.
2. Zugegeben, es gibt immer weniger exotische Hardware, aber kleine eingebettete Systeme sind hier, um zu bleiben.
3. GC ist für nicht fungible Ressourcen ungeeignet und bietet viel mehr Platz für eine gute Leistung. Die meisten (aber nicht fast alle) erzwungenen Initialisierungen können wegoptimiert werden.
4. Mehr Wettbewerb hat Vorteile, aber Komitees bedeuten Kompromisse.
5. Alle diese Grenzen Kontrollen Sie addieren, obwohl die meisten wegoptimiert werden kann. Nullzeigerüberprüfungen können meistens durchgeführt werden, indem der Zugriff aufgrund des virtuellen Adressraums auf null Overhead abgefangen wird, obwohl die Optimierung immer noch unterbunden ist.

Wenn Notluken vorgesehen sind, laden diese zu einem ausgereiften undefinierten Verhalten ein. Zumindest werden sie in der Regel nur in wenigen sehr kurzen Abschnitten verwendet, was die manuelle Überprüfung erleichtert.

Java und C # zeichnen sich zumindest zu Beginn ihrer Entwicklung durch einen dominierenden Anbieter aus. (Sun bzw. Microsoft). C und C ++ sind unterschiedlich; Sie hatten von Anfang an mehrere konkurrierende Implementierungen. C lief vor allem auch auf exotischen Hardware-Plattformen. Infolgedessen gab es Unterschiede zwischen den Implementierungen. Die ISO-Komitees, die standardisiertes C und C ++ vereinbarten, konnten sich auf einen großen gemeinsamen Nenner einigen, aber an den Rändern, an denen Implementierungen voneinander abweichen, ließen die Standards Raum für die Implementierung.

Dies liegt auch daran, dass die Auswahl eines Verhaltens bei Hardwarearchitekturen, die auf eine andere Entscheidung abzielen, möglicherweise teuer ist - Endianness ist die naheliegende Wahl.

Der wahre Grund liegt in einem grundsätzlichen Unterschied in der Absicht zwischen C und C ++ einerseits und Java und C # (für nur einige Beispiele) andererseits. Aus historischen Gründen geht es in den meisten Diskussionen hier eher um C als um C ++, aber (wie Sie wahrscheinlich bereits wissen) ist C ++ ein ziemlich direkter Nachkomme von C, und das, was über C gesagt wird, gilt auch für C ++.

Obwohl sie größtenteils in Vergessenheit geraten sind (und ihre Existenz manchmal sogar geleugnet wird), wurden die allerersten Versionen von UNIX in Assemblersprache geschrieben. Ein Großteil (wenn nicht nur) des ursprünglichen Zwecks von C bestand darin, UNIX von der Assemblersprache auf eine höhere Sprache zu portieren. Teil der Absicht war es, so viel wie möglich des Betriebssystems in einer höheren Sprache zu schreiben - oder es aus der anderen Richtung zu betrachten, um die Menge zu minimieren, die in Assemblersprache geschrieben werden musste.

Um dies zu erreichen, musste C nahezu den gleichen Grad an Zugriff auf die Hardware bieten wie die Assemblersprache. Das PDP-11 (zum Beispiel) hat E / A-Register auf bestimmte Adressen abgebildet. Beispielsweise würden Sie einen Speicherort lesen, um zu überprüfen, ob eine Taste auf der Systemkonsole gedrückt wurde. Ein Bit wurde an dieser Stelle gesetzt, als Daten darauf warteten, gelesen zu werden. Sie haben dann ein Byte von einem anderen angegebenen Speicherort gelesen, um den ASCII-Code der gedrückten Taste abzurufen.

Wenn Sie einige Daten drucken möchten, überprüfen Sie einen anderen angegebenen Speicherort, und wenn das Ausgabegerät bereit ist, schreiben Sie Ihre Daten an einen anderen angegebenen Speicherort.

Um das Schreiben von Treibern für solche Geräte zu unterstützen, haben Sie in C die Möglichkeit, einen beliebigen Speicherort mit einem ganzzahligen Typ anzugeben, ihn in einen Zeiger zu konvertieren und diesen Speicherort im Speicher zu lesen oder zu schreiben.

Natürlich hat dies ein ziemlich ernstes Problem: Nicht jede Maschine auf der Erde verfügt über einen Speicher, der mit einem PDP-11 aus den frühen 1970er Jahren identisch ist. Wenn Sie also diese Ganzzahl nehmen, in einen Zeiger konvertieren und dann über diesen Zeiger lesen oder schreiben, kann niemand eine angemessene Garantie dafür geben, was Sie erhalten werden. Nur für ein naheliegendes Beispiel: Lesen und Schreiben werden möglicherweise separaten Registern in der Hardware zugeordnet. Wenn Sie also etwas schreiben (im Gegensatz zum normalen Speicher), versuchen Sie, es zurückzulesen. Das Gelesene stimmt möglicherweise nicht mit dem überein, was Sie geschrieben haben.

Ich sehe ein paar Möglichkeiten, die sich ergeben:

1. Definieren Sie eine Schnittstelle zu aller möglichen Hardware - geben Sie die absoluten Adressen aller Speicherorte an, die Sie lesen oder schreiben möchten, um auf irgendeine Weise mit der Hardware zu interagieren.
2. Verbieten Sie diese Zugriffsebene, und legen Sie fest, dass jeder, der dies tun möchte, die Assemblersprache verwenden muss.
3. Erlauben Sie es den Leuten, dies zu tun, aber überlassen Sie es ihnen, (zum Beispiel) die Handbücher für die Hardware, auf die sie abzielen, zu lesen und den Code zu schreiben, der zu der von ihnen verwendeten Hardware passt.

Von diesen scheint 1 so absurd, dass es kaum einer weiteren Diskussion wert ist. 2 wirft im Grunde die grundlegende Absicht der Sprache weg. Damit bleibt die dritte Option im Wesentlichen die einzige, die sie vernünftigerweise überhaupt in Betracht ziehen könnten.

Ein weiterer Punkt, der ziemlich häufig auftritt, ist die Größe von Ganzzahltypen. C nimmt die "Position" ein, intdie der natürlichen Größe entsprechen soll, die von der Architektur vorgeschlagen wird. Wenn ich also ein 32-Bit-VAX programmiere, intsollte es wahrscheinlich 32 Bit sein, aber wenn ich ein 36-Bit-Univac programmiere, intsollte es wahrscheinlich 36 Bit sein (und so weiter). Es ist wahrscheinlich nicht sinnvoll (und möglicherweise auch nicht möglich), ein Betriebssystem für einen 36-Bit-Computer nur mit Typen zu schreiben, deren Größe garantiert ein Vielfaches von 8 Bit beträgt. Vielleicht bin ich nur oberflächlich, aber wenn ich ein Betriebssystem für eine 36-Bit-Maschine schreibe, möchte ich wahrscheinlich eine Sprache verwenden, die einen 36-Bit-Typ unterstützt.

Aus sprachlicher Sicht führt dies zu noch undefiniertem Verhalten. Was passiert, wenn ich 1 addiere, wenn ich den größten Wert nehme, der in 32 Bit passt? Bei typischer 32-Bit-Hardware wird ein Rollover ausgeführt (oder möglicherweise ein Hardwarefehler). Auf der anderen Seite, wenn es auf 36-Bit-Hardware läuft, wird es nur ... eine hinzufügen. Wenn die Sprache das Schreiben von Betriebssystemen unterstützt, können Sie keines der beiden Verhalten garantieren - Sie müssen lediglich zulassen, dass sowohl die Größen der Typen als auch das Verhalten des Überlaufs von einem zum anderen variieren.

Java und C # können all das ignorieren. Sie unterstützen nicht das Schreiben von Betriebssystemen. Mit ihnen haben Sie eine Reihe von Möglichkeiten. Eine besteht darin, die Hardware so zu gestalten, wie sie es erfordert - da sie Typen mit 8, 16, 32 und 64 Bit erfordert, müssen Sie nur Hardware erstellen, die diese Größen unterstützt. Die andere naheliegende Möglichkeit besteht darin, dass die Sprache nur auf einer anderen Software ausgeführt wird, die die gewünschte Umgebung bietet, unabhängig davon, welche zugrunde liegende Hardware gewünscht wird.

In den meisten Fällen ist dies keine Entweder-Oder-Wahl. Vielmehr machen viele Implementierungen ein wenig von beidem. Normalerweise führen Sie Java auf einer JVM aus, die auf einem Betriebssystem ausgeführt wird. Meistens ist das Betriebssystem in C und die JVM in C ++ geschrieben. Wenn die JVM auf einer ARM-CPU ausgeführt wird, stehen die Chancen gut, dass die CPU die Jazelle-Erweiterungen von ARM enthält, um die Hardware besser an die Anforderungen von Java anzupassen, sodass weniger Software erforderlich ist und der Java-Code schneller (oder weniger) ausgeführt wird langsam sowieso).

Zusammenfassung

C und C ++ haben ein undefiniertes Verhalten, da niemand eine akzeptable Alternative definiert hat, die es ihnen ermöglicht, das zu tun, was sie beabsichtigt haben. C # und Java verfolgen einen anderen Ansatz, aber dieser Ansatz passt (wenn überhaupt) schlecht zu den Zielen von C und C ++. Insbesondere scheint keines der beiden Verfahren eine vernünftige Möglichkeit zu bieten, Systemsoftware (z. B. ein Betriebssystem) auf die am meisten willkürlich ausgewählte Hardware zu schreiben. Beides hängt in der Regel von Funktionen ab, die von vorhandener Systemsoftware (normalerweise in C oder C ++ geschrieben) bereitgestellt werden, um ihre Arbeit zu erledigen.

Die Autoren des C-Standards erwarteten von ihren Lesern, dass sie etwas erkannten, was sie für offensichtlich hielten und in ihrer veröffentlichten Begründung anspielten, sagten jedoch nicht direkt: Das Komitee sollte keine Compiler-Autoren bestellen müssen, um die Bedürfnisse ihrer Kunden zu erfüllen. da die Kunden besser als der Ausschuss wissen sollten, was ihre Bedürfnisse sind. Wenn es offensichtlich ist, dass Compiler für bestimmte Arten von Plattformen erwartet werden, dass sie ein Konstrukt auf eine bestimmte Weise verarbeiten, sollte es niemanden interessieren, ob der Standard besagt, dass das Konstrukt Undefiniertes Verhalten aufruft. Das Versäumnis des Standards, konforme Compiler zur sinnvollen Verarbeitung von Code zu verpflichten, impliziert in keiner Weise, dass Programmierer bereit sein sollten, Compiler zu kaufen, die dies nicht tun.

Dieser Ansatz für Sprachdesign funktioniert sehr gut in einer Welt, in der Compiler-Autoren ihre Waren an zahlende Kunden verkaufen müssen. Es zerfällt völlig in einer Welt, in der Compiler-Autoren von den Auswirkungen des Marktes isoliert sind. Es ist zweifelhaft, ob es jemals die richtigen Marktbedingungen geben wird, um eine Sprache so zu steuern, wie sie in den 90er Jahren populär wurde, und noch zweifelhafter, ob sich ein vernünftiger Sprachdesigner auf solche Marktbedingungen verlassen möchte.

C ++ und c haben beide beschreibende Standards (die ISO-Versionen jedenfalls).

Die nur existieren, um zu erklären, wie die Sprachen funktionieren, und um einen einzigen Verweis darüber zu geben, was die Sprache ist. In der Regel geben Compiler-Anbieter und Bibliotheksschreiber die Richtung vor und einige Vorschläge werden in den ISO-Hauptstandard aufgenommen.

Java und C # (oder Visual C #, von dem ich annehme, dass Sie es meinen) haben vorgeschriebene Standards. Sie sagen Ihnen, was in der Sprache definitiv vor der Zeit ist, wie es funktioniert und was als erlaubtes Verhalten gilt.

Wichtiger noch ist, dass Java tatsächlich eine "Referenzimplementierung" in Open-JDK hat. (Ich denke, Roslyn zählt als Visual C # -Referenzimplementierung, konnte aber keine Quelle dafür finden.)

In Javas Fall, wenn der Standard mehrdeutig ist und Open-JDK dies auf eine bestimmte Weise tut. Die Art und Weise, wie Open-JDK dies tut, ist der Standard.

Undefiniertes Verhalten ermöglicht es dem Compiler, auf einer Vielzahl von Architekturen sehr effizienten Code zu generieren. Eriks Antwort erwähnt die Optimierung, aber sie geht darüber hinaus.

Beispielsweise sind signierte Überläufe in C undefiniertes Verhalten. In der Praxis sollte der Compiler einen einfachen signierten Additions-Opcode für die CPU generieren, der ausgeführt werden sollte.

Dies ermöglichte es C, auf den meisten Architekturen eine sehr gute Leistung zu erbringen und sehr kompakten Code zu erzeugen. Wenn der Standard festgelegt hätte, dass vorzeichenbehaftete Ganzzahlen auf bestimmte Weise überlaufen müssen, hätten CPUs, die sich anders verhalten, viel mehr Code für eine einfache vorzeichenbehaftete Addition benötigt.

Das ist der Grund für einen Großteil des undefinierten Verhaltens in C und warum Dinge wie die Größe von intzwischen Systemen variieren. Intist architekturabhängig und wird im Allgemeinen als der schnellste und effizienteste Datentyp ausgewählt, der größer als a ist char.

Als C neu war, waren diese Überlegungen wichtig. Computer waren weniger leistungsfähig und verfügten oft über eine begrenzte Verarbeitungsgeschwindigkeit und Speicher. C wurde dort eingesetzt, wo es auf Leistung ankommt, und von den Entwicklern wurde erwartet, dass sie verstehen, wie Computer gut genug funktionieren, um zu wissen, wie sich diese undefinierten Verhaltensweisen auf ihren jeweiligen Systemen auswirken würden.

Spätere Sprachen wie Java und C # haben es vorgezogen, undefiniertes Verhalten gegenüber unformatierter Leistung zu eliminieren.

In gewissem Sinne hat Java es auch. Angenommen, Sie haben Arrays.sort einen falschen Komparator zugewiesen. Es kann eine Ausnahme auslösen, wenn es es erkennt. Andernfalls wird ein Array auf eine Weise sortiert, von der nicht garantiert wird, dass sie eine bestimmte ist.

Wenn Sie eine Variable aus mehreren Threads ändern, sind die Ergebnisse ebenfalls nicht vorhersehbar.

C ++ ist nur noch einen Schritt weiter gegangen, um mehr Situationen undefiniert zu machen (oder besser gesagt, Java hat beschlossen, mehr Operationen zu definieren) und einen Namen dafür zu haben.