Wenn man mit dynamischer Speicherverwaltung arbeitet, muß sicher
gestellt sein, daß das Programm deutlich mehr Speicher zur Verfügung
gestellt bekommt, als es tatsächlich braucht. Einerseits verbraucht die
Heapverwaltungs selbst einiges, zum anderen muß man mit
Heapfragmentierung rechnen, die unter ungünstigen Umständen dazu führen
kann, daß zwar rechnerisch der größte Teil des Speichers frei ist, der
Heapallocator aber keinen ausreichend großen freien Block finden kann,
um eine Allokation erfolgreich zu beenden.
Das sind schon ausreichend Gründe, keine dynamische Speicherverwaltung
für die Winzbüchsen zu implementieren.
Dynamische Speicherverwaltung hat aber einen weiteren, sehr
schwerwiegenden Nachteil, den man gerne übersieht: Sie ist die Grundlage
für eine Klasse von Fehlern, die selbst für Experten äußerst harte Nüsse
darstellen. Stichwort Heapcorruption.
Solche Fehler sind deshalb so schwer zu finden, weil
- es meist ziemlich aussichtslos ist, stabile Testbedingungen
herzustellen.
- die Auswirkungen von Adressierfehlern u.U. erst sehr viel später
und an ganz anderer Stelle zu Ausfällen führen, der Kausalzusam-
menhang zwischen der Fehlerursache und der Auswirkung meist
nachträglich nicht zu rekonstruieren ist.
Dabei sind weniger die Routinen des Heapmangers das Problem, als der
Anwendungscode, denn letzterer ist i.d.R. deutlich weniger erprobt, als
ersterer.
Das Ganze ist ein uneinschätzbares Sicherheitsrisiko - also Finger weg,
wenn es um irgendwelche Gerätesteuerungen geht, die unter welchen
Umständen auch immer irgendwo mal das schwächste Glied in einer
Sicherheitskette sein könnten.
Ob das sein kann, übersieht man als Entwickler häufig nicht, denn Homo
sapiens sapiens neigt dazu, alles mögliche zu Zwecken zu gebrauchen, für
die es nicht vorgesehen war und vor Gericht und auf Hoher See ist man
bekanntlich in der Hand eines Herren, den es garnicht gibt...
