Die Sprache C beantwortete eine konkrete Frage der 1970er Jahre: Wie lässt sich ein Betriebssystem so hardwarenah schreiben, dass es effizient bleibt, ohne es bei jedem Rechnerwechsel fast vollständig neu entwickeln zu müssen?
Dennis Ritchie entwickelte C in den Bell Labs im Umfeld von Unix. Die Sprache versucht nicht, die Maschine zu verbergen. Stattdessen bietet sie einen kleinen Satz von Abstraktionen — Typen, Funktionen, Strukturen und Zeiger —, die ein Compiler auf unterschiedlichen Architekturen effizient übersetzen kann. Dieser Kompromiss erklärt ihre Verbreitung, aber auch jene Speicherfehler, die neuere Sprachen zu verhindern versuchen.
Vor C: BCPL und B
In den 1960er Jahren wurde Systemsoftware noch überwiegend in Assembler geschrieben. Damit ließ sich der Prozessor präzise steuern, doch jede Architektur besaß eigene Anweisungen. Ein Programm zu portieren bedeutete häufig, große Teile neu zu schreiben.
Martin Richards entwickelte 1967 BCPL als kompakte Sprache unter anderem für Compiler und Systeme. Ken Thompson leitete daraus B für die frühen Unix-Versionen ab. B vereinfachte die Arbeit gegenüber Assembler, doch sein weitgehend untypisiertes Modell war für Maschinen gedacht, die um Speicherwörter organisiert waren.
Der PDP-11, auf dem Unix weiterentwickelt wurde, konnte Bytes adressieren und Daten unterschiedlicher Größe verarbeiten. Ritchie ergänzte Typen, verbesserte Arrays und Strukturen und verwandelte „New B“ zwischen 1971 und 1973 schrittweise in C.
Eine von Unix geprägte Sprache
C wurde nicht erst theoretisch entworfen und anschließend auf Unix angewandt. Sprache und System entwickelten sich gemeinsam. Die Anforderungen des Kernels brachten C dazu, Adressen, Zeichen, Speicherblöcke und Datenstrukturen mit geringem Overhead darzustellen.
Ein Zeiger enthält die Adresse eines Datums. Damit lassen sich Arrays durchlaufen, verkettete Listen aufbauen oder Geräte ansprechen. Diese Flexibilität garantiert jedoch nicht, dass eine Adresse gültig ist. Ein Programm kann über das Ende eines Arrays hinaus lesen, bereits freigegebenen Speicher verwenden oder Bytes unter einem falschen Typ interpretieren.
Auch einige Details überlässt C der Implementierung, etwa Integergrößen, Byte-Reihenfolge oder die Ausrichtung von Strukturen. Portabler Code muss sich daher an die von C garantierten Eigenschaften halten und darf nicht von zufällig beobachteten Merkmalen einer bestimmten Maschine abhängen.
Die Neuschreibung von Unix verändert die Tragweite des Projekts
1973 wurde der größte Teil des Unix-Kernels in C neu geschrieben. Einige hardwareabhängige Abschnitte blieben in Assembler, doch der überwiegende Teil des Systems konnte nun für eine neue Architektur neu kompiliert werden.
Das bedeutete nicht, dass C jedes Programm automatisch portabel machte. Treiber und Hardwareannahmen mussten weiterhin angepasst werden. Es zeigte jedoch, dass ein leistungsfähiges Betriebssystem in einer höheren Sprache ausgedrückt werden konnte, ohne an einen einzelnen Prozessor gebunden zu sein.
Unix verbreitete sich anschließend mit Quellcode und Werkzeugen an Universitäten. Studierende lernten das System und seine wichtigste Sprache, schrieben neue Programme und trugen diese Praktiken später in die Industrie. C profitierte von Unix; Unix wurde durch C anpassungsfähiger.
Kleine Syntax, entscheidende Bibliothek
C besitzt nur wenige eingebaute Konstrukte. Ein-/Ausgabe, Zeichenkettenverarbeitung und dynamische Speicherverwaltung stammen überwiegend aus Bibliotheken. Diese Trennung hält den Sprachkern kompakt und ermöglicht Implementierungen in sehr unterschiedlichen Umgebungen.
Die Standardbibliothek bildet dennoch einen unverzichtbaren Vertrag. Eine Funktion wie fopen verhindert, dass jedes Programm die genaue Systemschnittstelle zum Öffnen einer Datei kennen muss. Portabilität beruht damit auf drei Elementen: Sprache, Compiler und kompatibler Bibliothek.
Die Übersetzung erzeugt üblicherweise nativen Code. C schreibt weder eine virtuelle Maschine noch eine Garbage Collection vor. Der Programmierer kontrolliert die Lebensdauer von Allokationen, was vorhersehbare Ressourcenprofile ermöglicht, aber die Verantwortung erhöht.
Von „K&R C“ zum internationalen Standard
1978 veröffentlichten Brian Kernighan und Dennis Ritchie The C Programming Language. Das Buch beschrieb die Sprache so präzise, dass es zur faktischen Referenz wurde. Diese Variante wird häufig K&R C genannt.
Mit der wachsenden Zahl von Compilern traten Unterschiede zutage. 1983 begann ein ANSI-Komitee mit der Definition eines gemeinsamen Standards. C89 formalisierte Sprache und Bibliothek; 1990 übernahm die ISO den Standard.
Spätere Revisionen ergänzten vorsichtig neue Typen, Werkzeuge für Nebenläufigkeit und Klarstellungen. Die Entwicklung bleibt durch Kompatibilität begrenzt: riesige Codebestände und zahlreiche Systemschnittstellen hängen vom historischen Verhalten von C ab.
Warum C so viele Sprachen beeinflusst hat
C++ ging direkt aus C hervor und ergänzte reichere Abstraktionen. Objective-C verband C mit einem von Smalltalk inspirierten Objektmodell. Java, JavaScript, C# und Go übernahmen Teile seiner Syntax, jedoch nicht dasselbe Speichermodell.
Diese syntaktische Verwandtschaft darf unterschiedliche Verträge nicht verdecken. Java schützt Speicherzugriffe stärker durch eine virtuelle Maschine. Rust versucht, Lebensdauern über sein Typsystem abzusichern. Go verwendet Garbage Collection. Alle reagieren auf ihre Weise auf die Kosten der direkten Kontrolle, die C bietet.
C bleibt eine gemeinsame Schnittstelle in Betriebssystemen, Bibliotheken und eingebetteten Umgebungen. Selbst eine speichersichere Sprache muss häufig mit einer in C entworfenen API kommunizieren.
Die Grenzen des Vertrauens in den Programmierer
Der C-Standard definiert undefiniertes Verhalten: Verletzt ein Programm bestimmte Regeln, ist kein bestimmtes Ergebnis vorgeschrieben. Der Compiler darf dann optimieren, indem er annimmt, dass solche Situationen nicht auftreten. Diese Freiheit begünstigt Leistung, macht manche Fehler aber schwer vorhersehbar.
Pufferüberläufe und Lebensdauerfehler haben zahlreiche Sicherheitslücken verursacht. Compiler, statische Analyse, Laufzeitschutz und Programmierrichtlinien verringern die Risiken, beseitigen sie aber nicht. C bleibt sinnvoll, wenn präzise Kontrolle und breite Kompatibilität unverzichtbar sind; es ist deshalb nicht automatisch die beste Wahl für jede Software.
Warum C weiterhin wichtig ist
C etablierte eine außergewöhnlich langlebige Abstraktionsebene zwischen Assembler und höherer Software. Hardware-nahe Operationen lassen sich in einer Notation ausdrücken, die mehrere Architekturen teilen können.
Seine Geschichte zeigt, dass eine erfolgreiche Abstraktion nicht zwingend alle Kosten versteckt. Sie kann sie auch handhabbar machen. Der Preis dieser Transparenz ist eine Disziplin, die die Sprache selbst nur begrenzt erzwingt und die Teams, Werkzeuge und Standards ergänzen müssen.
Zeitleiste
1967: Martin Richards stellt BCPL vor.
1969–1970: Ken Thompson entwickelt B für frühe Unix-Werkzeuge.
1971–1972: Dennis Ritchie entwickelt B auf dem PDP-11 zu C weiter.
1973: Der größte Teil des Unix-Kernels wird in C neu geschrieben.
1978: The C Programming Language erscheint.
1983: Das ANSI-Komitee X3J11 beginnt seine Arbeit.
1989: Der ANSI-C-Standard wird veröffentlicht.
1990: C wird als ISO-Standard übernommen.
1999: C99 ergänzt unter anderem neue Typen und numerische Werkzeuge.
2011: C11 führt unter anderem ein Speichermodell für Nebenläufigkeit ein.
Heute: C bleibt zentral für Systeme, Embedded-Software und Softwareschnittstellen.
Häufig gestellte Fragen
Hat Dennis Ritchie C allein entwickelt?
Er war der wichtigste Entwickler. Die Sprache entstand jedoch im kollektiven Umfeld der Bell Labs im Zusammenspiel mit B, Unix, Anwendern und Compilern.
Ist C von Natur aus portabel?
C erleichtert Portabilität, doch ein Programm kann von Hardwaredetails oder Erweiterungen abhängen. Echte Portabilität erfordert die Einhaltung des Standards und die Isolation plattformspezifischen Codes.
Was ist der Unterschied zwischen C und C++?
C++ leitet sich von C ab und ergänzt unter anderem Klassen, Templates, Überladung und deterministische Ressourcenverwaltung. Beide Sprachen besitzen heute eigene Standards und sind nicht vollständig kompatibel.
Warum hat C keine Garbage Collection?
Das Design bevorzugt eine kleine Laufzeitumgebung und explizite Ressourcenkontrolle. Eine Implementierung kann einen Collector ergänzen, doch die Standardsprache verlangt ihn nicht.
Ist C noch eine gute Sprache für den Einstieg?
C vermittelt Datenrepräsentation und Speicherverhalten, führt aber schnell zu komplexen Risiken. Ob es sich eignet, hängt vom Lernziel und Einsatzgebiet ab.
Wird C durch sicherere Sprachen ersetzt werden?
Neue Projekte bevorzugen teilweise Rust oder andere Sprachen, wenn Speichersicherheit Priorität hat. Der enorme Bestand an Code, Werkzeugen und bestehenden Schnittstellen sichert C dennoch eine lange Koexistenz.
Wie das Team um John Backus FORTRAN entwickelte, Wissenschaftler von einer Hochsprache überzeugte und ein dauerhaftes Erbe des numerischen Rechnens begründete.
