C11: Neue Version der Programmiersprache, Teil 1
Die Anforderungen an Programmiersprachen ändern sich mit der Zeit. Auch das Standardisierungskomitee für C versucht, dem nachzukommen. Der neue ISO/IEC-Standard für C11 wurde im Dezember 2011 offiziell ratifiziert. Der erste von zwei Artikeln stellt lang ersehnte Spracherweiterungen vor.
- Hagen Paul Pfeifer
Die Anforderungen an Programmiersprachen ändern sich mit der Zeit. Auch das Komitee zur Standardisierung für C versucht, dem nachzukommen. Der neue ISO/IEC-Standard für C11 wurde im Dezember 2011 offiziell ratifiziert. Der erste von zwei Artikeln stellt Spracherweiterungen vor, die lange auf der Wunschliste vieler Programmierer standen.
Die Programmiersprache C wurde Ende der 70er-Jahre von Dennis Ritchie und Brian Kernighan an den legendären Bell Telephone Laboratories entwickelt. Ritchie und Kernighan wollten eine Sprache kreieren, die systemnah, aber dennoch möglichst plattformunabhängig ist, performanten Code erzeugt und eine konsistente Syntax besitzt. Diese und weitere Anforderungen wurden mit C abgedeckt und sind 40 Jahre später keinesfalls obsolet. Der Kernel der meisten Betriebssysteme ist in C programmiert. Im Embedded-Umfeld, in dem die Nähe zur Hardware fundamentale Voraussetzung sowie kompakter und effizienter Code zu erzeugen ist, ist C nach wie vor die Sprache Nummer eins. Last, but not least erfreut sich C im gesamten unixoiden Umfeld großer Beliebtheit.
Doch die Anforderungen an Programmiersprachen ändern sich im Laufe der Zeit. Für wirksame Verjüngungskuren zeichnet das ISO/IEC JTC1/SC22 International Standardization Subcommittee for Programming Languages verantwortlich – im Fall von C speziell die Working Group 14. (Andere bekannte Working Groups sind die WG 9 für Ada oder die WG 21 für C++). Dieser Zusammenschluss an Experten überarbeitet Sprachkonstrukte, erweitert sie um neue Funktionen und beseitigt Fehler. Der neue Standard ist ISO/IEC 9899:2011 oder einfach nur C11. Er wurde im Dezember 2011 offiziell ratifiziert.
Um wilden und sprachuntypischen Wünschen den Wind aus den Segeln zu nehmen, verordnet sich die Arbeitsgruppe eine Handvoll Regeln, die sie von Revision zu Revision erweitert. Sie enthalten für C unter anderem den Grundsatz, dass bestehender Code einen hohen Stellenwert besitzt und dass Modifikationen den Geist der Sprache nicht ändern. Dem Nutzer sollen keine künstlichen Steine in den Weg gelegt werden, nur weil er die Sprache unorthodox einsetzt.
Dem Programmierer soll nicht misstrauisch über die Schulter geschaut werden. Das bedeutet beispielsweise, dass bei einer Vielzahl von Funktionen, die auf Speicherbereichen operieren, der Programmierer selbst sicherstellen muss, dass der zu Verfügung stehende Puffer groß genug ist, um das Resultat der Speicheroperation aufzunehmen. Der Compiler vertraut an der Stelle auf den Programmierer.
Bei der jüngsten Standardisierung hat die Arbeitsgruppe diese Prinzipien erneut erweitert. So sollte C um die Fähigkeit ergänzt werden, in internationalen Umgebungen besser mit UTF-16 und UTF-32 zu interagieren. Inkompatibilitäten mit C++ wünschte man zu verringern und das vorab angesprochene Prinzip des Vertrauens zu verfeinern: Die Verantwortung sollte weiterhin beim Programmierer liegen, aber er kann ebenso optionale Mittel nutzen, um seine Arbeit zu überprüfen und dadurch abzusichern.
Oberstes Ziel bei der Standardisierung ist eine vollständige Kompatibilität zum vorhergehenden Standard. Keinesfalls sollten bestehende Programme durch subtile Änderungen Instabilitäten aufweisen. Eine der größten Gruppen von C-Programmierern ist im Embedded-Bereich bei der hardwarenahen Programmierung zu finden. Gerade sie leidet unter der Volatilität der Hardware und sollte nicht noch zusätzlich durch einen neuen C-Standard unter Druck gesetzt werden.
Wie durchschlagend subtil wirkende Änderungen sein können, zeigt ein Beispiel, das beim Übergang von C89 auf C99 auftrat. Den Typ eines Ganzzahl-Literals bestimmt C99 anhand einer definierten Liste: int, long int, long long int. Passt ein Ganzzahl-Literal, beispielsweise 23424242, wertemäßig in ein Integer (int), wird dieser Typ verwendet. Ansonsten wird geprüft, ob ein long int passend ist. Als letzte Option kommt ein long long int zum Einsatz. Unter C89 ist allerdings diese Liste unterschiedlich: int, long int, unsigned long int, long long int. Der vorzeichenlose Ganzzahlentyp unsigned long passt nicht so richtig in die C99-Liste. Konsequenz ist, dass C99 auf einer 32-Bit-Architektur die Zahl 4.000.000.000 als long long interpretiert, während C89 unsigned long verwendet. Das Resultat für 4.100.000.000 > -1 unterscheidet sich also für C99 und C89.
Daneben gibt es weitere subtile Auswirkungen, die selten, aber dennoch ärgerlich sind. Dass solche Designfehler den Programmierer vergrätzen, ist den Mitgliedern der Working Group bewusst, und es wurde während der Entwicklung von C11 besonders darauf geachtet, solche Inkompatibilitäten zu vermeiden.
