Der größte Bug des gcc ist folgendes



  • Er erlaubt dieses Kommando:

    gcc main.c -o main**.c**

    Mit make sicherlich kein Problem, aber in der Kommandozeile hat man das schnell mit der TAB Taste zusammengeklickt, wenn man nicht höllisch aufpasst und dann ist es schon zu spät und der Code ist futsch.
    Dies gilt insbesondere unter einer unix-artigen Umgebung, in der es für ausführbare Programme keine Rolle spielt, wie die Dateiendung lautet.

    Mir ist das zwar nur ein einziges mal passiert, weswegen ich das weiß, aber es ist trotzdem sau doof, dass der gcc hier, oder dessen Linker, keine Dateinamensprüfung vorher macht.



  • Das wäre jetzt ein guter Zeitpunkt um dieses böße PEBKAC zu posten, aber ich werde es nicht tun.



  • Singender Holzkübel schrieb:

    Das wäre jetzt ein guter Zeitpunkt um dieses böße PEBKAC zu posten, aber ich werde es nicht tun.

    Weißt du, warum Steckdosen so designed wurden wie sie designed wurden und warum da nicht einfach nur zwei Drahtklemmen sind, an die man ein Kabel anschließen könnte?

    Denk mal darüber nach, dann bemerkst du vielleicht wie dämlich dein Link in diesem Fall hier ist.



  • Au ja, ein gcc-Aufruf ist lebensgefaehrlich. Toller Vergleich.



  • Wo ist das Problem? Datei neu auschecken, fertig!?



  • knivil schrieb:

    Au ja, ein gcc-Aufruf ist lebensgefaehrlich. Toller Vergleich.

    Weil Quellcode ja keinen Wert darstellt, gell.

    Ich möchte von euch beiden auch mal wissen, was diese dämliche Kloverteidigung des gcc soll?
    Der gcc erlaubt es einem Quellcode durch die falschen Parameter zu überschreiben und das tut er ohne Not. Ihr könnt schließlich gerne mal darlegen, warum ein Binary auf die Dateiendung *.c oder *.cpp enden soll.



  • SG1 schrieb:

    Wo ist das Problem? Datei neu auschecken, fertig!?

    Es geht um ein Beispiel und wer eine Datei auscheckt, der benutzt auch make oder vergleichbares.



  • Und wenn keine Versionsverwaltung eingesetzt wird, ist das noch eindeutiger Fall von PEBKAC.



  • SG1 schrieb:

    Und wenn keine Versionsverwaltung eingesetzt wird, ist das noch eindeutiger Fall von PEBKAC.

    Nein, es ist ein Fall von schlechtem Design, weil diese Fehlerquelle nicht abgefangen wird und dabei wäre es so trivial, die Parameter schon von Beginn an zu prüfen.

    Auch bist du mir immer noch eines Beweis schuldig geblieben, warum ein ausführbares Programm auf *.c oder *.cpp enden soll, bzw. warum es genauso heißen können soll, wie die Quellcodedatei.

    Denk mal darüber nach, wie gering der Aufwand ist, diese beiden Parameter zu vergleichen, das so etwas nicht mehr vorkommen kann.

    Dieser Fehler kann so leicht passieren, dass es schlimm ist, dass niemand darüber nachdenkt, dies zu ändern.
    Man gibt ein:

    1. gcc
    2. die ersten paar Buchstaben der Quellcodedatei, oft reichen schon 2-3.
    3. TAB Taste
    4. -o
    5. die ersten paar Buchstaben nochmals der Quellcodedatei, weil man der Quellcodedatei eben einen aussagekräftigen Namen und nicht nur main.c spendiert hat. Bspw: zinsrechner.c
    6. TAB Taste

    Und jetzt ab diesem Zeitpunkt besteht die große Gefahr dass die Katastrophe passiert.
    Denn die Backspace Taste, die man jetzt eigentlich in Schritt 7 drücken müsste, um die Dateiendung zu korrigieren liegt so nah an der Return Taste, dass hier sehr schnell ein Missgeschick passieren kann und das ist eben einfach ein Designfehler, sieh es ein.
    Es gibt auch nicht einen Grund, warum die Quelldatei genauso heißen soll, wie die Zieldatei. Das hat also absolut gar nichts mit PEBKAC zu tun, sondern das Design der Fehlervermeidung ist hier schlichtweg grottig umgesetzt.



  • SG1 schrieb:

    Und wenn keine Versionsverwaltung eingesetzt wird, ist das noch eindeutiger Fall von PEBKAC.

    Du wirfst für ein kleines Miniprogrämmchen eine Versionsverwaltung an, LOL!
    Und in welchen Zeitabschnitten machst du dann deinen commit?
    Wohl alle 3 Zeilen? 😃



  • Du wirst wohl noch in der Lage sein, es einmal richtig einzutippen und dann einfach den gcc Befehl mit Strg+R neu aufzurufen.

    Und warum sollte ein Programm nicht mit .c oder .cpp enden?



  • Katastrophe schrieb:

    knivil schrieb:

    Au ja, ein gcc-Aufruf ist lebensgefaehrlich. Toller Vergleich.

    Weil Quellcode ja keinen Wert darstellt, gell.

    Ich möchte von euch beiden auch mal wissen, was diese dämliche Kloverteidigung des gcc soll?
    Der gcc erlaubt es einem Quellcode durch die falschen Parameter zu überschreiben und das tut er ohne Not. Ihr könnt schließlich gerne mal darlegen, warum ein Binary auf die Dateiendung *.c oder *.cpp enden soll.

    main.c ist weniger Wert als ein odere mehrere Leben. Dein Vergleich ist kacke. Ich moechte gern mal wissen, was diese Kloanklage von dir soll. Du kannst auch gern mal darlegen, warum der Dateiname die Ausfuehrbarkeit einer Datei bestimmen soll und nicht deren Inhalt.

    Btw.: Ich liebe Trolle.



  • Katastrophe schrieb:

    5. die ersten paar Buchstaben nochmals der Quellcodedatei, weil man der Quellcodedatei eben einen aussagekräftigen Namen und nicht nur main.c spendiert hat. Bspw: zinsrechner.c

    Nö, die muss schon main.cpp heißen.

    Katastrophe schrieb:

    Und jetzt ab diesem Zeitpunkt besteht die große Gefahr dass die Katastrophe passiert.

    Man könnte sich ja auch eine Datei m erstellen mit "gcc main.c -o main" drin und immer mit ./m compilieren, spart ja auch Arbeit.

    Katastrophe schrieb:

    Es gibt auch nicht einen Grund, warum die Quelldatei genauso heißen soll, wie die Zieldatei. Das hat also absolut gar nichts mit PEBKAC zu tun, sondern das Design der Fehlervermeidung ist hier schlichtweg grottig umgesetzt.

    Stimmt auffallend.
    gcc main.c



  • Naja, der Name a.out ist schon selten dämlich.



  • Also... im Grunde hat er schon recht. Natürlich kann man alles mit "das Problem sitzt vor dem Bildschirm" begründen, aber wir befinden uns nicht mehr in den 80ern (auch wenn der GCC natürlich ein Kind der 80er ist).
    Möchte wissen, wie euer Chef reagieren würde, wenn ihr das als Antwort gebt, weil ein Kunde mal wieder euer Programm nicht so genutzt hat, wie ihr euch das vorstellt. Wenn man aufpassen muss, versehentlich keine dummen Sachen zu machen, die im Endeffekt wenig Sinn machen, dann sollte das _einmal_ im Programm verhindert werden, als dass sich jeder aufs neue eine entsprechende Lösung suchen muss.
    Und nein, der Verweis mit der Versionsverwaltung ist Unsinn, niemand checkt ununterbrochen ein.
    Nur weil man von Softwareentwicklern ein gewissen Maß technischen Verständnisses erwarten sollte, heisst das nicht, dass ich mir zu jedem Problem selbst eine Lösung ausdenken muss und will. Ich mein genau das wird doch bei der Programmierung immer propagiert: "Nutzt fertige Lösungen und erfindet das eckige Rad nicht neu!" Und solang niemand eine Notwendigkeit darin sieht, den Output *.cpp zu nennen, sollte die einmalige und funktionierende Lösung sein, dass der GCC darauf achtet.



  • Naja, dann mußte man auch einbauen, daß cp blockt, wenn man was in /bin/ überschreibt oder löscht.



  • rm -rf /

    😃



  • volkard schrieb:

    Naja, dann mußte man auch einbauen, daß cp blockt, wenn man was in /bin/ überschreibt oder löscht.

    Was soll

    cp blub.txt blub.txt
    

    schlimmes bewirken?
    Eine Kopie auf sich selbst?

    Und dein Beispiel ist Unsinn, weil cp gar nicht wissen kann, ob du in /bin etwas überschreiben willst. Bei gcc ist es aber eindeutig, das es Quatsch ist, den Quellcode mit dem compilierten Binärcode zu überschreiben.

    knivil schrieb:

    Du kannst auch gern mal darlegen, warum der Dateiname die Ausfuehrbarkeit einer Datei bestimmen soll und nicht deren Inhalt.

    Es ist nicht wichtig, ob der gcc eine Prüfung auf die Dateiendung macht. Wichtig wäre nur, dass er prüft ob der Name des Zielbinarys einem der Quellcodedateien entspricht.

    Das geht ganz grob mit einem einfachen

    while( i <= q_anzahl){
      if (zieldatei == quellcodedatei[i]){
        exit 1;
      }
      i++;
    }
    

    Da man mehrere Quellcodedateien angeben kann, müsste man da nur kurz durchiterieren.



  • Katastrophe schrieb:

    volkard schrieb:

    Naja, dann mußte man auch einbauen, daß cp blockt, wenn man was in /bin/ überschreibt oder löscht.

    Was soll

    cp blub.txt blub.txt
    

    schlimmes bewirken?
    Eine Kopie auf sich selbst?

    Und dein Beispiel ist Unsinn, weil cp gar nicht wissen kann, ob du in /bin etwas überschreiben willst. Bei gcc ist es aber eindeutig, das es Quatsch ist, den Quellcode mit dem compilierten Binärcode zu überschreiben.

    Er könnte sich das System zerschießen, wenn er aus /bin/ eine Datei löscht. Das muss doch verhindert werden! Wie bei Windows mit der Benutzerkontensteuerung. Kannst ja zum Compilieren eine Konsole unter anderem User aufmachen, der die Quellcode-Dateien nicht löschen kann. Wozu? Makefile oder IDE benutzen. Dein Problem ist gar kein reales. Oder einfacher:
    Ungeschickte User haben einfach keine Konsole zu benutzen.

    Katastrophe schrieb:

    knivil schrieb:

    Du kannst auch gern mal darlegen, warum der Dateiname die Ausfuehrbarkeit einer Datei bestimmen soll und nicht deren Inhalt.

    Es ist nicht wichtig, ob der gcc eine Prüfung auf die Dateiendung macht. Wichtig wäre nur, dass er prüft ob der Name des Zielbinarys einem der Quellcodedateien entspricht.

    Das geht ganz grob mit einem einfachen

    while( i <= q_anzahl){
      if (zieldatei == quellcodedatei[i]){
        exit 1;
      }
      i++;
    }
    

    Da man mehrere Quellcodedateien angeben kann, müsste man da nur kurz durchiterieren.

    Ungeschickte User haben einfach keine Konsole zu benutzen.



  • Du verstehst es einfach nicht, oder?

    Typisches OCPD Problem deinerseits.
    http://en.wikipedia.org/wiki/Obsessive–compulsive_personality_disorder


Anmelden zum Antworten