strings and arrays in c

Es war drei Uhr morgens, als das Telefon klingelte. Ein mittelständischer Automobilzulieferer aus Baden-Württemberg hatte ein Problem: Ihre Diagnose-Software für Steuergeräte stürzte unvorhersehbar ab, aber nur bei Kunden in Frankreich. Der Schaden belief sich pro Stunde Stillstand in der Werkstatt auf mehrere tausend Euro. Nach zwei Stunden Code-Review fand ich das Problem: Ein Puffer war für deutsche Kennzeichen ausgelegt, aber die längeren französischen Eingaben überschrieben den Speicher daneben. Das ist der klassische Moment, in dem die Theorie der Informatikvorlesung auf die harte Realität von Strings And Arrays In C trifft. Wer glaubt, dass ein Array einfach nur eine Liste von Daten ist, hat den ersten Schritt in Richtung eines kostspieligen Speicherfehlers bereits getan. In C gibt es kein Sicherheitsnetz, keine automatische Längenprüfung und keinen Garbage Collector, der hinter einem aufräumt. Wenn man hier patzt, schmiert nicht nur das Programm ab, sondern man öffnet Tür und Tor für Sicherheitslücken, die ganze Firmennetzwerke gefährden können.

Der fatale Glaube an die magische Null am Ende

Einer der häufigsten Fehler, den ich in über fünfzehn Jahren Praxis gesehen habe, ist das Ignorieren des Null-Terminators \0. Viele Programmierer behandeln Zeichenketten wie einfache Listen von Buchstaben. Das ist gefährlich. In C ist ein String nur so lange ein String, wie er mit einem Null-Byte endet. Fehlt dieses Byte, liest die Funktion printf oder strcpy einfach weiter im Arbeitsspeicher, bis sie zufällig auf eine Null stößt.

Stellen Sie sich vor, Sie reservieren Platz für zehn Zeichen. Sie kopieren "Stuttgart" hinein – neun Buchstaben plus die Null. Das passt. Jetzt kommt jemand und schreibt "Düsseldorf". Das sind zehn Buchstaben. Wenn Sie jetzt kein elftes Byte für die Null reserviert haben, überschreibt die Funktion das nächste Byte im Speicher. Das kann eine andere Variable sein, ein Funktionszeiger oder die Rücksprungadresse auf dem Stack. Ich habe Projekte gesehen, bei denen solche Fehler erst nach sechs Monaten im Feld auftauchen, weil der Speicherbereich daneben zufällig meistens eine Null enthielt. Die Lösung ist simpel, aber wird ständig vergessen: Reservieren Sie immer n + 1 Bytes und setzen Sie das letzte Byte explizit auf Null, wenn Sie mit Funktionen arbeiten, die keine Längenbegrenzung haben. Verlassen Sie sich niemals darauf, dass der Compiler das für Sie erledigt.

Sicherheitsrisiken durch Strings And Arrays In C vermeiden

Es gibt einen Grund, warum Funktionen wie gets() aus dem Standard verbannt wurden und warum erfahrene Entwickler bei strcpy() oder strcat() nervös werden. Diese Funktionen wissen nicht, wie groß Ihr Zielpuffer ist. Sie kopieren blind drauflos. Ein Angreifer kann dies für einen Buffer Overflow ausnutzen. In der industriellen Praxis bedeutet das: Verwenden Sie konsequent die "n"-Varianten der Funktionen wie strncpy() oder besser noch plattformspezifische sicherere Alternativen wie strlcpy(), sofern verfügbar.

Aber Vorsicht, auch strncpy() ist tückisch. Wenn die Quelle länger ist als der Zielpuffer, terminiert strncpy() das Ziel nicht mit einer Null. Das Programm läuft weiter, ist aber instabil. Ein erfahrener Praktiker schreibt sich daher oft eigene Wrapper-Funktionen, die unter allen Umständen eine Null-Terminierung garantieren. Wer hier Zeit sparen will, zahlt später doppelt bei der Fehlersuche. Sicherheit in C ist kein Feature, das man am Ende hinzufügt; es ist eine Arbeitsweise, die bei jedem einzelnen Array-Zugriff präsent sein muss.

Arrays sind keine Pointer und Pointer sind keine Arrays

Dies ist der Punkt, an dem die meisten Einsteiger den Halt verlieren. Ja, der Name eines Arrays zerfällt in vielen Kontexten zu einem Zeiger auf das erste Element. Aber ein Array ist ein fester Block Speicher, dessen Größe dem Compiler bekannt ist (solange er im Scope ist). Ein Zeiger ist lediglich eine Adresse.

Das Problem mit sizeof

Ein klassisches Szenario: Ein Entwickler übergibt ein Array an eine Funktion und versucht darin mit sizeof(array) / sizeof(array[0]) die Anzahl der Elemente zu berechnen. Innerhalb der Funktion ist array aber nur noch ein Zeiger. Das Ergebnis von sizeof ist dann die Größe eines Pointers (meist 8 Byte auf 64-Bit-Systemen), nicht die des ursprünglichen Arrays.

Ich habe miterlebt, wie ein Team tagelang einen Bug suchte, bei dem nur die ersten zwei Elemente einer Liste verarbeitet wurden, weil der Pointer auf einem 64-Bit-System eben 8 Byte groß war und die Elemente int (4 Byte) waren. 8 durch 4 ergibt 2. Das Programm lief technisch einwandfrei, rechnete aber mit falschen Daten. Übergeben Sie die Länge eines Arrays immer als separaten Parameter an die Funktion. Alles andere ist russisches Roulette mit Ihrem Quellcode.

Manuelle Speicherverwaltung als Stolperstein

Wenn wir über dynamische Arrays reden, kommen wir an malloc und free nicht vorbei. Der Fehler hier ist selten, dass jemand vergisst, Speicher zu reservieren. Der Fehler ist, dass die Besitzverhältnisse unklar sind. Wer ist dafür verantwortlich, den Speicher wieder freizugeben? Wenn eine Funktion Speicher alloziert und ihn zurückgibt, muss der Aufrufer wissen, dass er ihn freigeben muss.

In komplexen Systemen führt das ohne klare Regeln zu Memory Leaks. Ich habe einmal ein System analysiert, das nach 48 Stunden Betrieb wegen Speichermangels abstürzte. Es verlor nur 16 Bytes pro eingehender Nachricht. Bei Millionen von Nachrichten summiert sich das. Die Lösung ist ein strenges Ressourcen-Management: Wer alloziert, gibt auch frei, oder es gibt eine klar definierte Übergabe der Verantwortung ("Ownership"). Ein guter Trick ist es, so oft wie möglich auf dem Stack zu arbeiten, wenn die Größe zur Kompilierzeit bekannt ist. Der Stack räumt sich selbst auf und ist zudem deutlich schneller als der Heap.

Ein Vorher-Nachher-Vergleich aus der Praxis

Schauen wir uns an, wie ein typischer Fehler bei der Verarbeitung von Benutzereingaben aussieht und wie man es professionell löst.

Der naive Ansatz: Ein Programmierer möchte einen Pfadnamen einlesen und ein Suffix anhängen. Er erstellt ein Array char path[256] und nutzt scanf("%s", path). Danach fügt er mit strcat(path, ".log") die Dateiendung hinzu. Das Problem: Wenn der Benutzer einen Pfad mit 255 Zeichen eingibt, kracht es beim strcat. Wenn der Pfad Leerzeichen enthält, liest scanf nur bis zum ersten Leerzeichen. Das Programm ist instabil und unsicher.

Der professionelle Ansatz: Zuerst wird die Größe des Puffers als Konstante definiert. Dann wird fgets() verwendet, da man hier die maximale Länge angeben kann. fgets liest auch Leerzeichen und stoppt sicher am Pufferende. Vor dem Anhängen des Suffixes wird mit strlen() geprüft, ob noch genug Platz im Puffer ist. Falls nicht, wird eine Fehlermeldung ausgegeben, statt den Speicher zu korrumpieren. Im Falle einer dynamischen Anforderung würde man den Speicher mit realloc vergrößern, aber nur, wenn man den Rückgabewert validiert, um keinen Speicherverlust bei einem Fehlschlag zu riskieren. Dieser Unterschied in der Herangehensweise unterscheidet einen Bastler von jemandem, der Strings And Arrays In C wirklich beherrscht.

Mehrdimensionale Arrays und das Speicherlayout

Ein weiterer Ort für Performance-Killer sind mehrdimensionale Arrays. In C liegen diese zeilenweise hintereinander im Speicher ("row-major order"). Wer ein großes Bild verarbeitet und spaltenweise statt zeilenweise durch die Pixel geht, ruiniert seine Cache-Lokalität.

In einem Projekt zur Bildverarbeitung konnten wir die Geschwindigkeit eines Filters um den Faktor 10 steigern, indem wir lediglich die beiden verschachtelten For-Schleifen vertauscht haben. Das Programm hat vorher ständig Daten aus dem langsamen RAM nachladen müssen, weil die CPU nicht vorhersagen konnte, welcher Pixel als Nächstes gebraucht wird. Wenn man zeilenweise arbeitet, kann die CPU die Daten effizient vorladen. Das sind die Details, die man nur lernt, wenn man die Hardware unter dem C-Code versteht. Ein Array ist kein abstraktes mathematisches Konstrukt; es ist ein physischer Bereich auf einem Siliziumchip.

Der Mythos der Performance um jeden Preis

Oft höre ich das Argument, man müsse direkt mit Zeigerarithmetik arbeiten, weil das schneller sei als der Zugriff über Indizes wie array[i]. Das ist in 99 % der Fälle Unsinn. Moderne Compiler wie GCC oder Clang sind extrem gut darin, Array-Zugriffe zu optimieren. Sie erkennen Muster und nutzen Vektor-Instruktionen der CPU (SIMD).

Wenn Sie manuell mit Zeigern hantieren, machen Sie den Code oft nur schwerer lesbar und anfälliger für "Off-by-one"-Fehler. Ein Index-Zugriff ist klar und deutlich. Nutzen Sie Zeigerarithmetik nur dann, wenn Sie wirklich einen triftigen Grund haben, zum Beispiel wenn Sie einen Stream parsen, bei dem Sie keinen festen Startpunkt haben. Ansonsten gilt: Lesbarkeit spart Wartungskosten, und Wartungskosten sind in der Softwareentwicklung meist höher als die Kosten für ein paar zusätzliche CPU-Zyklen.

Ein ehrlicher Realitätscheck

Kommen wir zum Punkt: C zu programmieren bedeutet, die volle Verantwortung zu übernehmen. Es gibt keine Abkürzung, um die Komplexität von manuellem Speichermanagement zu umgehen. Wenn Sie mit dieser Strategie erfolgreich sein wollen, müssen Sie akzeptieren, dass Sie mehr Zeit mit dem Nachdenken über Grenzfälle verbringen werden als mit dem eigentlichen Schreiben von Code.

In der echten Welt bedeutet das:

• Jede Funktion, die ein Array annimmt, muss auch dessen Größe kennen.
• Jeder String muss explizit null-terminiert werden.
• Jeder Rückgabewert von malloc muss auf NULL geprüft werden.
• Jede Schleife muss strikt auf ihre Grenzen kontrolliert werden.

Das klingt mühsam, und das ist es auch. Aber es ist der einzige Weg, um Software zu schreiben, die nicht nur auf Ihrem Rechner funktioniert, sondern auch unter Last, in widrigen Umgebungen und gegen böswillige Eingaben besteht. Wer nicht bereit ist, diese Disziplin aufzubringen, sollte lieber Sprachen wie Python oder Rust verwenden. C verzeiht nichts. Ein einziger falscher Index kann ein Projekt, das Millionen gekostet hat, zum Einsturz bringen. Wenn Sie sich aber die Mühe machen, diese Grundlagen wirklich zu verinnerlichen, dann beherrschen Sie eine der mächtigsten Werkzeuge der Informatik. Es braucht Monate, um es zu verstehen, und Jahre, um es zu meistern. Fangen Sie damit an, defensiv zu programmieren. Gehen Sie immer davon aus, dass die Eingabe zu lang, das Array zu klein und der Speicher voll ist. Wenn Sie so denken, haben Sie eine Chance, stabilen Code zu produzieren.