Seite 9 von 13 ErsteErste ... 5678910111213 LetzteLetzte
Ergebnis 161 bis 180 von 255

Thema: while(true) {write();} - Der Programmierer-Spamthread #1

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Hab noch ein bisschen damit rumgespielt und muss sagen, es ist richtig cool. Lege ich jedem ans Herz, der ein bisschen Ahnung von OpenGL und eine Webcam hat.

    Btw: Muss ich mir Gedanken machen, wenn mich Luki bittet, eine RPG Maker 2003 Map für ihn zu bearbeiten und ich einen Hexeditor nehme, statt den passenden Maker zu installieren?

  2. #2
    Zitat Zitat von DFYX Beitrag anzeigen
    Btw: Muss ich mir Gedanken machen, wenn mich Luki bittet, eine RPG Maker 2003 Map für ihn zu bearbeiten und ich einen Hexeditor nehme, statt den passenden Maker zu installieren?
    Nein, das ist ganz normaler Wahnsinn.

  3. #3
    Zitat Zitat von Ineluki Beitrag anzeigen
    Nein, das ist ganz normaler Wahnsinn.
    Dito. Ich patche auch schon mal meine eigenen Tools mit einem Hex-Editor, wenn ich wo einen Schreibfehler finde aber den Source gerade verlegt habe

  4. #4
    Code (C):
     
    #include <stdlib.h>
    #include <stdio.h>
    #include <string.h>
     
    int main(int argc, char* argv[]) {
        char* buffer = NULL;
        buffer = (char*)malloc(1024);
        memset(&buffer, 0, 1024);
        printf("blah blah\n");
        return 0;
    }
     


    Ähnliches, hervorgerufen durch copy & paste, ist mir vor kurzem in einem größeren Programm mit Dateioperationen passiert. Glücklicherweise aber schnell entdeckt.

  5. #5

  6. #6
    Zitat Zitat
    Ähnliches, hervorgerufen durch copy & paste, ist mir vor kurzem in einem größeren Programm mit Dateioperationen passiert. Glücklicherweise aber schnell entdeckt.
    Mein C ist nicht so wirklich gut, aber lese ich richtig das "&Buffer" das Problem ist? Weil es ist ja ein Pointer und so

  7. #7
    calloc() macht doch das selbe, was du gemacht hast.

  8. #8
    Zitat Zitat von Whiz-zarD Beitrag anzeigen
    calloc() macht doch das selbe, was du gemacht hast.
    Schau dir die Verwendung von memset nochmal genauer an

  9. #9
    Zitat Zitat von Mivey Beitrag anzeigen
    Mein C ist nicht so wirklich gut, aber lese ich richtig das "&Buffer" das Problem ist? Weil es ist ja ein Pointer und so
    Dein C ist offensichtlich besser als meins: Ich dachte nur "na toll, wird gar nicht ge-free()-t".

    Zitat Zitat von Whiz-zarD Beitrag anzeigen
    calloc() macht doch das selbe, was du gemacht hast.
    Tut es, und ich frage mich, warum immer malloc() verwendet wird. Kann mir das wer erklären?

  10. #10
    Zitat Zitat von dead_orc Beitrag anzeigen
    Tut es, und ich frage mich, warum immer malloc() verwendet wird. Kann mir das wer erklären?
    Naja, solange du den Speicher nicht genullt brauchst, ist calloc() halt unnötiger Mehraufwand. Andernfalls ist's aber echt eine gute Frage. ^^" Gewohnheit wohl, und die Tatsache, dass es meist nicht viel Unterschied macht, performanztechnisch.

    @ Whiz: Er hat ja geschrieben, "Ähnliches", ist im Original also vielleicht eh sinnvoller, bzw. nicht der Punkt.

  11. #11
    Zitat Zitat von dead_orc Beitrag anzeigen
    Tut es, und ich frage mich, warum immer malloc() verwendet wird. Kann mir das wer erklären?
    Ich denke, das hat wohl was damit zu tun, dass C für Unix gedacht war und Unix generell den Speicher mit Nullen belegt. Da macht es keinen Unterschied, ob malloc() oder calloc(). Nur unter Windows muss man da höllisch aufpassen. Auch wenn man den Speicher nicht genullt braucht, würde ich es dennoch machen. Schaden kann es nicht.

  12. #12
    Daß malloc() den Speicher nullt ist auch unter Unix nicht garantiert. Die meisten oder alle neueren Unixe machen es zwar so, aber garantiert ist es absolut nicht.

  13. #13
    Zitat Zitat von dead_orc Beitrag anzeigen
    Tut es, und ich frage mich, warum immer malloc() verwendet wird. Kann mir das wer erklären?
    In einigen Faellen ist es aufgrund des Zeitbedarfs einfach besser, malloc anstatt calloc zu verwenden.

  14. #14
    Zitat Zitat von Brauni90 Beitrag anzeigen
    In einigen Faellen ist es aufgrund des Zeitbedarfs einfach besser, malloc anstatt calloc zu verwenden.
    Naja, der Zeitbedarf ist doch recht minimal, sodass man ihn schon quasi vernachlässigen kann.
    Der Zeitunterschied zwischen den beiden Funktionen, bei 1.000.000 Blöcken a 1 MB Plus Freigeben des Speichers liegt, bei meinem Rechner, bei 124 ms.
    Ich besitze einen Intel C2D E6600 (2x 2,4 Ghz) und 2 GB RAM.
    Da gibt es eigentlich kein Optimierungspotenzial.

  15. #15
    Zitat Zitat von Whiz-zarD Beitrag anzeigen
    Naja, der Zeitbedarf ist doch recht minimal, sodass man ihn schon quasi vernachlässigen kann.
    Der Zeitunterschied zwischen den beiden Funktionen, bei 1.000.000 Blöcken a 1 MB Plus Freigeben des Speichers liegt, bei meinem Rechner, bei 124 ms.
    Ich besitze einen Intel C2D E6600 (2x 2,4 Ghz) und 2 GB RAM.
    Da gibt es eigentlich kein Optimierungspotenzial.
    Das entspricht einem Mindestdatendurchsatz von etwa 7,7TiB/s, wenn ich mich nicht verrechnet habe Oo. Ein weltweites Text- oder Bildbearbeitungsprogramm zaehlt jedenfalls nicht zu "In einigen Faellen".

  16. #16
    hab jetzt mal alle Programme geschlossen und mein Testprogramm durchlaufen lassen.
    nun liegt der Unterschied sogar bei nur 47 ms.

    Zitat Zitat
    1000000 mal 1048576 Bytes reservieren und freigeben
    Zeit von malloc: 35047 ms
    Zeit von calloc: 35000 ms
    Zeitunterschied: 47 ms

  17. #17
    Zitat Zitat von Mivey Beitrag anzeigen
    Mein C ist nicht so wirklich gut, aber lese ich richtig das "&Buffer" das Problem ist? Weil es ist ja ein Pointer und so
    Ja, richtig. Die interessantere Frage ist aber nicht wo die Ursache ist, sondern was genau dabei passiert. Da es eine lokale Variable auf dem Call Stack ist, wird dieser überschrieben und damit alle im Stack folgenden Rücksprungadressen, Funktionsparameter, etc. Kurz gesagt, Katastrophe. In diesem Fall ist es sogar noch schlimmer, da ohne Debugger das Programm an der Stelle der früher oder später resultierenden Zugriffsverletzung still beendet ("bla bla" wird nicht ausgegeben), ohne auf das Fehlverhalten mit einer entsprechenden Ausnahmebehandlung zu reagieren.

    Zitat Zitat von drunken monkey Beitrag anzeigen
    @ Whiz: Er hat ja geschrieben, "Ähnliches", ist im Original also vielleicht eh sinnvoller, bzw. nicht der Punkt.
    Ursprünglich war es wie erwähnt eine Dateioperation, fread um genau zu sein. memset sollte wirklich nur dem Vorführungszweck dienen.

    Zitat Zitat von Whiz-zarD Beitrag anzeigen
    [...] Auch wenn man den Speicher nicht genullt braucht, würde ich es dennoch machen. Schaden kann es nicht.
    Da würden dir die C-Entwickler vermutlich etwas anderes sagen. Redundanz im Zeichen der Fehlerreduzierung entspricht zum Beispiel nicht der C-Philosophie.

    Die Frage, ob man auf malloc verzichten sollte erinnert mich an die Frage, ob man auf goto verzichten sollte. Hierzu:
    Zitat Zitat
    In computer science:

    1st years don't use goto
    2nd years use goto in assembly language
    3rd years use goto when goto is needed.
    Besonders in C hat goto einen festen Platz und vereinfacht oft den Code, wie zum Beispiel in der Ausnahmebehandlung. Ähnlich verhält es sich mit malloc und calloc. Beide haben Vor- und Nachteile, die je nach Situation andere Gewichtung haben können. Verdammen ist ist in meinen Augen nie gut und schädlicher als fragliche Anwendung.

    Zitat Zitat von Whiz-zarD Beitrag anzeigen
    hab jetzt mal alle Programme geschlossen und mein Testprogramm durchlaufen lassen.
    nun liegt der Unterschied sogar bei nur 47 ms.
    Ohne Code sind diese Resultate nicht wirklich repräsentativ. Man kann auf eine Weise messen und auf eine andere mit jeweils völlig unterschiedlichen Ergebnissen. Entscheidend wären beispielsweise, Granularität, Mittelwertbildung mehrerer Messwerte um Abweichungen durch Interrupts und ähnliches zu minimieren, Reduzierung auf die Messung der tatsächlichen Arbeit (free ist ein Störfaktor), usw.
    Ich habe mal einige Messungen auf meinem Pentium D 2.8 Ghz gemacht und bei mir braucht malloc für 1 MB im Schnitt (10 Messungen hintereinander) etwa 12500 clock cycles (entspricht etwa 4.46 us bei 2.8 Ghz) und calloc etwa 13500 clock cycles (etwa 4.82 us). Damit ist calloc um 8% langsamer als malloc. Nicht viel, aber viel hat man hier auch nicht erwartet, denn Nullsetzung ist sehr billig und in heutigen Zeiten in der Regel SIMD-optimiert. Natürlich erhebe ich keinen Anspruch, dass auch meine Messungen 100%-ig repräsentativ und fehlerfrei sind. Jedenfalls gibt es einen Unterschied, der in manchen Situationen sogar größer sein kann und damit eventuell abgewogen werden könnte, wie zum Beispiel auf Systemen ohne SIMD, wenigen und kleinen Caches etc.

    Geändert von Kyuu (16.02.2010 um 23:04 Uhr)

  18. #18
    Zitat Zitat von Kyuu Beitrag anzeigen
    Verdammen ist ist in meinen Augen nie gut und schädlicher als fragliche Anwendung.
    Stellt sich die Frage, ob du auch noch sprintf() benutzt. Das ist ja bekanntermaßen eine gute Möglichkeit, unkontrolliert Speicher zu überschreiben und viele empfehlen, stattdessen snprintf() (bei C99-fähigen Compilern) oder asprintf() (bei GNU GCC) zu verwenden. Zugegeben, die sind vermutlich beide langsamer, aber solange man nicht per (semi-)formellem Beweis nachweisen will, daß der Puffer nicht überlaufen kann, stellen sie auch Schutz vor einem potentiellen Sicherheitsrisiko dar.

  19. #19
    Also gut, ich verwende eigentlich automatisch schon snprintf() (auch wenn ich praktisch nie C programmiere), aber teilweise würde ich sehr wohl auch sprintf() für gerechtfertigt halten. Z.B. wenn man nur Integers in einen String schreibt – länger als 11/20 Stellen (je nach Größe) können die ja nicht werden. Genauso wenn man bei allen Wildcards auch die Maximallänge angibt (bei Strings halt – floats sind wohl echt problematisch).
    "Verdammen" wäre da vielleicht auch falsch, selbst wenn es allgemein auch kaum schaden wird, einfach immer die sichereren Varianten zu benutzen.

  20. #20
    Interessant wird's dann aber, wenn man in weiser Voraussicht den String auf 11 Stellen dimensioniert hat, weil der Code ja eh nur auf 32bittigen Plattformen zum Einsatz kommt. Und dann kommt plötzlich eine source-kompatible 64bittige Version der Plattform raus oder jemand portiert den Code.

    Das ist (sicherheitstechnisch) das Blöde bei C: Die einzige Sicherheit, die du hast, ist die, die du einbaust. Das ist ein Grund, lieber defensiv zu programmieren als die letzten 0,1% Leistung rauszukitzeln.

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •