while(true) {write();} - Der Programmierer-Spamthread #1

[Jesus_666]

Interessant wird's dann aber, wenn man in weiser Voraussicht den String auf 11 Stellen dimensioniert hat, weil der Code ja eh nur auf 32bittigen Plattformen zum Einsatz kommt. Und dann kommt plötzlich eine source-kompatible 64bittige Version der Plattform raus oder jemand portiert den Code.

Das ist (sicherheitstechnisch) das Blöde bei C: Die einzige Sicherheit, die du hast, ist die, die du einbaust. Das ist ein Grund, lieber defensiv zu programmieren als die letzten 0,1% Leistung rauszukitzeln.

[Kyuu]

Wie gesagt, am Ende kommt es immer auf die Anforderungen der Software an, die man programmiert. Es ist genauso falsch an den falschen Stellen zu optimieren, wie auch zu optimistisch, oder zu pessimistisch zu programmieren. Hundertprozentige Sicherheit gibt es sowieso nie.

[Jesus_666]

Doch, gibt es. Sie nennt sich "EAL7-Zertifizierung". Gut, dafür mußt du sämtliche Software und IIRC auch Teile der Hardware formell verifizieren und testen. Aber dann kannst du dir absolut sicher sein, daß jegliche Fehler Hardwaredefekte und nicht Implementierungsfehler sind.

Okay, als Normalsterblicher wirst du nicht mit EAL7-Kram arbeiten. Aber du solltest schon wissen, wann du wo welche Risiken eingehen kannst. Ich würde mir wohl nicht die Mühe machen, bei jedem Befüllen eines Strings abzuwägen, ob es theoretisch möglich ist, den String mit zu vielen Daten zu befüllen – nicht, wenn es Funktionen gibt, die diese Mühe überflüssig machen.
Man kann's natürlich übertreiben, aber solange der Performanceverlust durch Verwendung von sprintf()-Alternativen nicht zu groß ist, würde ich sie grundsätzlich verwenden. Und das dürfte außerhalb von synthetischen Benchmarks immer der Fall sein.

[Kyuu]

Die CC ist auch keine Silberkugel und unangreifbar. Du kannst dich an absolute Sicherheit annähern, sie aber nie erreichen. Mit jedem erreichten EAL kannst du deine Software als "sicherer", oder als "zur Zeit sicher gegen dies und das" bezeichnen, aber nie als "sicher". Die Hardware spielt IMO auch eine entscheidende Rolle bei der Frage nach der Sicherheit eines Systems. Übrigens habe ich mal irgendwo gelesen, dass EAL7 für Low Level-Implementation nur semi-formelle Spezifikation fordert, so dass es keinen mathematischen Beweis gibt, dass die Low Level-Spezifikation der Implementation entspricht. Dass EAL7 nur für sehr spezielle Systeme mit sehr speziellen Sicherheitsfunktionen überhaupt praktikabel ist, da der Aufwand und die daraus resultierenden Kosten enorm sind, ist bekannt. Naja, ich bleibe dabei, dass absolute Sicherheit - und ich meine absolut - nicht möglich ist. Ich meine mich zudem zu erinnern gelesen zu haben, dass selbst bei der medizinischen Ausrüstung (und anderer Technik mit ähnlichen Sicherheitsstandards) nicht mit absoluter Fehlerfreiheit gerechnet wird und Todesfälle verursacht durch Fehler in diesen Geräten sowohl in Kauf genommen werden (wenn auch minimal), als auch schon vorgekommen sind.

Was sprintf angeht, überrascht es mich ein wenig, dass du nur die Performance, oder gerade die Performance in Betracht ziehst, da diese kaum bei der sprintf-Familie relevant sein kann. Ich kann mir jedenfalls nicht vorstellen aus welchem sinnvollen Grund sprintf und co. etwas in performancekritischen Bereichen zu suchen hätten. Vielmehr würde ich speziell bei snprintf/asprintf argumentieren, dass ihre Verwendung zusätzlichen Aufwand und damit Komplexität erzeugt in dem Fall, wenn man sich nicht auf einen Compiler beschränken möchte. MSVC ist zum Beispiel nicht C99-konform und hat keine snprintf-Implementation. Nun bietet MSVC zwar sein eigenes snprintf, nämlich _snprintf (was hätte man anderes erwartet), dieses ist aber semantisch von C99-snprintf verschieden -> Aufwand ist notwendig um hier Plattformunabhängigkeit zu erreichen. Man könnte argumentieren, dass dieser Aufwand relativ gering ist, es bleibt trotzdem Aufwand, der betrieben werden muss. IIRC ist das Trimmen von _snprintf auf C99-snprintf aus dem Grund der semantischen Unterschiede sogar nicht so effizient wie man es erwarten würde und würde im Worst Case viele Aufrufe erfordern, was vielleicht nicht wünschenswert ist. Wenn die Software klein genug ist und das Risiko, dass sprintf einen Überlauf verursacht gering ist und nur in Grenzfällen eintreten kann, wie etwa wie in deinem Beispiel mit der Portierung auf 64 Bit, kann man dieses durchaus in Kauf nehmen. Man kann auch mit größerem Buffer arbeiten, was absolut nicht unüblich ist. Ein Wechsel von sprintf zu snprintf/asprintf/_snprintf/etc. ist zu jedem Zeitpunkt immernoch möglich. Ich habe gelernt, dass vorzeitige Paranoia genauso schädlich ist, wie vorzeitige Optimierung und ähnliches Übel und Schritte in diese Richtungen erst gemacht werden sollten, wenn ein Anlass besteht. Es gibt natürlich Ausnahmen.

Im Übrigen bin ich alles andere als der Meinung, Performance geht über Stabilität und Sicherheit, falls (aus welchem Grund auch immer) bei irgendwem dieser Eindruck entstanden sein sollte. Um ehrlich zu sein, habe ich doch bis jetzt immer wieder auf eine oder andere Art betont, dass immer abgewogen werden sollte, je nach Situation und Anforderungen. Ich bin aber definitiv der Meinung, dass nicht vorschnell Dinge als impraktikabel erklärt werden sollten, allein aufgrund dessen, dass sie unter bestimmten Voraussetzungen unsicher sind. "sicher" erweckt meiner Meinung nach sowieso ein falsches Gefühl der Sicherheit, denn um überhaupt nur entfernt von Sicherheit zu reden ist weit mehr nötig, als nur calloc oder snprintf und co. zu verwenden. Davon abgesehen, dass calloc kaum als "sichere Variante von malloc" gedacht war, sondern vermutlich nur als "die bequeme Variante", im Fall, dass der erhaltene Speicher genullt sein muss. Im Fall von Gleitpunktzahlen und Zeigern ist calloc schonmal keine Silberkugel, denn alle Bits auf Null gesetzt, bedeutet nicht eine Gleitpunktzahl gleich Null, oder einen Nullzeiger, man hat also das gleiche Problem wie in deinem Beispiel mit sprintf und der Portierung auf 64 Bit.

[Jesus_666]

C99 ist immer noch nicht flächendeckend implementiert? Oy vey; ich weiß schon, warum ich mich von lowlevel-Programmierung fern halte.