Golem: C ist eine feindselige Sprache

Status
Für weitere Antworten geschlossen.

schorsch_76

FreeBSD Fanboy
Hallo zusammen,

letztens hab ich auf Golem folgende Artikel gelesen:
https://www.golem.de/news/rust-c-ist-eine-feindselige-sprache-1707-129196.html
https://www.golem.de/news/security-linux-desktops-brauchen-bessere-verteidigung-1708-129244.html

Der Tenor ist, das eh alles viel zu alt und unsicher ist. Von C zu X11. Ok, als X11 entworfen wurde waren noch andere Bedrohungslagen da.

Wo ich überhaupt nicht zustimme, das C und die verwandten Sprachen feindselig sind.

Habt ihr das auch gelesen? Wie ist eure Meinung dazu?

Gruß
Georg
 
Wo ich überhaupt nicht zustimme, das C und die verwandten Sprachen feindselig sind.
Finds immerwieder lustig, wie eigene Unfähigkeiten mit Schuldzuweisungen bewältigt werden, weiterhin empfinde ich die Überschrift als reinen Clickbait.

C macht genau was es soll mit allen Freiheiten die man sich vorstellen kann mit annähernd maximaler Performance und Simplicity ( <- Einfachheit klingt doof ). Jede Sprache die einen Vorteil bietet, birgt an irgendeiner anderen Position einen Nachteil. C ist für mich die best ausbalancierte Sprache (Subjektive Aussage, da ich C nur lese und nicht schreibe).

X11 ist für mich ein notwendiges Übel
 
Ich mag diese "Alles ist alt, doof und sollte neu gemacht werden"-Denkweise nicht. Es mag selten durchaus sinnvoll sein alles zu verwerfen und neu zu beginnen, oft ist es das aber einfach kontraproduktiv. Denn viele Dinge, die einen auf den ersten Blick schlecht gelöst sind, sind das Ergebnis begründeter Designentscheidungen oder haben sich über längere Zeiträume so ergeben und überlebt, weil sie sinnvoll sind. Außerdem stecken in Code und Architektur oftmals Unmengen Know-How, die so nirgends sonst dokumentiert sind und sich auch nicht ohne weiteres erkennen lassen. Bei einem Neubeginn verliert man all dieses, erkennt dann nach und nach die Defizite seines im Vorfeld auf dem Reißbrett entworfenen Konzepts, beginnt zwangsläufig es zu verändern und Kompromisse einzugehen und landet letztendlich wieder dort, wo man einst gestartet ist. Gewonnen hat man unter dem Strich nichts.

Das ist übrigens eine Lektion, die gerade die Linux-Desktop-Entwickler inzwischen hätten lernen können. Wie oft sind KDE, Gnome und die diversen anderen Desktops schon von vorne begonnen und haben versucht das Rad neu zu erfinden? Oder Wayland. Wayland hat ein gutes Design, ja. Und es funktioniert auf meinem Laptop unter Gnome 3 wunderbar. Aber eben nur, weil Wayland für hochintegrierte Desktopumgebungen entwickelt wurde, wo es von Vorteil ist, wenn Display Server, Window Manager und Message Broker eng zusammenhängen. Aber für die große Masse schlankerer Desktops, wo man eben keine enge Integration der 3 Komponenten braucht und aus Gründen der Flexibilität auch nicht möchte, ist es sehr suboptimal.

Das soll nun nicht heißen, dass man nichts verändern soll. Ganz im Gegenteil. Man sollte aber nicht auf "Alles ist alt, doof und sollte neu gemacht werden" zurückfallen, sondern iterativ die vorhandene Lösung verbessern. Bezogen auf Golems Artikel beispielsweise die Thumpnail-Erstellung in Gnome 3 evaluieren, die vorhandene Lösung und ihre Designentscheidungen verstehen. Ihre Schwachpunkte analysieren, für diese Lösungen finden und implementieren.

Joel Spolsky schriebt vor inzwischen 17 Jahren darüber und der Text ist heute genauso aktuell wie damals: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
 
Ich programmiere jetzt C/C++ seit 25 Jahren. Ja, ich hab auch viel Code produziert der Anfangs nicht sehr gut war. Wenn ich heute Code warten muss den ich vor ca 15 Jahren geschrieben habe, merke ich ganz klar den Unterschied. Erfahrung kommt auch von machen. Man muss sich aber auch permanent weiterbilden. Der Blick in mein Bücherregal spricht Bände ;)
 
Nun, auch die größten Sicherheitsexperten bauen aus versehen Sicherheitslücken in ihren Code ein. Diese Denke "man kann mit C sicher programmieren, also muss der Programmierer eben besser werden" halte ich für genauso unsinnig. Genauso kann man auch argumentieren, dass auch einfach der Programmierer mal sich eine neue Sprache aneignet, mit der er sich weniger um die "Low Level" Sicherheit seines Programms sorgen machen muss, weil einem das der Compiler eben direkt um die Ohren haut. Die Überlegungen bestimmte Compile-Time Prüfungen in eine Sprache einzubauen sind doch nicht neu. Ada hat das schon 1980 gemacht. Rust packt dies nur in ein etwas moderneres Gewand und benötigt dafür auch keine Managed-Runtime wie Java oder C#.

Wir leben nicht mehr in "einfachen" Zeiten. Die Welt besteht eben nicht mehr nur aus unverschlüsselter Kommunikation in reinen Text-Dateien. Wir brauchen jetzt auch keine Diskussion darüber, dass das auch heute noch alles ausreicht. Komplexe Datenformate sind da, verschlüsselte Kommunikation mit unterschiedlichen Protokollen und Verschlüsselungsalgorithmen sind da und ein Desktop besteht aus mehr als nur eine weiße Fläche auf der einfarbige Fenster dargestellt werden.

Jedes mal wenn man ein Sicherheitsupdate einspielt, dann ist das mit sehr hoher Wahrscheinlichkeit ein Buffer Overflow irgendwo. Ebenso mit sehr hoher Wahrscheinlichkeit wäre der gleiche Code in einer sicheren Programmiersprache gar nicht kompilierbar gewesen. Und gerade kleine Programme wie eben die Parser für verschiedene Dateiformate mal in Rust und Co. neu zu schreiben ist keine Mammutaufgabe. Klar nicht von heute auf morgen, aber man kann damit ja einfach stetig weiter machen.

Man kann es ja auch wunderbar hier sehen: https://www.bsdforen.de/threads/def-con-25-free-net-openbsd-sind-auch-keine-lösung.33671/
 
Diese Denke "man kann mit C sicher programmieren, also muss der Programmierer eben besser werden" halte ich für genauso unsinnig.
Wer unfähig ist, einen gewissen Qualitätsstandart in seine Programme zu integrieren, baut auch mit "sicheren" Sprachen keine "sicheren" Programme. Ich habe recht wenig Ahnung vom Schreiben von Lowlevel Code, darum die Frage: Verhindert Rust wirklich die Problematik von Buffer-Overflows vollständig, oder wird das Problem nur seltener und wird von den Programmierern dann nichtmehr beachtet?
 
Wer unfähig ist, einen gewissen Qualitätsstandart in seine Programme zu integrieren, baut auch mit "sicheren" Sprachen keine "sicheren" Programme. Ich habe recht wenig Ahnung vom Schreiben von Lowlevel Code, darum die Frage: Verhindert Rust wirklich die Problematik von Buffer-Overflows vollständig, oder wird das Problem nur seltener und wird von den Programmierern dann nichtmehr beachtet?

Rust erlaubt keinen "unsafe" Code, solange man es nicht explizit anfordert. Neben dem, dass der Compiler möglichst früh versucht den Code gar nicht erst zu kompilieren, sind Out-Of-Bounds Zugriffe generell nicht möglich. Das fliegt einem dann zur Laufzeit um die Ohren, statt dass es einfach getan wird.

Unsicherer Code hat auch nichts mit Qualitätsstandards zu tun. Auch OpenBSD hat Lücken und Sicherheitsprobleme. Bereits gehabt und wird es noch haben. Trotzdem würdest du ihnen keinen fehlenden Qualitätsstandard vorwerfen. Menschen machen Fehler... Fehler die ein Compiler durchaus finden und eine Sprache auch verhindern kann. Man darf halt nur nicht Stur einfach behaupten man sei perfekt und brauche deswegen solche Sachen nicht.
 
Also einfach mal ein sehr simples Beispiel:

Folgender C Code kompiliert wunderbar und wird ohne Mucken ausgeführt:
Code:
int main() {
  int a[3] = {1,2,3};
  int i = a[4];                                                                            
}

folgender Rust Code kompiliert zwar, aber mit der Warnung, dass einem das zur Laufzeit um die Ohren fliegt:
Code:
fn main () {                                                                              
  let k = [1, 2, 3];
  k[4];
}

warning: this expression will panic at run-time
--> main.rs:3:3
|
3 | k[4];
| ^^^^ index out of bounds: the len is 3 but the index is 4

Neben diesen simplen Sachen hat Rust auch noch komplexe Analysen über Funktionen hinweg, ob man die Rückgabeparameter korrekt verarbeitet, Switch-Statements vollständig sind usw. usw.

edit:
Nebenbei versucht der Rust-Compiler auch effizienten Code zu generieren, indem man z.B. Bound-Checks aus dem Code entfernt, der garantiert nicht Out-of-Bounds gehen kann.
 
Zuletzt bearbeitet:
Menschen machen Fehler... Fehler die ein Compiler durchaus finden und eine Sprache auch verhindern kann. Man darf halt nur nicht Stur einfach behaupten man sei perfekt und brauche deswegen solche Sachen nicht.
Da muss ich dir absolut zustimmen!

Ich denke ich werde mir einfach mal Rust installieren und ein Buch dazu kaufen :)
 
Auch clang warnt dich...

% clang teset.c
teset.c:3:11: warning: array index 4 is past the end of the array (which contains 3 elements) [-Warray-bounds]
int i = a[4];
^ ~
teset.c:2:3: note: array 'a' declared here
int a[3] = {1,2,3};
^
1 warning generated.
 
Auch clang warnt dich...

Und läuft das Programm danach trotzdem normal durch? ;) Also GCC hat mich da z.B. nicht gewarnt. Aber es geht weniger um die Warnung, sondern darum, dass der Code hinterher einfach nicht "funktioniert" und sich das Programm bitte direkt verabschiedet. Die Clang Warnung verschwindet, wenn der Code etwas komplexer wird und die Zugriffsvariable berechnet wird
 
Was gibts da gross zu laufen, das dürfte eh weg optimiert werden =)

Aber warum kompiliert es rust überhaupt -- warum brichts nicht ab mit Kompilierfehler?
 
Was gibts da gross zu laufen, das dürfte eh weg optimiert werden =)
Aber warum kompiliert es rust überhaupt -- warum brichts nicht ab mit Kompilierfehler?

Es geht hier um ein simples Bespiel... da braucht man jetzt auch nicht groß drum rum reden, dass da irgendwas wegoptimiert wird, das kein echter Code ist oder sonst was. Es dient schlicht und ergreifend nur dazu, zu zeigen, dass C und dessen Compiler kaputte Programme schlicht erlaubt. Und ein Out-Of-Bounds Zugriff ist in C nunmal nicht verboten, darum funktionieren die ganzen Buffer-Overflows auch.

Und warum Rust das nur vorwarnt und nicht gleich abbricht, das liegt daran, dass es eben ein "simpler" Fehler ist. Bei komplexen Algorithmen ist es schwer im Vorfeld zu beweisen, dass ein Zugriff Out-Of-Bounds wird. Sollte sich das Gegenteil nicht beweisen lassen (also, dass es garantiert immer In-Bound ist), kleistert der Rust Compiler den Zugriff mit Bound-Checks zu.
 
Ich denke ich werde mir einfach mal Rust installieren und ein Buch dazu kaufen :)
Ich weiss nicht ob es ein Buch wirklich bringt. Die Doku zwar recht gut aber die Einstiegshürde doch nicht ohne da sich Rust von den vertrauten Sprachen um einiges unterscheidet und eine etwas andere Denke erfordert (Angeblich sollen sich Leute mit ML/Haskel Erfahrung etwas leichter tun). Installiere dir gleich rustup das dann automatisch alles notwendige installiert.

Have fun!
Peter
 
Habt ihr das auch gelesen? Wie ist eure Meinung dazu?

Sprachen wie Go und Rust, die unter der Prämisse entwickelt werden, dass manche Leute zu blöd für sicheres C/C++ sind, lösen das falsche Problem. Ein Interesse meinerseits, irgendwas in Go oder Rust zu entwickeln, nur damit ich beim Tippen weniger denken muss, besteht nicht.
 
dass manche Leute zu blöd für sicheres C/C++ sind

Ich würde eher sagen: Alle sind zu blöd für sicheres C. Ausnahmslos alle. Der eine mag weniger Fehler machen als der Andere, aber Fehler machen sie alle.

edit: Wer übrigens meint, dass Bound-Checking das einzige Sicherheitsproblem in C ist, der sollte vielleicht noch mal genau nachlesen was in C alles so ungeprüft durchgeht.
 
Zuletzt bearbeitet:
Wer übrigens meint, dass Bound-Checking das einzige Sicherheitsproblem in C ist

Das Sicherheitsproblem in Code wie ...

Code:
void geh_kaputt(void) {
    int foo[3] = { 1, 2, 3 };
    int bar = foo[4];
}

... sitzt vor dem Rechner und macht vor dem Tippen sein Köpflein aus.
 
Das Sicherheitsproblem in Code wie ...
... sitzt vor dem Rechner und macht vor dem Tippen sein Köpflein aus.

Dir ist aber schon der Unterschied zwischen einem simplen Beispielcode, der Grundprobleme der Sprache aufzeigen soll, und den ganzen mehr oder weniger komplexen Buffer-Overflows in realen Code bekannt, oder? ;) Alleine schon wie viele verschiedene Varianten es in C gibt einen String zu kopieren und wie viele davon kaputt sind und trotzdem allgemein als "sicher" gelten...
 
Alleine schon wie viele verschiedene Varianten es in C gibt einen String zu kopieren

Gar keine, denn in C gibt es keine Strings. Ein Pointer auf ein char ist kein String. Ein char[] ist kein String. Ein string ist ein Syntaxfehler. :rolleyes:

Aber gut, lassen wir das mal außen vor und tun so, als gäbe es zwischen einem Zeiger und einer Zeichenkette keinen irgendwie interessanten Unterschied, um die Dramaturgie noch ein wenig aufrecht zu erhalten:

und wie viele davon kaputt sind und trotzdem allgemein als "sicher" gelten...

Mir ist exakt edit: eine einzige standardkonforme Implementierung von strcpy bekannt, die allgemein als "sicher" gälte. Weißt du da mehr als ich?
 
Gar keine, denn in C gibt es keine Strings. Ein Pointer auf ein char ist kein String. Ein char[] ist kein String. Ein string ist ein Syntaxfehler. :rolleyes:

Jojo, Korinthenkackerei, nech? ;) Die ganzen C Funktionen haben "str" für "String" im Namen, weil... es ja keine Strings sind ;)

Mir ist exakt keine einzige standardkonforme Implementierung von strcpy bekannt, die allgemein als "sicher" gälte. Weißt du da mehr als ich?

Na dann suche mal nach strncpy und schaue dir mal an was allgemein dazu gesagt wird ;) Non-Standard gibt's einige, ja. Eine ganze Tonne an weiterem Problemen passieren jedem C Programmierer. Wie gesagt: Wenn sicheres C so einfach ist, warum wird dann so gut wie jeden Tag ein Buffer-Overflow irgendwo gefunden? Alle Programmierer blöd? Nur du der einzig wahre C-Programmierer? ;)

Sorry, aber die Praxis zeigt, dass niemand, in einem nicht-trivialen Projekt, dauerhaft in der Lage ist mit C sicher zu programmieren.
 
Na dann suche mal nach strncpy und schaue dir mal an was allgemein dazu gesagt wird ;)

Du hast meinen Edit verpasst. Was aber allgemein zu strncpy gesagt wird: Scheißidee, nicht machen, ist unsicher.
Es gibt allerdings inzwischen strcpy_s, das einigermaßen als sicher durchgehen könnte.

Wenn sicheres C so einfach ist, warum wird dann so gut wie jeden Tag ein Buffer-Overflow irgendwo gefunden?

Weil nicht alles in C geschrieben ist. :D
Ernsthaft: Du verwechselst hier Korrelation und Kausalität. Firefox ist inzwischen teilweise in Rust geschrieben und trotzdem nicht gerade für seine Stabilität bekannt.

Alle Programmierer blöd?

Es gibt zu viele Programmierer, die stattdessen vielleicht besser putzen oder kochen sollten. Mich schließe ich da zweifellos nicht aus, übrigens - aber ich habe es auch selten mit wirklich komplexer Software zu tun. (Die würde ich dann auch lieber in einer anderen Sprache schreiben wollen.)
 
Juhu, Sprachdiskussionen! ;)

Was mir auffällt, ist dass manchmal unsinnig diskutiert wird. Das mit den Warnungen von clang und Rust ist ein Beispiel dazu.

Zunächst einmal sehen viele C und C++ Programmierer die Sprache weniger kritisch als die Schreihälse, die meinen Bugtracker von riesigen Production-Systemen mit "Bitte in Rust neu schreiben" voll spammen zu müssen. Das sind die Selben, die meinen alt bedeutet schlecht, aber auch Leute, die selber Rust Faboys sind ohne Rust oder C zu programmieren. Damit kämpft auch das Rust-Projekt ziemlich, das ja durchaus viele Leute aus der C++-Welt und vielen funktionalen Programmiersprachen als Entwickler hat, die sich teils auch schon eine Weile damit beschäftigt haben C und C++ sicherer zu bekommen und zwar auf unterschiedlichste Arten (also statische Code-Analyse genauso wie Erweiterungen). Derzeit passiert ja im LLVM SAFECode auch einiges. Das ist eben ein anderer Ansatz, die Probleme, die es so gibt zu "beheben", wenn man das so nennen kann.

Ich würde deshalb vorschlagen irgendwelche Trolle jetzt mal außen vor zu lassen. Dass es die gibt bestreitet auch keiner, und dass das was die sagen zu größten Teilen Unfug ist auch nicht.

Stattdessen würde ich Rust eher als die aktuelle Inkarnation von "man kann die Probleme die es gibt mit oder nur mit einem neuen Sprachdesign beseitigen". Da gehen ja die Meinungen auseinander und es gibt durchaus einige an Entwickler, die selbst Rust genau so sehen, nämlich vor allem als Experiment, das natürlich auch scheitern kann, zum Beispiel weil es zu schwer zu verwenden ist oder auch andere Gründe.

Solche Probleme gibt's öfters, dass irgendwelche lauten Teile er Community das sind was Leute mitbekommen und nicht die Arbeit und Forschung, die man potentiell wieder verwerten kann (Rust baut ja auch auf LLVM auf).

Dass man mit C schreckliche Sachen machen kann, die statt nur einen Panic häufig auch zu Remote Code Execution führen ist auch klar. Es gibt eben keine Type Safety. Das ist mal neutral, und heißt jetzt nicht direkt, dass C schlecht ist, sondern würde ich eher als Eigenschaft der Sprache ansehen, als Entscheidung bezüglich des Designs, die wie es aussieht zum Teil zumindest (gerade da wo es Performance und mal flapsig gesagt "Trickserei" angeht) zum Teil auch zum Erfolg der Sprache beigetragen hat.

Rust versucht nun das Security-Problem weg zu bekommen, vor allem ohne die Nachteile in der Performance zu haben. Der Preis ist dann eine erhöhte Komplexität, wo es dann viele Meinungen gibt, ob diese im Verhältnis steht, ob das nur scheinbar komplexer ist, weil es dazu zwingt korrekt zu programmieren, oder ob das unverhältnismäßig ist und wenn ja, ob und wie man das verbessern kann.

Anders als ähnliche Projekte hat es den Vorteil nicht nur in irgendwelchen Hinterzimmern einer Uni oder vor allem durch ein in Verhältnis zu Mozilla kleines, unbekanntes Unternehmen gestützt zu werden. Es gibt echte Projekte, die in Rust implementiert wurden, was dazu führt, dass viele Leute ein Auge drauf werfen.

Und wenn man mal davon ausgeht, dass Rust ein erfolgreiches Projekt wird in dem Sinn, dass in 10 - 20 Jahren es immer noch eine große Sprache ist, dann heißt das noch immer nicht zwangsweise, dass C Geschichte ist. Dafür kann es viele Gründe geben. Neben so Sachen, wie dass es genug Code gibt wird C sehr wahrscheinlich nicht an allen Bereichen verdrängt werden. Aber nehmen wir mal an C code könnte und würde schnell und Effektiv in das von vielen beherrschte Rust übersetzt werden, weil sich die Meinung durchsetzen würde, dass es viel besser ist die Sicherheit zu haben. Selbst dann würde es wohl Leute geben, die einfach schneller und unsicherer programmieren wollen. Kann gut sein, dass C dann hipp ist, weil sich ein Startup sagt, dass man damit schneller einen Prototypen hat der bestimmte Voraussetzung erfüllt.

Aber wenn ich drauf tippen müsste, würde ich sagen, dass C und C++ (vielleicht letzteres noch eher) in 20 Jahren, selbst wenn Rust stark weiter wächst wohl keinesfalls ein Nischendasein fristen wird, sondern Rust (oder sonst eine Alternative die aus was für einen Grund auch immer groß wächst) eher so im Verhältnis stehen werden wie diverse Skriptsprachen (Python. Ruby, Node.js, PHP, Perl und so weiter).

Hype ist immer so eine zweischneidige Sache und auch wenn ich den Beiträgen hier zustimme, dass der Unsinn der da geredet wird teilweise echt nervig und bestenfalls Clickbait ist braucht gerade ein neues Projekt Hype. Auch C und C++ und Java haben anfangs Hype gebraucht. Man kann es auch Marketing nennen. Das ist zwar irgendwo traurig, dass sich nicht einfach das Bessere durchsetzt, zumindest in den Gebieten wo der Vorteil objektiv messbar ist, aber so funktioniert die Welt leider nicht.

Ich glaube ehrlich gesagt nicht, dass sich Rust groß durchsetzen wird, weil das Reinkommen in die Sprache doch einige Zeit dauert, aber der Trend der letzten Jahrzehnte finde ich gezeigt hat, dass sich sprachen durchsetzen, die man sehr schnell begreift. Trotzdem hoffe ich, dass sich viele Leute, die Sprache dahinter ansehen, allein schon um was zu lernen und vielleicht auch zu kopieren, aber vor allem, damit es dann nicht vor Behauptungen wuchert, warum Rust gescheitert sei, die nichts mit der Realität zu tun haben und von lediglich von Leuten kommen, die sich nie ernsthaft mit der Sprache auseinandergesetzt haben.

Und sterben wird Rust wohl auch nicht. Zumindest nicht mehr als so "tote" Sprachen, wie Perl (oder vielleicht diverse MAL-Versionen). Dazu gibt es jetzt schon zu viel Code und ich rechne nicht damit, dass sich da Rust bereits in einer Abklingphase befindet.

Ganz zum Schluss nochmal zu C. Ich glaube durch die ganzen Sachen, die im LLVM-Bereich derzeit stattfinden wird C Code deutlich an Sicherheit gewinnen, wenn man Qualität nicht komplett ignoriert. Es kommen ständig Compile-Switches, Warnings, etc. dazu, es gibt Valgrind, wo sich auch noch was tut, Projekte sprießen. Die Leute schwören immer mehr auf Tests, Tooling, Fuzzers, es setzen sich immer wieder Sachen durch wo man sich fragt, wie es sein kann, warum das nicht schon vor 30 Jahren hatte als C-Entwickler. Generell steigt gefühlt der Mindeststandard den man an C-Code bzw. den Projekten drum rum hat gerade gewaltig. Ich denke das wird sich auswirken, auch wenn es sicherlich noch zu früh ist, dass man das auch nur versuchen könnte zu messen, was ja ohnehin schwierig ist.

Gerade wenn man dann noch so Schutzfunktionen von außerhalb (OS/Kernel) dazu nimmt denke ich, dass die Schwächen, die C da haben mag immer mehr in den Hintergrund treten und tatsächlich nutzbare Sicherheitslücken immer mehr in Kategorien, die wirklich auf Anwendungsebene stattfinden sein werden oder einfach auch mieser Security beruhen. Zumindest sieht es für mich gerade so aus, weil eben das Ecosystem sich da gerade ziemlich entwickelt. Dass so viele Sprachen sich als Konkurrenz platzieren wollen spielt da sicherlich ebenfalls mit rein.
 
Du hast meinen Edit verpasst. Was aber allgemein zu strncpy gesagt wird: Scheißidee, nicht machen, ist unsicher.
Es gibt allerdings inzwischen strcpy_s, das einigermaßen als sicher durchgehen könnte.

Der allgemein Grundton im Internet ist "nimm strncpy, statt strcpy weil sicher".... das strncpy auch unsicher ist, ist die nächste Stufe. Es zeigt doch schon, dass es gut und gerne 4-5 unterschiedliche String-Copy Funktionen gibt, weil alle davor unsicher waren. Das sagt doch schon eindeutig: Die Sprache ist unsicher. Man hat nach 2-3 Iterationen immer noch nicht geschafft was allgemein sicheres auf die Beine zu stellen.

Weil nicht alles in C geschrieben ist. :D

Betrifft nur leider meist C/C++ Programme ;) Gerade im Bereich der Systemsoftware.

Es gibt zu viele Programmierer, die stattdessen vielleicht besser putzen oder kochen sollten. Mich schließe ich da zweifellos nicht aus, übrigens - aber ich habe es auch selten mit wirklich komplexer Software zu tun. (Die würde ich dann auch lieber in einer anderen Sprache schreiben wollen.)

Wie gesagt: Auch die OpenBSD Leute machen Fehler und haben Sicherheitslücken produziert, oder Code importiert, den sie für sicher hielten, oder selbst die Lücken übersehen. Willst du denen jetzt auch allgemeine Blödheit unterstellen? FreeBSD ist noch schlechter in Punkto Sicherheit, noch viel schlechter ist NetBSD. Alle blöd? Jede SSL-Implementierung die ich je gesehen habe, hatte schon kritische Lücken: Auch alle blöd? Jedes OS, jeder (nicht-triviale) Kernel, jede Bibliothek die Fremddaten verarbeitet hatte auch schon kritische Lücken... auch allesamt blöd?

Ich bleibe dabei: Nicht der Programmierer ist das Problem, sondern die Sprache.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben