Der entscheidende Unterschied zu vielen jüngeren Sprachen ist die Philosophie der Nähe zur Maschine. C wurde bewusst als schlanke Abstraktion über der Hardware entworfen: Es bietet gerade so viel Komfort, dass man nicht in Assembler denken muss, gibt dem Entwickler aber die volle Kontrolle über Speicher und Laufzeitverhalten zurück. Diese Nähe macht C zugleich mächtig und anspruchsvoll – die Sprache nimmt dem Entwickler wenig ab und verlässt sich darauf, dass er weiß, was er tut. Für Teams bedeutet das: sehr effizienter Code, der aber Sorgfalt und Erfahrung verlangt.
Drei Eigenschaften definieren C:
C entstand ohne offiziellen Standard – der De-facto-Bezugspunkt der Frühzeit war ein Buch der beiden Sprachväter, weshalb man vom sogenannten „K&R-C“ spricht, benannt nach Brian Kernighan und Dennis Ritchie. Mit der wachsenden Verbreitung wurde eine verbindliche Vereinheitlichung notwendig: Ende der 1980er standardisierte das amerikanische Normungsgremium ANSI die Sprache, kurz darauf übernahm die internationale Normungsorganisation ISO den Standard. Seither wird C in einem geordneten Prozess über mehrere Revisionen weiterentwickelt, die jeweils behutsam neue Sprachmittel ergänzen, ohne den bewährten Kern über Bord zu werfen.
Für den deutschen Mittelstand ist diese Standardisierung von großer praktischer Bedeutung. Sie bedeutet, dass in ISO-C geschriebener Code herstellerunabhängig ist und über verschiedene Compiler und Plattformen hinweg vergleichbar funktioniert. Wer heute in eine C-Codebasis investiert, setzt auf eine formal genormte, langfristig verfügbare Grundlage – ein wichtiger Faktor für Wartbarkeit, Zertifizierbarkeit und die Unabhängigkeit von einzelnen Anbietern. Die konkrete Revision, die ein Projekt nutzt, sollte am aktuellen Stand geprüft werden, da sich der Sprachstand über die Jahre weiterentwickelt.
Anders als eine breite Anwendungs- oder Skriptsprache ist C selten das Werkzeug für die schnelle Auswertung oder das interne Hilfsprogramm. Seine Domäne liegt eine Schicht tiefer: dort, wo Software direkt mit Hardware, Betriebssystem oder knappen Ressourcen zu tun hat. C ist damit weniger ein Allrounder für jeden Zweck als vielmehr das Fundament, auf dem viele andere Werkzeuge erst aufbauen. Genau diese Rolle macht es für bestimmte Aufgaben unverzichtbar und für andere schlicht zu aufwendig.
Wer C nur als „veraltete Sprache“ abtut, unterschätzt seine anhaltende Bedeutung in Embedded-Systemen und Systemsoftware – und wer es umgekehrt für jede Aufgabe einsetzt, bezahlt einen hohen Preis an Entwicklungszeit und Fehlerrisiko, den modernere Sprachen ihm ersparen würden. Die ehrliche Einordnung dieser Rolle ist das Ziel dieses Artikels.
Das prägendste Merkmal von C ist die kompromisslose Kontrolle über die Maschine. Wo modernere Sprachen dem Entwickler viele Details abnehmen – automatische Speicherverwaltung, umfassende Sicherheitsprüfungen, komfortable Abstraktionen –, gibt C ihm die volle Verantwortung zurück. Das ist kein Versäumnis, sondern Absicht: C soll gerade dort funktionieren, wo diese Abstraktionen zu teuer oder schlicht nicht verfügbar sind, etwa auf einem winzigen Mikrocontroller mit wenigen Kilobyte Speicher.
Diese Kontrolle ist zugleich Stärke und Fallstrick. Sie erlaubt hocheffiziente, präzise auf die Hardware zugeschnittene Programme – verlagert aber die Verantwortung für Korrektheit fast vollständig zum Entwickler. Fehler im Umgang mit Speicher oder Zeigern fängt C nicht automatisch ab; sie führen im ungünstigsten Fall zu Abstürzen, unvorhersagbarem Verhalten oder Sicherheitslücken. Wer mit C arbeitet, braucht daher Disziplin, Erfahrung und geeignete Werkzeuge – ein Punkt, auf den wir im Sicherheits-Kapitel zurückkommen.
C-Code wird vor der Ausführung vollständig in nativen Maschinencode übersetzt. Daraus entsteht eine eigenständige ausführbare Datei, die ohne Interpreter oder umfangreiche Laufzeitumgebung direkt auf dem Zielsystem läuft. Das hat handfeste Vorteile: extrem hohe Ausführungsgeschwindigkeit, ein sehr geringer Ressourcenbedarf und vorhersagbares Laufzeitverhalten, weil keine versteckte Zwischenschicht dazwischenliegt. Für Systemsoftware und eingebettete Geräte ist genau das entscheidend.
Der Preis dieser Bauweise ist der Kompilierschritt und die Plattformbindung. Eine für ein bestimmtes System übersetzte Binärdatei läuft nicht ohne Weiteres auf einer anderen Prozessorarchitektur; für jede Zielplattform muss neu übersetzt werden. In der Praxis ist das gut beherrschbar, erfordert aber eine durchdachte Werkzeugkette – gerade wenn Software für unterschiedliche Geräte oder Steuerungen erstellt wird. Auf dieses Thema gehen wir im Ökosystem-Kapitel genauer ein.
Die Syntax von C hat viele spätere Sprachen geprägt: geschweifte Klammern zur Blockbildung, Semikolons zum Abschluss von Anweisungen, eine klare Trennung von Deklaration und Anweisung. Wer eine der zahlreichen Sprachen kennt, die sich an C orientiert haben, findet sich schnell zurecht. Diese Vertrautheit ist trügerisch: Die Oberfläche wirkt bekannt, doch die darunterliegenden Konzepte – insbesondere der direkte Umgang mit Speicher – unterscheiden sich grundlegend von modernen Hochsprachen und verlangen ein anderes Denken.
Kein Thema ist so eng mit C verbunden wie das der Zeiger. Ein Zeiger ist, vereinfacht gesagt, eine Variable, die nicht einen Wert, sondern die Speicheradresse eines Werts enthält. Über Zeiger lässt sich der Speicher direkt ansprechen, manipulieren und effizient durchlaufen. Das ist die Grundlage dafür, dass C so schlanke und schnelle Programme erzeugt: Datenstrukturen, Puffer und Hardwarezugriffe werden über Zeiger präzise und ohne Umwege verwaltet.
Zugleich sind Zeiger die häufigste Quelle schwerwiegender Fehler. Ein Zeiger, der auf einen ungültigen oder bereits freigegebenen Speicherbereich verweist, führt zu unvorhersagbarem Verhalten, Abstürzen oder Sicherheitslücken – und der Compiler kann viele dieser Fehler nicht erkennen, weil sie erst zur Laufzeit auftreten. Der Umgang mit Zeigern gilt zu Recht als eine der größten Hürden beim Erlernen von C. In professionellen Projekten empfehlen wir daher konsequente Konventionen, gründliche Reviews und den Einsatz spezialisierter Prüfwerkzeuge, um diese Fehlerklasse beherrschbar zu halten.
Eng mit den Zeigern verbunden ist die manuelle Speicherverwaltung. In C reserviert der Entwickler Speicher explizit und gibt ihn ebenso explizit wieder frei, sobald er nicht mehr benötigt wird. Es gibt keinen automatischen Aufräumdienst im Hintergrund, der ungenutzten Speicher einsammelt. Diese Selbstverantwortung ermöglicht extrem sparsames und vorhersagbares Verhalten – ein entscheidender Vorteil in Umgebungen mit knappem Speicher oder harten Echtzeitanforderungen, wo unvorhersehbare Aufräumpausen nicht toleriert werden können.
Die Kehrseite ist eine ganze Klasse typischer Fehler: Wird Speicher nicht freigegeben, entstehen über die Zeit Speicherlecks; wird er zu früh oder mehrfach freigegeben, drohen Abstürze und schwer auffindbare Fehler. Diese Probleme gehören zu den häufigsten und teuersten in C-Projekten. Die Community hat darauf mit bewährten Mustern, klaren Verantwortlichkeiten für Speicher und Analysewerkzeugen reagiert – doch anders als in Sprachen mit automatischer Speicherverwaltung bleibt die Sorgfalt letztlich Aufgabe des Entwicklers.
Eine Besonderheit von C ist der Präprozessor, der den Quelltext vor der eigentlichen Übersetzung bearbeitet. Über ihn werden Header-Dateien eingebunden, Konstanten und Makros definiert und Codeteile je nach Zielplattform ein- oder ausgeblendet. Dieser Mechanismus ist mächtig und für portable, plattformübergreifende Software praktisch unverzichtbar – er kann aber bei unbedachtem Einsatz die Lesbarkeit und Nachvollziehbarkeit von Code erheblich erschweren, weshalb ein disziplinierter Umgang wichtig ist.
Darüber hinaus verfügt C über die klassischen Bausteine strukturierter Programmierung: Kontrollstrukturen, eigene zusammengesetzte Datentypen wie Strukturen, sowie eine bewusst knapp gehaltene Menge an Schlüsselwörtern. Über die Jahre haben die Standard-Revisionen behutsam neue Sprachmittel ergänzt, ohne die Grundphilosophie aufzugeben. Welche Features in welcher Revision verfügbar sind, ändert sich mit dem Sprachstand – der aktuelle Umfang sollte daher stets in der maßgeblichen Norm oder Dokumentation geprüft werden.
C hat keine einzelne Referenz-Laufzeit, sondern eine Vielzahl von Compilern, die den Quelltext in Maschinencode übersetzen. Weit verbreitet sind etwa die freien Compiler GCC und Clang, die auf zahlreichen Plattformen verfügbar sind; daneben existieren kommerzielle und spezialisierte Compiler, insbesondere für eingebettete Systeme und bestimmte Prozessorarchitekturen. Diese Vielfalt ist eine Stärke: Für praktisch jede Hardware, vom Großrechner bis zum winzigen Mikrocontroller, gibt es einen passenden C-Compiler.
Damit Code über diese verschiedenen Compiler hinweg vergleichbar funktioniert, ist die Orientierung am ISO-C-Standard entscheidend. Compiler bieten oft eigene Erweiterungen an, die bequem, aber herstellerspezifisch sind. In Projekten, denen Portabilität und Langlebigkeit wichtig sind, empfehlen wir, sich möglichst am Standard zu halten und Abweichungen bewusst und dokumentiert zu treffen. So bleibt der Code unabhängig von einem einzelnen Werkzeughersteller.
Weil C-Projekte aus vielen Quelldateien bestehen, die in der richtigen Reihenfolge übersetzt und zusammengebunden werden müssen, spielt die Steuerung des Übersetzungsprozesses eine wichtige Rolle. Das klassische Werkzeug hierfür ist Make, das anhand von Regeln entscheidet, welche Teile eines Projekts neu übersetzt werden müssen. Rund um dieses bewährte Grundprinzip hat sich über die Jahre eine ganze Reihe moderner Build-Systeme etabliert, die größere Projekte, plattformübergreifende Übersetzung und Abhängigkeitsverwaltung komfortabler machen.
Für den Mittelstand ist entscheidend, dass diese Build-Kette von Anfang an sauber aufgesetzt wird. Anders als bei manchen modernen Sprachen mit integriertem Paketmanager ist das Zusammenspiel aus Compiler, Build-Werkzeug und externen Bibliotheken in C manueller und erfordert bewusste Entscheidungen. Eine durchdachte, dokumentierte Werkzeugkette ist die Grundlage dafür, dass ein C-Projekt reproduzierbar und über Jahre wartbar bleibt.
Zum Sprachumfang gehört eine kompakte, standardisierte C-Standardbibliothek, die grundlegende Funktionen bereitstellt – etwa für Ein- und Ausgabe, Zeichenkettenverarbeitung, mathematische Operationen und Speicherverwaltung. Diese Bibliothek ist bewusst schlank gehalten, im Einklang mit der Philosophie einer kleinen, effizienten Sprache. Vieles, was in anderen Sprachen fertig mitgeliefert wird, muss in C entweder selbst geschrieben oder über externe Bibliotheken eingebunden werden.
Rund um C existiert eine große Menge etablierter externer Bibliotheken – von Netzwerk- und Kryptografie-Funktionen über Datenformate bis zu hardwarespezifischen Treibern. Anders als in Ökosystemen mit zentralem Paketverzeichnis werden diese Bibliotheken in C oft manueller eingebunden und verwaltet. Das erfordert bewusste Auswahl und Pflege der Abhängigkeiten – ein Punkt, der sowohl für die Wartbarkeit als auch für die Sicherheit relevant ist und den wir im Reife-Kapitel wieder aufgreifen.
Wenn ein Feld Cs anhaltende Bedeutung erklärt, dann ist es die eingebettete und systemnahe Software. Überall dort, wo Programme direkt mit Hardware zusammenarbeiten, mit knappen Ressourcen auskommen oder unter harten Zeitanforderungen laufen müssen, spielt C seine Stärken aus. In der Industrie, im Maschinenbau und in der Fertigung – Kerndomänen des deutschen Mittelstands – steckt C damit in unzähligen Steuerungen, Sensoren und Geräten, oft unsichtbar, aber unverzichtbar.
Der praktische Vorteil geht über die reine Effizienz hinaus. Weil C in diesen Bereichen seit Jahrzehnten Standard ist, existiert ein riesiger Bestand an bewährtem Code, an Werkzeugen und an erfahrenen Entwicklern. Für ein Unternehmen, das eingebettete Systeme baut oder wartet, ist C damit nicht nur eine mögliche, sondern in aller Regel die naheliegende Wahl – ein Faktor, den wir im Mittelstands-Kapitel vertiefen.
Neben den sichtbaren Einsatzgebieten spielt C eine oft übersehene Rolle als Fundament. Die Laufzeitumgebungen und Kernbibliotheken vieler moderner Sprachen sind selbst in C geschrieben; rechenintensive Teile anderer Programme werden häufig in C ausgelagert und von dort angesteuert. C ist damit in vielen Systemen präsent, auch wenn die eigentliche Anwendung in einer ganz anderen Sprache entwickelt wurde.
Für den Mittelstand ist diese Rolle indirekt relevant: Selbst Unternehmen, die selbst kein C entwickeln, verlassen sich über ihre Software-Stapel auf in C geschriebene Komponenten. Ein Grundverständnis dafür, wo C im Fundament steckt, hilft bei Entscheidungen über Wartung, Sicherheit und Abhängigkeiten – auch dann, wenn C nicht die primäre Entwicklungssprache im Haus ist.
C++ ist historisch aus C hervorgegangen und erweitert es um objektorientierte Programmierung, umfangreiche Abstraktionen und eine sehr große Menge zusätzlicher Sprachmittel. Diese Mächtigkeit macht C++ für große, komplexe Systeme attraktiv, in denen strukturierte Abstraktion und Wiederverwendung wichtig sind – zum Preis einer erheblich höheren Komplexität und einer deutlich steileren Lernkurve. C++ ist eine der umfangreichsten Sprachen überhaupt.
C gewinnt dagegen dort, wo Schlankheit, Vorhersagbarkeit und minimaler Ressourcenbedarf zählen. Auf sehr kleiner Hardware, in einfachen Firmware-Projekten oder überall, wo ein möglichst kleiner, überschaubarer Sprachkern gewünscht ist, bleibt C oft die klarere Wahl. Die Faustregel aus unseren Projekten: Je größer und abstraktionsbedürftiger das System, desto eher C++; je kleiner, hardwarenäher und ressourcenknapper, desto eher C. In vielen Häusern koexistieren beide, teils sogar im selben Projekt.
Rust ist eine modernere Systemsprache, die einen zentralen Schwachpunkt von C adressiert: die Speichersicherheit. Über ein besonderes Konzept der Eigentümerschaft von Speicher erzwingt Rust bereits zur Übersetzungszeit, dass viele der typischen Speicherfehler von C gar nicht erst entstehen können – ohne dabei einen Garbage Collector einzusetzen und damit ohne Verzicht auf hardwarenahe Effizienz. Für sicherheitskritische Neuentwicklungen ist das ein starkes Argument, und Rust gewinnt in diesem Feld zunehmend an Bedeutung.
C hält dem seine Reife, seine Allgegenwart und seinen riesigen Bestand entgegen. Für praktisch jede Hardware existiert ein C-Compiler, es gibt Jahrzehnte an bewährtem Code, etablierte Zertifizierungswege und einen großen Pool erfahrener Entwickler. Rust ist jünger, sein Ökosystem für sehr kleine oder exotische Hardware noch nicht überall gleich reif, und die Lernkurve ist anspruchsvoll. Die ehrliche Einordnung: Rust ist die sicherheitsorientierte Alternative für Neues, C bleibt der pragmatische Standard für Bestand und breiteste Hardware-Unterstützung.
Go ist eine kompilierte Sprache mit automatischer Speicherverwaltung, die auf einfache Handhabung, gute Nebenläufigkeit und schnelle Entwicklung ausgelegt ist. Für performante Backend-Dienste und Infrastruktur-Werkzeuge ist Go häufig die produktivere Wahl als C, weil es viele der Fehlerquellen von C von vornherein vermeidet und deutlich zugänglicher ist. Go arbeitet jedoch eine Abstraktionsebene über der Hardware und ist für sehr kleine eingebettete Systeme oder tiefe Hardwarezugriffe nicht gedacht.
Die Arbeitsteilung ist klar: C für hardwarenahe, eingebettete und ressourcenkritische Software; Go für serverseitige Dienste, bei denen Entwicklungsgeschwindigkeit und Wartbarkeit wichtiger sind als die letzte Kontrolle über jedes Byte. Beide Sprachen konkurrieren in der Praxis selten direkt, weil sie unterschiedliche Schichten des Software-Stapels bedienen.
C gilt zu Recht als eine der schnellsten Sprachen überhaupt. Weil der Code vorab in nativen Maschinencode übersetzt wird und keine Interpreter- oder umfangreiche Laufzeitschicht dazwischenliegt, läuft C-Software mit minimalem Overhead und maximaler Effizienz. In vielen Vergleichen dient C sogar als Referenzmaßstab, an dem sich andere Sprachen messen. Für ressourcenkritische Anwendungen – kleine Hardware, harte Zeitanforderungen, hohe Durchsätze – ist dieser Vorsprung oft der entscheidende Grund für die Sprachwahl.
Ebenso wichtig wie die reine Geschwindigkeit ist die Vorhersagbarkeit. Weil C keine automatische Speicherbereinigung im Hintergrund betreibt, gibt es keine unerwarteten Pausen, wie sie in Sprachen mit Garbage Collection auftreten können. Dieses berechenbare Laufzeitverhalten ist in Echtzeit- und sicherheitskritischen Systemen mindestens ebenso wertvoll wie die hohe Geschwindigkeit selbst – und ein zentraler Grund, warum C in diesen Domänen so fest etabliert ist.
Beim Deployment zeigt sich ein anderes Bild als bei interpretierten Sprachen. Das Ergebnis einer C-Übersetzung ist eine eigenständige, native Binärdatei, die auf dem Zielsystem ohne zusätzliche Laufzeitumgebung läuft – das macht die Auslieferung im Prinzip sehr schlank. Die Herausforderung liegt in der Plattformbindung: Eine für eine bestimmte Architektur übersetzte Datei läuft nicht ohne Weiteres auf einer anderen, weshalb für jede Zielhardware neu übersetzt werden muss.
In der Praxis bedeutet das, dass eine durchdachte Werkzeugkette entscheidend ist – insbesondere bei eingebetteten Systemen, wo oft auf einem Entwicklungsrechner für eine andere Zielhardware übersetzt wird. Dieses Vorgehen ist gut etabliert, erfordert aber bewusste Aufmerksamkeit für Compiler-Einstellungen, Abhängigkeiten und die genaue Zielplattform. Für den Mittelstand heißt das: Mit einem sauber aufgesetzten Build- und Auslieferungsprozess ist C-Deployment beherrschbar, aber es ist manueller als bei Sprachen mit integriertem Paket- und Laufzeitmanagement.
Im laufenden Betrieb sind gut geschriebene C-Programme außerordentlich robust und stabil – viele laufen über Jahre oder Jahrzehnte zuverlässig. Die eigentlichen Betriebsrisiken bei C liegen weniger in der Leistung als in der Korrektheit des Codes: Speicherfehler, fehlerhafte Zeiger und mangelnde Prüfung von Eingaben können zu Abstürzen und Sicherheitslücken führen, die sich erst spät und schwer auffindbar zeigen.
Die Gegenmaßnahmen sind etabliert: statische Analysewerkzeuge, die den Code vor der Übersetzung auf typische Fehlermuster prüfen; Laufzeit-Prüfwerkzeuge, die Speicherfehler während der Ausführung aufdecken; strenge Compiler-Warnungen; sowie in kritischen Bereichen verbindliche Codierregelwerke. Wer diese Werkzeuge konsequent einsetzt, macht aus der prinzipiell riskanten manuellen Speicherverwaltung ein beherrschbares Vorgehen. Diese Disziplin ist bei C kein Extra, sondern Voraussetzung für professionellen Einsatz.
Der deutsche Mittelstand ist stark von Industrie, Maschinenbau und Fertigung geprägt – und genau dort ist C zu Hause. In Maschinensteuerungen, Sensoren, Aktoren und eingebetteten Geräten ist C seit Jahrzehnten die dominierende Sprache. Für Unternehmen, die physische Produkte mit Elektronik und Software entwickeln, ist C damit nicht eine Option unter vielen, sondern oft die faktische Grundlage ihrer Produkte. Diese Verankerung in der industriellen Wertschöpfung macht C für weite Teile des Mittelstands anhaltend relevant.
Ein wichtiger Vorteil ist dabei die Nähe zur Hardware, die C bietet. Wo ein Gerät mit sehr knappem Speicher auskommen, unter harten Zeitanforderungen reagieren oder direkt auf Sensoren und Aktoren zugreifen muss, gibt es zu C oft keine praktikable Alternative. Modernere Sprachen mögen komfortabler sein, sind aber für die kleinsten und ressourcenknappsten Zielsysteme häufig schlicht nicht geeignet.
Ein zweischneidiges, aber insgesamt vorteilhaftes Thema ist die Verfügbarkeit von Fachkräften und Wissen. Weil C so lange etabliert ist, gibt es einen großen Bestand an erfahrenen Entwicklern, umfangreiche Literatur und bewährte Praktiken. Gleichzeitig ist zu beobachten, dass jüngere Entwickler häufiger mit modernen Hochsprachen einsteigen und die anspruchsvolle, hardwarenahe C-Entwicklung eine spezialisiertere Kompetenz bleibt. Für Unternehmen bedeutet das, gezielt in den Erhalt und Aufbau dieses Wissens zu investieren.
Der große Trumpf von C für den Mittelstand ist seine Langlebigkeit. C-Code, der vor vielen Jahren geschrieben wurde, läuft und lässt sich oft bis heute weiterpflegen – ein enormer Investitionsschutz für Unternehmen mit langlebigen Produkten. Anders als bei kurzlebigen Technologietrends besteht bei C wenig Risiko, dass die Sprache in absehbarer Zeit verschwindet. Diese Kontinuität ist gerade für Industrieprodukte mit langen Lebenszyklen ein gewichtiges Argument.
Die Kehrseite der Langlebigkeit ist der Umgang mit gewachsenem Altcode. Viele mittelständische Unternehmen betreiben C-Codebasen, die über Jahre oder Jahrzehnte entstanden sind, oft von wechselnden oder inzwischen ausgeschiedenen Entwicklern. Ohne saubere Dokumentation, Versionierung und klare Verantwortlichkeiten wird solcher Code zum Risiko: Änderungen werden riskant, Wissen hängt an einzelnen Personen, und Sicherheitsaktualisierungen unterbleiben.
Die Gegenmaßnahme ist pragmatische Sorgfalt: konsequente Versionierung, verständliche Dokumentation, einheitliche Codierstandards, automatisierte Tests und der Einsatz von Analysewerkzeugen. Gerade bei geschäftskritischem oder sicherheitsrelevantem C-Code ist diese Disziplin die beste Versicherung gegen teure Abhängigkeiten von einzelnen Wissensträgern. Wer Altcode bewusst pflegt und modernisiert, statt ihn nur weiterlaufen zu lassen, sichert die Zukunftsfähigkeit seiner Produkte ab.
C ist über ein halbes Jahrhundert gewachsen, außerordentlich stabil und in einem formalen Normungsprozess der internationalen Normungsorganisation ISO festgeschrieben. Diese Standardisierung ist ein zentrales Merkmal: Sie legt verbindlich fest, wie sich standardkonformer C-Code zu verhalten hat, und macht ihn damit herstellerneutral und über verschiedene Compiler und Plattformen hinweg vergleichbar. Der Standard wird in geordneten Revisionen behutsam weiterentwickelt, wobei der bewährte Kern erhalten bleibt.
Für den Mittelstand ist diese Reife und Kontinuität ein gewichtiges Argument. C ist keine Modeerscheinung, sondern eine langfristig verlässliche, formal genormte Grundlage, für die Werkzeuge, Wissen und Personal dauerhaft verfügbar sein werden. Die Orientierung an der ISO-Norm – statt an compilerspezifischen Erweiterungen – ist dabei die beste Grundlage für portablen, zukunftssicheren und zertifizierbaren Code. Welche Revision im Einzelfall die richtige ist, hängt vom Projekt ab und sollte am aktuellen Stand geprüft werden.
Beim Thema Sicherheit muss man bei C ehrlich sein: Die fehlende automatische Speichersicherheit ist die bekannteste und meistdiskutierte Schwäche der Sprache. Weil C den Umgang mit Speicher und Zeigern vollständig dem Entwickler überlässt und typische Fehler nicht automatisch abfängt, sind Speicherfehler eine der häufigsten Ursachen für ernste Sicherheitslücken in Software überhaupt. Dieser Punkt ist der Hauptgrund, warum modernere Sprachen wie Rust mit dem Versprechen erzwungener Speichersicherheit an Bedeutung gewinnen.
Das bedeutet nicht, dass sich sicheres C nicht schreiben ließe – es bedeutet, dass Sicherheit bei C aktiv erarbeitet werden muss. Die etablierten Gegenmaßnahmen sind klar: statische Analysewerkzeuge, Laufzeit-Speicherprüfung, strenge Compiler-Warnungen, sorgfältige Prüfung aller Eingaben, verbindliche Codierregelwerke in kritischen Bereichen sowie gründliche Code-Reviews. Ebenso wichtig ist der bewusste Umgang mit externen Bibliotheken, die als Teil der Lieferkette gepflegt und auf bekannte Schwachstellen geprüft werden müssen. Der jeweils aktuelle Stand zu bekannten Schwachstellen und Werkzeugen sollte laufend geprüft werden.
Die Sprache C selbst ist ein offener, herstellerneutraler ISO-Standard und unterliegt keinem einzelnen Eigentümer, der Lizenzgebühren für ihre Nutzung erheben könnte. Wer in C entwickelt, zahlt für die Sprache als solche nichts – ein wirtschaftlicher Vorteil, insbesondere für den Mittelstand. Zu unterscheiden ist dies von den Werkzeugen und Bibliotheken: Verbreitete Compiler wie GCC und Clang sind quelloffen und frei nutzbar, während spezialisierte kommerzielle Compiler, etwa für bestimmte eingebettete Zielsysteme, kostenpflichtig sein können.
Wichtig ist zudem der Blick auf die eingebundenen Bibliotheken: Diese unterliegen jeweils eigenen Lizenzen, die von sehr freizügig bis zu solchen mit spürbaren Pflichten reichen können – gerade bei der Weitergabe von Software oder in eingebetteten Produkten ist das relevant. Für den kommerziellen Einsatz sollte daher bekannt sein, welche Lizenzen die genutzten Compiler und Bibliotheken tragen und welche Verpflichtungen daraus folgen. Dies ist eine fachliche Einordnung aus Projektsicht und keine Rechtsberatung; die konkrete lizenzrechtliche Bewertung gehört in die Hände fachkundiger rechtlicher Begleitung.
