1. Foren
  2. Kommentare
  3. Wissenschaft
  4. Alle Kommentare zum Artikel
  5. › Sel4: Fehlerloser Microkernel…

Codeanalyse

  1. Thema

Neues Thema Ansicht wechseln


  1. Codeanalyse

    Autor: monettenom 29.07.14 - 21:55

    Ich habe mir den Code mal grob angesehen und was mir recht schnell auffiel war, dass zum Beispiel als Parameter übergebenen Zeiger nicht auf null geprüft werden. Auch andere Parameterchecks finden kaum statt. Trotzdem gilt der Code als sicher.

    Das muss kein Problem sein, wenn die Gültigkeit der Parameter durch den Kontext gegeben, also implizit sichergestellt ist.

    Das finde ich insofern interessant als dass man bei jedem Projekt ständig irgendein Klugscheißer aufschreit, wenn man einen Parameter nicht auf null prüft, obwohl man selbst genau weiß, dass das durch den Aufrufpfad gar nicht notwendig ist. Es gab sogar ein Projekt, bei dem man Referenzen auf null prüfen sollte, weil es potentiell möglich ist, so eine Referenz zu übergeben.

    Daher finde ich es eine durchaus interessante Übung, diesen Code unter der Annahme zu analysieren, dass er wirklich sicher ist und herauszufinden, warum solche Checks in diesem Fall tatsächlich nicht nötig sind.

  2. Re: Codeanalyse

    Autor: rommudoh 30.07.14 - 10:15

    monettenom schrieb:
    --------------------------------------------------------------------------------
    > Das finde ich insofern interessant als dass man bei jedem Projekt ständig
    > irgendein Klugscheißer aufschreit, wenn man einen Parameter nicht auf null
    > prüft, obwohl man selbst genau weiß, dass das durch den Aufrufpfad gar
    > nicht notwendig ist. Es gab sogar ein Projekt, bei dem man Referenzen auf
    > null prüfen sollte, weil es potentiell möglich ist, so eine Referenz zu
    > übergeben.

    Das nennt sich over-defensive programming. Im prinzip unnötig, nur die Vorschriften zwingen einen dazu.

    Wenn sichergestellt ist, dass ein Parameter nicht null sein kann, muss man auch nicht nochmal prüfen. Wenn z.B. eine Funktion nur lokal von einer anderen aufgerufen wird und diese vorher auf null prüft, muss die lokale Funktion keine Checks machen.

  3. Re: Codeanalyse

    Autor: gadthrawn 31.07.14 - 08:41

    rommudoh schrieb:
    --------------------------------------------------------------------------------
    > monettenom schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Das finde ich insofern interessant als dass man bei jedem Projekt
    > ständig
    > > irgendein Klugscheißer aufschreit, wenn man einen Parameter nicht auf
    > null
    > > prüft, obwohl man selbst genau weiß, dass das durch den Aufrufpfad gar
    > > nicht notwendig ist. Es gab sogar ein Projekt, bei dem man Referenzen
    > auf
    > > null prüfen sollte, weil es potentiell möglich ist, so eine Referenz zu
    > > übergeben.
    >
    > Das nennt sich over-defensive programming. Im prinzip unnötig, nur die
    > Vorschriften zwingen einen dazu.
    >
    > Wenn sichergestellt ist, dass ein Parameter nicht null sein kann, muss man
    > auch nicht nochmal prüfen. Wenn z.B. eine Funktion nur lokal von einer
    > anderen aufgerufen wird und diese vorher auf null prüft, muss die lokale
    > Funktion keine Checks machen.

    Sorry, aber das ist Quatsch. Es zeigt von einem tiefen Missverständnis.

    "durch den Aufrufpfad gar nicht notwendig ist" - das kann niemand wissen. Sobald Funktionen/Methoden eingesetzt werden, hat man nicht mehr nur den einen aktuellen Aufrufpfad. Es kann immer einen Punkt in Zukunft geben, in dem eine Methode von jemand anderem verwendet wird. Sei es dass die Methode öffentlich ist, oder dass jemand eine Klasse erweitert. Oder die Methode wird per Reflektion aufgerufen.

    Das ist dann nicht over-defensive - das ist eine normale Prüfung.

  4. Re: Codeanalyse

    Autor: Hello_World 31.07.14 - 11:21

    Ob ein Parameter null sein darf oder nicht ist Teil des Vertrags der betreffenden Methode, und es ist Aufgabe des Aufrufers, sicherzustellen, dass dessen Vorbedingungen eingehalten werden. Denn ansonsten stellt sich die Frage: was soll die Methode denn machen, wenn das nicht der Fall ist? In der Regel ist es dann nicht möglich, die Nachbedingungen zu erfüllen, schließlich denkt man sich die Vorbedingungen nicht zum Spaß aus, also was soll man dann zurückliefern? Vielleicht auch wieder null? Das kaschiert den Fehler nur und macht ihn schwerer zu diagnostizieren (ganz zu schweigen davon, dass viele Sprachen das gar nicht erlauben). Vielleicht sollte man eine Exception werfen? Die kommt schon von allein, wenn man das betreffende Objekt irgendwann nutzen will. Ist also alles sinnlos.

    Es ist daher das ganz normale und sinnvolle Vorgehen, gewisse Vorbedingungen nicht zu prüfen, unter anderem auch, weil das manchmal gar nicht sinnvoll möglich ist. Ein Beispiel ist binäre Suche. Die Vorbedingung ist, dass das Array sortiert sein muss. Das nachzuprüfen geht nur in linearer Laufzeit, aber der Witz an binärer Suche ist gerade, dass sie nur logarithmische Laufzeit braucht, damit ist der Algorithmus dann sinnlos.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Web-Entwickler (m/w/d) für E-Commerce & Webshop B2C
    Ricosta Schuhfabriken GmbH, Donaueschingen
  2. Mitarbeiter (m/w/d) Prozessmanagement IT
    Kindertagesstätten Nordwest Eigenbetrieb von Berlin, Berlin
  3. IT Service Delivery Manager (m/w/d) im Bereich Unix
    Volkswagen Financial Services AG, Braunschweig
  4. Information Security Experts (m/w/d)
    Allianz Deutschland AG, München Unterföhring

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (u. a. Fallout 76 für 12,50€, Wolfenstein II: The New Colossus für 11€, Dishonored: Death of...
  2. Über 3400 Angebote mit bis zu 90 Prozent Rabatt
  3. 29,99€
  4. 23,49€


Haben wir etwas übersehen?

E-Mail an news@golem.de