1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Die 25 gefährlichsten…

Das sind keine Programmierfehler

  1. Thema

Neues Thema Ansicht wechseln


  1. Das sind keine Programmierfehler

    Autor: gagamel 13.01.09 - 11:50

    Es handelt sich hier um eine allgemeinere Kategorie, nämlich um Designfehler.

  2. Re: Das sind keine Programmierfehler

    Autor: TheSeer 13.01.09 - 12:51

    Kann man jetzt philosophisch sehen...

    Ist es ein Design-/Programmierfehler, wenn man etwas gar nicht eingebaut hat?

    Immerhin beeinträchtigen die Fehler ja selten die Funktionalität der eigentlichen Software...

    Anders gesagt: Ein Auto ohne Tankanzeige funktioniert ja trotzdem tadellos und wieviel genau im Tank ist, ist ja für die Funktion nicht immer entscheidend... ;-)

  3. Re: Das sind keine Programmierfehler

    Autor: decke 13.01.09 - 13:46

    Ich gehe sogar weiter und sag die Liste ist blödsinnig und die Empfehlungen dazu purer bullshit.

    Wieso blödsinnig?
    Weil die Liste maximal als Klassifizierung von Fehlern dienen kann aber für die Praxis komplett untauglich ist. Na klar sind Buffer Overflows (CWE-119: Failure to Constrain Operations within the Bounds of a Memory Buffer) eine Gefahr aber das trifft nicht auf alle Programmiersprachen zu und außerdem bringt es dem Programmierer in der Praxis erst wieder nichts wenn er "in bester Absicht" trotzdem einen buffer overflow produziert.


    Wieso bullshit?
    Ich lass meinen Code gerne von einem dieser Sourcecode Analyse Tools überprüfen aber wenn das Tool sagt ich mach alles richtig und dann doch ein Fehler drin ist dann wirds interessant. Der Kunde wird nämlich sicher auf Vertragsverletzung oder dergleichen bestehen und will dann irgendwas von mir obwohl das nicht finden des Fehlers eindeutig ein Problem des Analyse Tool ist. Also ich geb sicher keine Garantien ab für ein Produkt eines anderen Herstellers.

  4. Re: Das sind keine Programmierfehler / hilft Toolunterstützung ?

    Autor: Nullpointer 13.01.09 - 14:32

    decke schrieb:
    -------------------------------------------------------
    > Wieso bullshit?
    > Ich lass meinen Code gerne von einem dieser
    > Sourcecode Analyse Tools überprüfen aber wenn das
    > Tool sagt ich mach alles richtig und dann doch ein
    > Fehler drin ist dann wirds interessant.

    Genau, dann wirds interessant!
    Dann geht es nämlich weiter und deine Erfahrungen sind gefragt.
    Ich lese das aber eher so, als würdest du dann aufhören und dich
    in von dem Tool vorgegebener falscher Sicherheit wiegen.
    Natürlich kann so ein Tool immer nur Ansätze liefern und Basisüberprüfungen vornehmen.


  5. Re: Das sind keine Programmierfehler

    Autor: gagamel 13.01.09 - 15:08

    Bei Buffer-Overflows helfen eher Laufzeit-Analyse-Tools. Natürlich sind aber Debug-Infos bzw. Source-Code-Bezüge dabei unabdingbar. Ein exzellentes solches Tool ist z. Bsp. valgrind: http://valgrind.org/

  6. Oder man verwendet einfach moderne Programmiersprachen...

    Autor: (keine Alternative: kostenlos registr 13.01.09 - 16:11

    wie z.B. Haskell

    Hier werden auch ein paar Fehler besprochen, die in Haskell nicht passieren können:
    http://learnhaskell.blogspot.com/2007/09/lesson-2-input-and-output-variable.html

  7. modern?

    Autor: Missingno. 13.01.09 - 16:24

    In Haskell, the layout of the code is significant.
    O - M - G - !

    No Variable Declarations, But Still Safe
    LOL
    Und typsicher, nicht?

    Was passiert eigentlich, wenn man in dem Beispiel als Name \0<code> eingibt? Wird bestimmt gnadenlos ausgeführt. :D

    --
    Dare to be stupid!

  8. Re: modern?

    Autor: GodsBoss 13.01.09 - 16:28

    > No Variable Declarations, But Still Safe
    > LOL
    > Und typsicher, nicht?
    Haskell ist statisch typisiert.

    > Was passiert eigentlich, wenn man in dem Beispiel
    > als Name \0<code> eingibt? Wird bestimmt
    > gnadenlos ausgeführt. :D
    Hast du es probiert?

    Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

  9. Re: Oder man verwendet einfach moderne Programmiersprachen...

    Autor: lib 13.01.09 - 17:05

    moderne libs (STL z. bsp.) reichen gewöhnlich, um sicheres speichermanagement zu haben, aber man will ja gerne performance rauskitzeln und macht es manuell ...

  10. Re: Oder man verwendet einfach moderne Programmiersprachen...

    Autor: realitätskontrolle 13.01.09 - 17:57

    Haskell ist durchaus eine sehr interessante Sprache, allerdings ohne Relevanz für die Praxis.
    Außerhalb des akademischen Kontexts fällt die konzeptionelle Distanz zu gängigen Sprachen zu stark ins Gewicht, so dass dort von keiner wirklichen Verbreitung gesrochen werden kann.
    Auch sind Frameworks wie HAppS zwar schöne Proof-of-Concept Implementierungen, kommen aber nicht mal auch nur in die Nähe von einem simplen Servletcontainer wie Tomcat.

    Gutes Konzept, hat sich aber nicht durchgesetzt. Leider.

  11. Re: Das sind keine Programmierfehler

    Autor: Hassashin 14.01.09 - 03:27

    TheSeer schrieb:

    > Ist es ein Design-/Programmierfehler, wenn man etwas gar nicht
    > eingebaut hat?
    ...
    > Anders gesagt: Ein Auto ohne Tankanzeige funktioniert ja trotzdem
    > tadellos und wieviel genau im Tank ist, ist ja für die Funktion
    > nicht immer entscheidend... ;-)

    Naja, wenn der Tankdeckel fehlen würde, würde das Auto trotzdem fahren, aber es würde dir nach ein paar Kilometern mit reichlich Kurven schon sauer aufstossen.

    Gruss
    Hassashin

    --
    Schäuble muss weg!
    www.onlinetrojaner.de

  12. Re: Das sind keine Programmierfehler

    Autor: Himuralibima 14.01.09 - 10:05

    decke schrieb:

    > Na klar sind Buffer Overflows
    > (CWE-119: Failure to Constrain Operations within
    > the Bounds of a Memory Buffer) eine Gefahr aber
    > das trifft nicht auf alle Programmiersprachen zu

    Eben. Allein deshalb ist die Liste ein Marketing-Gag ohne Sinn und Verstand; bullshit wie Du sagtest.

    Man braucht keine Werkzeug zur Softwareanalyse, um zu einer vernünftigen Sprache zu wechseln. Wenn eine Sprache bestimmte Programmierfehler massenhaft erzeugt, ja regelrecht provoziert, dann sind den Programmierern nicht diese Fehler anzulasten, sondern die verantwortungslose Entscheidung für die kaputte Programmiersprache.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Hays AG, Vilsbiburg
  2. AKKA, Berlin, Braunschweig, Wolfsburg
  3. Schwarz Dienstleistung KG, Raum Neckarsulm
  4. Sparda-Bank Augsburg eG, Augsburg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 76,90€ (Bestpreis!)
  2. (u. a. Total War Promo: Warhammer 2 für 16,99€, Three Kingdoms für 37,99€, Attila für 11...
  3. 72,90€ (Bestpreis!)
  4. (aktuell u. a. NZXT gläsernes Tower-Gehäuse für 99,90€, Lenovo Thinkpad T440, generalüberholt...


Haben wir etwas übersehen?

E-Mail an news@golem.de


In eigener Sache: Die offiziellen Golem-PCs sind da
In eigener Sache
Die offiziellen Golem-PCs sind da

Leise, schnell, aufrüstbar: Golem.de bietet erstmals eigene PCs für Kreative und Spieler an. Alle Systeme werden von der Redaktion konfiguriert und getestet, der Bau und Vertrieb erfolgen über den Partner Alternate.

  1. In eigener Sache Was 2019 bei Golem.de los war
  2. In eigener Sache Golem.de sucht Produktmanager/Affiliate (m/w/d)
  3. In eigener Sache Aktiv werden für Golem.de

Energie: Dieses Blatt soll es wenden
Energie
Dieses Blatt soll es wenden

Schon lange versuchen Forscher, die Funktionsweise von Blättern nachzuahmen. Nun soll es endlich gelingen - und um Längen effizienter sein als andere Verfahren zur Gewinnung von Wasserstoff.
Ein Bericht von Werner Pluta

  1. Energiewende Grüner Wasserstoff aus der Zinnschmelze
  2. Brennstoffzelle Deutschland bekommt mehr Wasserstofftankstellen
  3. Energiewende Hamburg will große Wasserstoff-Elektrolyseanlage bauen

Elektroautos: Die elektrischste Tiefgarage Deutschlands
Elektroautos
Die elektrischste Tiefgarage Deutschlands

Was muss passieren, damit in zehn Jahren fast jeder in der Tiefgarage sein Elektroauto laden kann? Ein Pilotprojekt bei Stuttgart soll herausfinden, welcher Aufwand auf Netzbetreiber und Eigentümer und Mieter zukommen könnte.
Ein Bericht von Friedhelm Greis

  1. Trotz Software-Problemen VW hält an Terminplan für den ID.3-Start fest
  2. Kabinenroller Microlino 2.0 und dreirädriger E-Motoroller Microletta geplant
  3. Crowdfunding Sono Motors baut vier Prototypen seines Elektroautos

  1. Speech-to-Text: Amazon Transcribe entfernt persönliche Informationen
    Speech-to-Text
    Amazon Transcribe entfernt persönliche Informationen

    Das Speech-to-Text-Angebot Transcribe von Amazon soll künftig auch automatisiert persönliche Informationen entfernen können. Dazu gehören Namen, Kontaktdaten oder auch Bankinformationen. Kunden sollten wohl aber nicht all zu großes Vertrauen in den Dienst setzen.

  2. Open Wheel Racing: GTA Online erhält so etwas wie die Formel 1
    Open Wheel Racing
    GTA Online erhält so etwas wie die Formel 1

    Wettrennen mit sehr schnellen Sportflitzern auf sieben Strecken bietet die Rennserie San Andreas Prix im Onlinemodus von GTA 5. Allerdings scheinen einige Spieler mit der nicht ganz einfachen Fahrzeugsteuerung von Open Wheel Racing überfordert zu sein.

  3. Apex 2020: Vivo stellt Smartphone-Konzept mit echtem Zoom vor
    Apex 2020
    Vivo stellt Smartphone-Konzept mit echtem Zoom vor

    Das Apex 2020 von Vivo zeigt, was der chinesische Hersteller aktuell bei Smartphones leisten kann: Die Frontkamera ist unsichtbar unter dem Display verbaut, die Hauptkamera hat einen echten optischen Zoom und der Akku lässt sich mit 60 Watt drahtlos laden.


  1. 16:11

  2. 15:48

  3. 15:29

  4. 15:12

  5. 14:55

  6. 14:33

  7. 14:17

  8. 14:00