Frage an die Programmierer



  • groovemaster schrieb:

    Buffer-Overruns sollten heutzutage nun wirklich kein Problem mehr sein, weder in C, und erst recht nicht in C++.

    sollten sie dann aber vor 20 jahren genauso wenig... darum kamen und kommen die ja auch so selten vor...



  • Reyx schrieb:

    Java hat als Interpretersprache (ja, das ist es, auch wenn die Javaianer gerne das Gegenteil behaupten) ganz andere Möglichkeiten, auf solche Fehler zu reagieren bzw. ihnen entgegen zu wirken. Wie stellst du dir das bei nativem Code vor?

    man könnte es endlich mal lassen, "nativen code" zu verwenden. das würde uns diese probleme ersparen.

    @halteproblem:
    für jeden algorithmus, bei dem ein mensch eine endlosschleife erkennt lässt sich ein algorithmus schreiben, der dies ebenfalls kann. im übrigen ist das, was der mensch beim "denken" macht auch nichts weiter, als eine gute mischung aus "algorithmus" und "raten"

    :schland:



  • Reyx schrieb:

    Wie stellst du dir das bei nativem Code vor?

    Für Bereichsprüfungen bei Arrayzugriffen braucht man keine virtuelle Maschine. Solche Bereichsprüfungen können auch in den nativen Maschinencode eingebaut werden. Ich sehe da gar kein Problem.



  • groovemaster schrieb:

    Ranner schrieb:

    Der Instruction Pointer muss ja bei Funktionsaufrufen aufm Stack landen dagegen kannste auch nicht viel machen.

    Das ist Käse. Der IP landet nirgendwo, und schon gar nicht aufm Stack. Wenn überhaupt, dann steht der IP mit dem Code Segment in Verbindung.

    Hmmmm?
    Wieso ist das Käse? Bei mir landet der IP meistens auf dem Stack...



  • Fehler gibt es, weil es in der Natur des Menschen liegt Fehler zu machen.

    Und manche Tools verleiten eher dazu Fehler zu machen als andere (aber kein einziges Tool hindert mich am Fehler machen). So dass wir das Problem haben:

    Mensch macht gerne Fehler und Tool verleitet ihn dazu. Das kombiniert mit so schicken Sachen wie Termindruck, etc. macht ein nicht wirklich schoenes Gebilde daraus 😉



  • Shade Of Mine schrieb:

    Fehler gibt es, weil es in der Natur des Menschen liegt Fehler zu machen.

    Und manche Tools verleiten eher dazu Fehler zu machen als andere (aber kein einziges Tool hindert mich am Fehler machen). So dass wir das Problem haben:

    Mensch macht gerne Fehler und Tool verleitet ihn dazu. Das kombiniert mit so schicken Sachen wie Termindruck, etc. macht ein nicht wirklich schoenes Gebilde daraus 😉

    ...womit wir dieses problem auf die endlichkeit der menschlichen existenz zurückgeführt hätten. :schland:



  • DrGreenthumb schrieb:

    sollten sie dann aber vor 20 jahren genauso wenig

    Sicher, nur war es damals aufwendiger. Immerhin gab es noch keine STL. Und die C Programmierer haben auch dazugelernt.

    audacia schrieb:

    Wieso ist das Käse? Bei mir landet der IP meistens auf dem Stack...

    Nein, das tut er mit Sicherheit nicht. Wie kommst du auf sowas?
    Der IP gibt die aktuelle Position im Code Segement (cs) an, also die Stelle, an der die CPU den nächsten Maschinenbefehl abholt, um diesen zu verarbeiten. Der Stack, oder besser das Stack Segment (ss), ist eine ganz andere Baustelle.



  • Der IP wird vor jedem Funktionsaufruf auf den Stack gepusht und wenn die Funktion durch ist und alle (lokalen) Variablen wieder von Stack sind wird auch der IP vom Stack gepopt damit man die Adresse wieder hat wo man vor dem Aufruf war und wieder zurück springen kann. Es wird natürlich nicht der IP auf den Stack gepusht (der ist ja festgelötet), sondern der Wert, welcher ja beim Funktionsaufruf überschrieben wird.



  • JetztPassMalAuf schrieb:

    Der IP wird vor jedem Funktionsaufruf auf den Stack gepusht

    Das ist aber nicht der IP, sondern die Rücksprungadresse. Das ist beim Call nunmal zufällig der selbe Wert. Aber schon wenn man in der Funktion selbst ist, dann sind der IP und der Wert auf dem Stack zwei vollkommen andere Werte.
    Vielleicht habe ich *Ranner* auch nur falsch verstanden. Wenn er die Rücksprungadresse meinte, dann hat er Recht. Das ist aber nicht der IP. Dieser Wert wird erst zum IP, wenn der ret Befehl abgearbeitet wird.



  • Toll. Jetzt zitierst du die ersten 5 Worte von mir und schreibst dann nochmal das gleiche mit anderen Worten.



  • Lern lesen! 💡

    JetztPassMalAuf schrieb:

    Der IP wird vor jedem Funktionsaufruf auf den Stack gepusht

    🇲🇪 schrieb:

    Das ist aber nicht der IP, sondern die Rücksprungadresse

    Ausserdem habe ich mehr als 5 Worte zitiert, so kleinlich will ich aber mal nicht sein. 😉



  • So, habe mir jetzt nochmal die Intel Docs angeschaut, die sprechen tatsächlich vom IP, oder genauer gesagt bei IA-32 vom EIP. Es sollte trotzdem klar sein, dass beim Call nur der Wert selbst, also die Adresse auf dem Stack landet. Aber nicht der IP im eigentlichen Sinne auf dem Stack verfügbar ist. Sry, falls ich *Ranner* da falsch verstanden habe.



  • Na dann is ja gut...



  • jop aber immer erst das Mäulchen weit aufreissen nicht wahr mein kleiner groovemaster.

    MfG,
    :schland: *Ranner* :schland:



  • Als Unreg ignoriere ich dich einfach mal... 🙄

    Zumal der entscheidende Punkt bei Buffer-Overruns ja auch nicht der ist, dass beim Funktionsaufruf der IP auf den Stack kopiert wird. Sondern dass beim ret die Rücksprungadresse vom Stack geholt wird.



  • Da hast du aber mal Glück gehabt, das Ranner nicht Moderator ist, sonst hätte er dich für immer gebannt.



  • Ein Thema und die Trollerei ist da... wo kommen die her, ist das Heise-Forum zu?



  • @GlückGehabt: Tja, ich bin auch froh, dass man ihn auf sein Angebot hin nicht haben wollte *lol*
    @Diamond: Nö, aber die haben { Ranner | *Ranner* | Real_Ranner } und Kohorten wieder freigelassen ... 🙄

    Greetz, Swordfish



  • LOL wer ist denn hier der Troll Swordfish. Dein Beitrag hier ist wieder mal völliger Schrott während mein Beitrag hier im Thread sinnvoll und ernstgemeint war.

    MfG,
    :schland: *Ranner* :schland:



  • Swordfish ist Fachmann im Müll posten. f'`8k


Anmelden zum Antworten