Von C zu Rust wechseln?
-
müssen schrieb:
Nathan schrieb:
Beide Projekte müssten doch von Leuten programmiert sein, die nicht "doof" sind oder "keine Ahnung von C++ haben".
Nein. Die internal compiler errors sind idR nur bei sehr obskuren, neuen C++ Features. Die Implementierung ist dann natürlich nicht ausgereift, da passiert sowas.
Genau das meine ich doch! Die Entwicklung ist nicht ausgereift => Segfault. Wieso Segfault? Weil irgendwo Speicherfehler passiert sind. (Oder durch null dividiert, aber das ist recht selten.) Wie fixen? Stundenlang vor dem Debugger sitzen und alle mögliche Eingaben ausprobieren. Dann kommen so Weisheiten zustande wie "80% der Zeit sitzt man vor dem Debugger".
Laut meiner Erfahrung ist das Debuggen nicht so lang, idR finde ich die Ursache für meine (seltenen) Segfaults recht schnell.
In Rust würde das nicht passieren, weil der Compiler das garantiert.
Ja. In C++ garantiert er das leider nicht. Ich wollte lediglich gegen die Haltung von einigen, dass C++ nur unsicheren Code hat, argumentieren.
Nathan schrieb:
Rust erlaubt auch "falsches" Memory Handling in unsafe Blöcken. Und das Problem ist ja, dass es sich die "doofen" Leute zutrauen, mit rohen Pointern/in unsafe Blöcken zu arbeiten und das deshalb auch tun werden. "doofe" Programmierer werden immer Speicherfehler produzieren, egal welche Sprache.
Ich habe da andere Erfahrung gemacht. unsafe ist unelegant und kein Programmierer will uneleganten Code schreiben. Ausserdem reduziert sich der Code, in dem man Speicherfehler suchen muss auf unsafe-Blöcke.
Wobei ich das nicht mit 100% Sicherheit sagen kann, da vielleicht noch gar keine doofen Programmierer nach Rust gekommen sind.Dasselbe gilt auch für Smartpointer und trotzdem nutzen manche rohe Pointer. Sie werden auch aus demselben Grund unsafe Blöcke verwenden.
-
Gute Nachrichten, meine Arbeitssituation hat sich geändert. Ich werde wohl nie mehr auch nur eine Zeile Code schreiben. Das bedeutet ihr könnt weiter an die vielen 100% speichersicheren C++-Projekte glauben, wovon ich nicht ein einziges kenne. Bei Rust ist das einfach, alles was nicht in einem unsafe Block ist, ist sicher.
C++ ist ein einziger unsafe Block...arme IT-Welt wenn das so bleibt.
Also von mir dann alles Gute, bye bye.
-
Eine Aussage in der Richtung „in einem C++-Programm gibt es immer Speicherfehler“ sollte man werten wie „in einem PHP-Programm gibt es immer Sicherheitslücken“. Selbstverständlich ist das absolut gesehen falsch, das heißt aber nicht, dass es nicht bestimmte Tendenzen geben kann. Natürlich kann man eine PHP-Anwendung absolut sicher programmieren, aber wenn man auf Sicherheit Wert legt, sieht man sich vielleicht doch nach einer anderen Sprache um.
Ich möchte die Aussage an sich nicht unterstreichen. Ich bin auch der Meinung, dass durch konsequente Anwendung von RAII und entsprechender Smartpointer in mehr als 90% der Fälle keine Speicherfehler entstehen, sondern nur in Randfällen, die in der Praxis selten auftauchen. Ich möchte aber darauf hinweisen, dass die entsprechenden Aussagen in Bezug auf C++ weniger absolut interpretiert werden sollten, als dass manche hier tun.
Außerdem möchte ich bemerken, dass manche C++ hier mit Argumenten der Art „brauch ich nicht, passiert mir nicht“ verteidigen. Aber ungeachtet der vielen Gründe, die gegen einen Umstieg auf Rust sprechen, sollte man doch einsehen, dass in puncto Speichersicherheit Rust objektiv besser ist als C++. Selbst wenn es am Ende eine Gegenüberstellung ist von „verhindert 95% der Speicherfehler“ vs. „verhindert 99,9%“.
-
@NewHope
Ich glaub ich hab dich auch falsch verstanden.
Du hast "Speicherfehler" geschrieben und ich hab "Memory-Leaks" gedacht.Was andere Speicherfehler angeht, also z.B. die allseits beliebten Data-Races, ... also das fehlerfrei hinzubekommen ist schon nicht mehr so trivial. Wenn man weiss wie man es macht, aufpasst und ein wenig Glück hat hat man auch da gute Chancen ein grösseres Projekt halbwegs fehlerfrei hinzubekommen. Aber da würde ich mich nicht mehr zu behaupten trauen dass ich das automatisch und im Halbschlaf immer richtig mache. Fast immer, aber sicher nicht im Halbschlaf
Und ja, natürlich ist es eine gute Sache wenn die Sprache solche Dinge enforcen kann. Bzw. ist das zumindest meine Meinung. Mit der ich aber auch nicht ganz alleine bin. Carmack hat z.B. auf einer "seiner" letzten Quakecons in seiner Keynote erwähnt dass er gerne Tools hätte mit denen er viele zusätzliche Regeln enforcen kann (also diverse Coding-Guidelines, Regeln dieser Art).
-
Jo, kein Thema. Ach ich bin jetzt übrigens nur noch Anwender von Grafik und Audioprogrammen und habe daher nie wieder was mit Programmierung zu tun(Vielleicht mal ein Script, mehr aber nicht). Nach 10 Jahren in der Branche hatte ich einfach die Nase voll. Euch allen viel Spaß bei der Software-Entwicklung, mich hat sie letzten Endes doch nicht glücklich gemacht. Das was ich jetzt mache sieht und hört man sofort und kann es auch nicht ITlern zeigen. So was ist einfach schöner für mich.
Also...machts gut.
-
An die C++ Verfechter: Kann mir mal jemand ein Chrome oder Mozilla Release zeigen, in denen keine Speicherfehler vorkommen? Bin gespannt!
-
Realität schrieb:
An die C++ Verfechter: Kann mir mal jemand ein Chrome oder Mozilla Release zeigen, in denen keine Speicherfehler vorkommen? Bin gespannt!
An dich: Kannst du bitte mal ein Rust Projekt zeigen, dass es besser hinbekommt?
-
Realität schrieb:
An die C++ Verfechter: Kann mir mal jemand ein Chrome oder Mozilla Release zeigen, in denen keine Speicherfehler vorkommen? Bin gespannt!
Firefox besteht aus fast 5 Mio Zeilen C++ und 2 Mio Zeilen C (100k Zeilen Assembler, 2.5 Mio Zeilen Javascript und vieles mehr) und ist schon 10 Jahre alt. Da arbeiten extrem viele Leute dran und natürliches ist vieles veraltet aber man kann nicht ständig alles neu schreiben. Auch mit Rust wäre die Welt nicht gerettet.
-
Marthog schrieb:
Realität schrieb:
An die C++ Verfechter: Kann mir mal jemand ein Chrome oder Mozilla Release zeigen, in denen keine Speicherfehler vorkommen? Bin gespannt!
An dich: Kannst du bitte mal ein Rust Projekt zeigen, dass es besser hinbekommt?
Checkst du es eigentlich nicht? In Rust kriegst du ohne unsafe Block keine Speicherfehler und Data Races hin!
Es gibt ein interessantes youtube-Video über Servo, das schon ziemlich weit fortgeschritten ist. Kann ich nur empfehlen!
-
Realität schrieb:
Checkst du es eigentlich nicht? In Rust kriegst du ohne unsafe Block keine Speicherfehler und Data Races hin!
Es gibt ein interessantes youtube-Video über Servo, das schon ziemlich weit fortgeschritten ist. Kann ich nur empfehlen!Jedes grosse Projekt wird irgendwann Fehler haben. Selbst wenn es keine Speicherfehler gibt, kann es immer noch andere Probleme geben. Mein Firefox ist auf meinem alten PC oft abgestuerzt, weil es Fehler in der Hardwareunterstuetzung gab. Also hilft Rust schonmal wenig, wenn die OpenGl- (oder was die nehmen) Implementierung kaputt ist oder falsch benutzt wird.
Gerade bei legacy-libraries und das sind fast alles muss man irgendwelche Funktionen
An geschwindikeitskritischen Stellen wird man wahrscheinlich auf memcpy und damit unsafe-Bloecke zurueckgreifen.Den Heartbleed haette auch Rust wahrscheinlich nicht verhindern koennen, ausser man waere bereit gewesen, sich an entsprechender Stelle mit der halben Geschwindigkeit auszugeben. Es gibt zwar eine Designaenderung, die Sicherheit und Geschwindigkeit bietet, aber diese ist in C++ genauso moeglich.
-
Marthog schrieb:
Mein Firefox ist auf meinem alten PC oft abgestuerzt, weil es Fehler in der Hardwareunterstuetzung gab. Also hilft Rust schonmal wenig, wenn die OpenGl- (oder was die nehmen) Implementierung kaputt ist oder falsch benutzt wird.
Das ist ein sprachunabhängiges Problem und hat nichts mit dem Thema zu tun!
Marthog schrieb:
Den Heartbleed haette auch Rust wahrscheinlich nicht verhindern koennen, ausser man waere bereit gewesen, sich an entsprechender Stelle mit der halben Geschwindigkeit auszugeben.
Heartbleed war möglich, weil malloc selbst implementiert wurde, was nichts mit Geschwindigkeit zu tun hatte.
-
Realität schrieb:
Heartbleed war möglich, weil malloc selbst implementiert wurde, was nichts mit Geschwindigkeit zu tun hatte.
Der Heartbleed bug entstand, weil ein grosser Speicherblock angefordert wurde und danach mit memcpy unter Umstaenden zu wenige Daten reinkopiert, sodass der Speicher noch immer den alten Inhalt hat. Man haette zwar Speicher grundsaetzlich auf 0 setzen koennen, aber das macht keiner, auch nicht bei rust. Der eigene allocator hat das Problem nur verschaerft, weil dadurch die Speicherbereiche mit den interessanten Daten, also den gerade eingetroffenen oder abgeschickten Paketen wiederverwendet wurden.
Haette man in Rust std::Vec mit resize verwendet, waere der Speicher zwar initialisiert worden, aber mit halber Geschwindigkeit, weil erst alles geloescht und dann ueberschrieben worden waere. Die Alternative mit einem unsafe-Block und std::ptr::copy_nonoverlapping_memory waere genauso fehlerhaft.
Die richtige Alternative hingegen mit push_all waere in C++ mit einem iterator und append genauso machbar und ebenfalls ohne fehler.
-
Realität schrieb:
Heartbleed war möglich, weil malloc selbst implementiert wurde, was nichts mit Geschwindigkeit zu tun hatte.
Wie kommst du darauf dass das nix mit Geschwindigkeit zu tun gehabt hat?
-
hustbaer schrieb:
Realität schrieb:
Heartbleed war möglich, weil malloc selbst implementiert wurde, was nichts mit Geschwindigkeit zu tun hatte.
Wie kommst du darauf dass das nix mit Geschwindigkeit zu tun gehabt hat?
Ok, hier habe ich wohl Mist erzählt. Ich hatte das irgendwie in Erinnerung, dass das mit Features zusammenhing, was ich aber nicht durch Recherche nachvollziehen konnte.
Der Punkt ist: Eine eigene Implementierung war letztendlich Mist. Man macht so etwas nicht. Nichtsdestotrotz: Wenn man für ausgewählte Stellen unsichere Implementierungen haben will, dann geht das mit rust auch, aber so etwas ist nicht die Regel, sondern die Ausnahme. Das ist der entscheidende und eklatante Unterschied!
-
Marthog schrieb:
An geschwindikeitskritischen Stellen wird man wahrscheinlich auf memcpy und damit unsafe-Bloecke zurueckgreifen.
Moment mal, ich verfolge das hier nur am Rande, aber bis jetzt schien es mir so als wuerde die "Speichersicherheit" von Rust durch Sprachmittel zur Compilezeit garantiert werden, warum sollte man also einen unsafe Block brauchen um effizient Speicher zu kopieren?
-
Realität schrieb:
Der Punkt ist: Eine eigene Implementierung war letztendlich Mist. Man macht so etwas nicht.
Eigene Implementierung? Doch.
Nichtsdestotrotz: Wenn man für ausgewählte Stellen unsichere Implementierungen haben will, dann geht das mit rust auch, aber so etwas ist nicht die Regel, sondern die Ausnahme. Das ist der entscheidende und eklatante Unterschied!
Der Unterschied ist komplett irrelevant. Unabhängig vom Default, manche Programmierer werden unsafe verwenden, wie ich schon sagte. Das sind dann auch die, die rohe, besitzende Pointer in C++ verwenden. Solange Rust unsafe anbietet, werden es manche verwenden. Das ist simple Psychologie.
Nochmal: Gute Programmierer schreiben immer guten Code, schlechte Programmierer immer schlechten. Die Programmiersprache hat damit nichts zutun.
Und dieses C++ Gebashe ua. von NewHope nervt einfach nur. Es ist genauso gut möglich in C++ sichere Programme zu schreiben, wie in Rust unsichere. Punkt.
-
Realität schrieb:
Nichtsdestotrotz: Wenn man für ausgewählte Stellen unsichere Implementierungen haben will, dann geht das mit rust auch, aber so etwas ist nicht die Regel, sondern die Ausnahme. Das ist der entscheidende und eklatante Unterschied!
Das Projekt war wohl auch ziemlich vermuellt. LibreSSL hat in wenigen Wochen 90,000 Zeilen ersatzlos geloescht und bei OpenSSL hat man wohl auch oft selber workarounds geschrieben, statt Bugs in irgendwelchen Libraries zu melden und dadurch sehr viel unnoetigen Muell implementiert. Vor dummen Projectmanagern schuetzt auch Rust nicht.
-
Wer in rust ständig unsafe benutzt, kann gleich bei C++ bleiben. Das wäre die falsche Zielgruppe. qed.
-
Wer in C++ ständig rohe besitzende Zeiger benutzt, kann gleich bei C bleiben. Das wäre die falsche Zielgruppe.
-
cooky451 schrieb:
Marthog schrieb:
An geschwindikeitskritischen Stellen wird man wahrscheinlich auf memcpy und damit unsafe-Bloecke zurueckgreifen.
Moment mal, ich verfolge das hier nur am Rande, aber bis jetzt schien es mir so als wuerde die "Speichersicherheit" von Rust durch Sprachmittel zur Compilezeit garantiert werden, warum sollte man also einen unsafe Block brauchen um effizient Speicher zu kopieren?
Ich sehe nicht wozu man memcpy braucht? Rust hat auch sowas wie PODs und jede Kopie wird dann zu memcpy.
Nathan schrieb:
Nochmal: Gute Programmierer schreiben immer guten Code, schlechte Programmierer immer schlechten. Die Programmiersprache hat damit nichts zutun.
Ja, bleib du bei Assembler.
Und dieses C++ Gebashe ua. von NewHope nervt einfach nur. Es ist genauso gut möglich in C++ sichere Programme zu schreiben, wie in Rust unsichere. Punkt.
Die Erfahrung hat gezeigt, dass es keine sicheren grösseren Programme gibt. Java Programme haben aber z.B. grundsätzlich weniger Probleme als C-Programme. Die Programmiersprache hilft nachweisbar.
