C-Hasser



  • Hey Leute, dann programmiert doch die Betriebssysteme in Basic.



  • net schrieb:

    DrGreenthumb schrieb:

    Habe die Seite nur überflogen aber da steckt schon viel Wahrheit drin.

    leider kommt man um 'c' manchmal nicht herum. da bleibt nur noch assembler, aber das ist ja noch schlimmer.

    Na, na. Da, wo man um C nicht herumkommt, das sind in erster Linie irgendwelche Mikrocontroller, wo es einfach nichts anderes gibt (wobei es auch genug Embedded-Kram gibt, auf dem auch kein C läuft). Wir reden hier aber über PCs und sowas. Ich sehe da keinen Anwendungsfall, wo ich C nehmen kann, aber eine andere (und mit dem Hinblick auf Sicherheit besser konzipierte) Sprache wie zB Ada nicht gehen würde.

    BTW: C++ nun sicherheitstechnisch kein großer Fortschritt gegenüber C, weil die Sprache so kompliziert und unübersichtlich ist. Ich finde eine recht schöne Demonstration dafür ist, daß Firefox, Internet Explorer, Opera, Konqueror usw. alle in C++ geschrieben sind und trotzdem reproduzierbar bei dem Besuch von bestimmten Seiten abstürzen, wo doch C++ alles besser macht und Pufferüberläufe verhindert. Augenscheinlich tut es das nicht, oder die Leute haben alle keine Ahnung. Dann könnte man allerdings C++ vorwerfen, daß es das Keine-Ahnung-Haben zu leicht macht, wenn es ja schon alles besser macht.



  • Und warum ist das ein Fehler von C++? Wenn ein Projekt so groß ist wie firefox und co., dann ist es jawohl nicht verwunderlich, dass einige Fehler drin sind.



  • Das Problem ist das sehr sehr viele Leute nicht richtig C++ programmieren können. Kann man wunderbar nachvollziehen, wenn man sich ein paar C++ Projekte bei Sourceforge runterlädt.



  • Daniel E. schrieb:

    net schrieb:

    DrGreenthumb schrieb:

    Habe die Seite nur überflogen aber da steckt schon viel Wahrheit drin.

    leider kommt man um 'c' manchmal nicht herum. da bleibt nur noch assembler, aber das ist ja noch schlimmer.

    Na, na. Da, wo man um C nicht herumkommt, das sind in erster Linie irgendwelche Mikrocontroller, wo es einfach nichts anderes gibt (wobei es auch genug Embedded-Kram gibt, auf dem auch kein C läuft). Wir reden hier aber über PCs und sowas. Ich sehe da keinen Anwendungsfall, wo ich C nehmen kann, aber eine andere (und mit dem Hinblick auf Sicherheit besser konzipierte) Sprache wie zB Ada nicht gehen würde.

    ne, du redest von pc's. hier geht's doch allgemein darum wie mies 'c' ist. 'ada' ist übrigens ein gutes stichwort: das wird auch auf embedded systemen eingesetzt, bei denen ein crash schlimme auswirkungen hätte. ...und auf pc-artigen boliden kann man auch noch java und .NET nehmen.
    btw: in dem punkt bin ich deiner meinung: c++ ist kein bisschen besser als c.



  • theoretisch ist c++ viel besser als c.



  • Natürlich ist C++ sicherheitstechnisch besser als C. Man kann sehr viel automatisieren, was man normal vergessen könnte. Und wenn man keine C-Arrays verwendet, kann man u.U. sogar die meisten Bufferoverflows vermeiden.



  • Optimizer schrieb:

    Natürlich ist C++ sicherheitstechnisch besser als C. Man kann sehr viel automatisieren, was man normal vergessen könnte. Und wenn man keine C-Arrays verwendet, kann man u.U. sogar die meisten Bufferoverflows vermeiden.

    Schau dir mal die gängigen Sicherheitsstandards für Software an (IEC 1508 u.ä.). Nach solchen Kriterien schneidet C++ nicht besser ab als C.



  • Was haben Sicherheitsstandards mit Software damit zu tun? Ich habe gesagt, dass man in C++ leichter sichere Programme schreiben kann als in C, mehr nicht. Willst du das bestreiten? Ob die Leute es dann tun ist ne andere Frage.



  • aus wiki, stichwort bufferoverflow:

    Hier ist ein Programmierer gezwungen, von Hand den entsprechenden Code zu generieren, wobei oft entweder absichtlich oder aus Nachlässigkeit darauf verzichtet wird. Die Überprüfung ist häufig auch fehlerhaft codiert, da während der Programmtests diese Programmteile meist nicht oder ungenügend getestet werden.

    und das wollt ihr nun auf C/C++ schieben? ist ja lächerlich. so wie jede andere programmiersprache ist C/C++ nur ein werkzeug. wenn man zu dämlich ist eine kleine abfrage zu schreiben, ob der buffer nun ausreicht oder nicht dann ist man selber drann schuld.



  • Optimizer schrieb:

    Was haben Sicherheitsstandards mit Software damit zu tun?

    Äh, es *gibt* Sicherheitsstandards für Software, darum geht's. Hast Du noch nie was von SIL-Stufen gehört? Niemand will SIL-4-Software in C++ schreiben. Willst Du das bestreiten?

    Ich habe gesagt, dass man in C++ leichter sichere Programme schreiben kann als in C, mehr nicht. Willst du das bestreiten?

    Ja.

    DEvent schrieb:

    aus wiki, stichwort bufferoverflow:

    Wikipedia: Ahnungslose helfen Laien.

    und das wollt ihr nun auf C/C++ schieben? ist ja lächerlich. so wie jede andere programmiersprache ist C/C++ nur ein werkzeug. wenn man zu dämlich ist eine kleine abfrage zu schreiben, ob der buffer nun ausreicht oder nicht dann ist man selber drann schuld.

    "Alle sind dämlich" ist natürlich ein sehr hübsches Weltbild. Wenn man eine Zeit Bugtraq gelesen hat, wird man verstehen, was ich meine. Dort sieht man nämlich wunderschön, daß alle die gleichen kritischen Fehler machen. Warum also kein Werkzeug nehmen, mit dem man diese Fehler kaum machen kann?



  • DEvent schrieb:

    [...] wenn man zu dämlich ist eine kleine abfrage zu schreiben, ob der buffer nun ausreicht oder nicht dann ist man selber drann schuld.

    Wenn du mal groß bist, darfst du alles besser machen. 🙄

    DEvent schrieb:

    Hier ist ein Programmierer gezwungen, von Hand den entsprechenden Code zu generieren, wobei oft entweder absichtlich oder aus Nachlässigkeit darauf verzichtet wird. Die Überprüfung ist häufig auch fehlerhaft codiert, da während der Programmtests diese Programmteile meist nicht oder ungenügend getestet werden.

    und das wollt ihr nun auf C/C++ schieben? ist ja lächerlich. so wie jede andere programmiersprache ist C/C++ nur ein werkzeug.

    Das von dir war gerade übelste Zitatverfälschung.
    Du hast den relevantesten Teil gerade weggelassen. Ich hab mich schon gewundert, wo der Programmierer gezwungen ist...usw.

    Also hab ich mir die beiden Sätze davor angeschaut.

    Die wesentliche Ursache für Bufferoverflows sind aber Programmiersprachen, die nicht die Möglichkeit bieten, Grenzen von Speicherbereichen automatisch zu überwachen, um eine Überschreitung von Speicherbereichen zu verhindern. Hierzu gehört besonders die Sprache C, die das Hauptgewicht auf Performance (und ursprünglich Einfachheit des Compilers) legt und auf eine Überwachung verzichtet, sowie die C-Weiterentwicklung C++. [ab hier geht das von dir zitierte weiter]

    Spitzenleistung. 👍



  • ja ok vieleicht war es ein wenig aus dem zusammenhang gerissen 🙂

    auf was ich ja hinaus wollte, mit c++ kann man ja so ziemlich alles machen. das mag ich eher so an c++. man sollte auch ahnung von der sprache haben die man verwendet. es ist nunmal keine sprache die einem das denken übernimmt.



  • Das heist C++ ist schlecht weil es vector<T>::operator[] und vector<T>::at gibt? Eine Sprache die also nur vector<T>::at hat ist also überlegen? Naja Ansichtssache. 🙄



  • DEvent schrieb:

    das mag ich eher so an c++. man sollte auch ahnung von der sprache haben die man verwendet. es ist nunmal keine sprache die einem das denken übernimmt.

    arroganz, arroganz...
    darf ich mal fragen, wie viele hochkomplexe programme du schon geschrieben hast?



  • Wer den text da geschrieben hat der hat sich ganz schön mühe gegeben. Ich frage mich, in was der betreffende so codet, schließlich hat er ja von C scheinbar eine Ahnung.

    Und C / C++ bietet die meißten möglichkeiten - nach assembler.



  • BloodLord schrieb:

    Wer den text da geschrieben hat der hat sich ganz schön mühe gegeben. Ich frage mich, in was der betreffende so codet, schließlich hat er ja von C scheinbar eine Ahnung.

    Die Welt ist ja zum Glück ein bißchen größer, als Du dir das von deinem C-Teller aus vorzustellen scheinst. Wenn der Autor über den Text nicht "C-Hasser", sondern "gängige C-Anfängerfehler" drübergeschrieben und die polemischen Spitzen weggelassen hätte, dann würde der Text vermutlich im Forum öfter zitiert.

    Und C / C++ bietet die meißten möglichkeiten - nach assembler.

    Falsch.



  • Man kann mit C++ schon sicher programmieren. Das Problem fängt aber allein dabei an, dass dies weder in der Standard Library noch von den Compiler-Herstellern so vorgesehen ist. Man kann erst recht keinen sicheren Stil erzwingen.

    Das kann man `C++` schon vorwerfen.

    Es gibt Programmiersprachen, die sehr viel mehr Sicherheit dem Programmierer aufzwingen. Eiffel und ADA (SPARK) fallen mir da ein, obwohl ich diese beiden Programmiersprachen (noch) nicht wirklich kenne.



  • in C++ ist ungeheuer einfach solche fehler zu begehen, wie sie in dem Text dargestellt sind. zwar hat man mit assert etc die mittel zur hand um eben diesen missstand mit viel arbeit aus der welt zu schaffen, schade ist es allerdings, dass die sprache selber sich nicht um sowas kümmert(was ich sehr schade finde ist, dass der so einfach zu nutzende op[] von vector und konsorten kein assert verwendet, und sich in dem punkt dann doch wieder sehr den c-arrays annähert. Und wer benutzt schon at, wenn der op[] viel einfacher zu lesen und verstehen ist...)



  • C hassen ist etwas besonderes,

    C hassen ist eher der neid derer die nicht in C programmieren können :p 😃

    lo0ol


Anmelden zum Antworten