Das prüfen auf fehlerhafte argumente in der glibc ist eigentlich fast unnötig Klar es bringt ein wenig mehr Performance und vor allem öffnet ein Tür für absichtlich geschriebenen fehlerhaften Code. Wenn eine Überprüfung nicht statt findet kann durchaus ein Schadprogramme daraus profitieren.
Wenn du so ängstlich vor schadprogrammen bist, dann starte doch alle deine programme in valgrind. Nur leider macht das die meisten programme mehr oder weniger unbedienbar. Dafür hast du allerdings etwas mehr sicherheit. Oder soll jetzt glibc sämtliche arbeitsspeicher zugriffe checken, ob diese erlaubt sind? Wenn du erwartest, dass memcpy seine argumente überprüft, dann musst du auch erwarten, dass ALLE speicherzugriffe überprüft werden, weil nur so sichergestellt werden kann, dass alles ok ist. Dann wären wir aber wieder dort, dass du valgrind nehmen kannst, weil dort genau das gemacht wird
So ängstlich bin ich nicht. Meine Ausführung gilt eher Leute die unbedarft alles ausführen was Ihnen unter die Finger kommt. Wenn Windows so erfolgreich gehackt wird liegt es u. a. an ein zu Laschen Sicherheitskonzept. Für eigene Werke wird selbstverständlich Valgrind bemüht, ein kleinen Fehler kann sich immer bemerkbar machen. Ich habe ein Status Monitor für Epson Drucker programmiert, irgendwann habe ich die Benachrichtigung erhalten, dass der Anwender sich auf unerlaubte Weise Rechte verschaffen kann. Die Ursache war eigentlich nicht meinen Code aber ein fehlerhafte Bibliothek. Das Ergebnis ist, dass ich, um den Fehler zu beseitigen, das Environment untersuche und von unnötige Variable befreit und die Variablen die notwendig sind auf deren Inhalt untersuche und gegebenenfalls das Programm vorzeitig beendet. Wäre besagte Lib Fehlerfrei gewesen, hätte ich den Ärger nicht gehabt.
Das prüfen auf fehlerhafte argumente in der glibc ist eigentlich fast unnötig
Klar es bringt ein wenig mehr Performance und vor allem öffnet ein Tür für absichtlich geschriebenen fehlerhaften Code.
Wenn eine Überprüfung nicht statt findet kann durchaus ein Schadprogramme daraus profitieren.
Wenn du so ängstlich vor schadprogrammen bist, dann starte doch alle deine programme in valgrind. Nur leider macht das die meisten programme mehr oder weniger unbedienbar. Dafür hast du allerdings etwas mehr sicherheit.
Oder soll jetzt glibc sämtliche arbeitsspeicher zugriffe checken, ob diese erlaubt sind? Wenn du erwartest, dass memcpy seine argumente überprüft, dann musst du auch erwarten, dass ALLE speicherzugriffe überprüft werden, weil nur so sichergestellt werden kann, dass alles ok ist. Dann wären wir aber wieder dort, dass du valgrind nehmen kannst, weil dort genau das gemacht wird
So ängstlich bin ich nicht. Meine Ausführung gilt eher Leute die unbedarft alles ausführen was Ihnen unter die Finger kommt.
Wenn Windows so erfolgreich gehackt wird liegt es u. a. an ein zu Laschen Sicherheitskonzept.
Für eigene Werke wird selbstverständlich Valgrind bemüht, ein kleinen Fehler kann sich immer bemerkbar machen. Ich habe ein Status Monitor für Epson Drucker programmiert, irgendwann habe ich die Benachrichtigung erhalten, dass der Anwender sich auf unerlaubte Weise Rechte verschaffen kann. Die Ursache war eigentlich nicht meinen Code aber ein fehlerhafte Bibliothek. Das Ergebnis ist, dass ich, um den Fehler zu beseitigen, das Environment untersuche und von unnötige Variable befreit und die Variablen die notwendig sind auf deren Inhalt untersuche und gegebenenfalls das Programm vorzeitig beendet. Wäre besagte Lib Fehlerfrei gewesen, hätte ich den Ärger nicht gehabt.