Der größte Bug des gcc ist folgendes

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?

mortified_penguin

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?

knivil

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.

volkard

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.

volkard

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.

volkard

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

Katastrophe schrieb:

Auch bist du mir immer noch eines Beweis schuldig geblieben, warum ein ausführbares Programm auf *.c oder *.cpp enden soll

Warum denn nicht? Wenn du willst, geb ich dir auch ein Beispiel: du hast ein altes Fortran-Programm nach C portiert, aber noch keine 100-prozentige Kompatibilität erreicht, weshalb das Fortran-Programm weiterhin unter altem Namen verfügbar sein soll. Experimentierfreudigen Nutzern/Kollegen willst du den C-Port aber trotzdem schon anbieten. Eine gängige Konvention, herauszustellen, dass es sich bei einer Binary um den C-Port des Programms handelt, ist das Voranstellen des Buchstaben c: aus 'prog' wird 'cprog'. Eine andere Konvention ist eben das Anhängen von '.c'. Habs selbst noch nie verwendet, aber schon gesehen. Ganz abgesehen davon hab ich es nicht gern, wenn Programme meinen mir in die Benennung meiner Dateien pfuschen zu müssen oder darauf bestehen, dass der Dateiname auf .irgendwas endet.

bzw. warum es genauso heißen können soll, wie die Quellcodedatei.

Das ist schon eher ein Punkt, aber auch hier muss ich sagen, dass alles andere einfach den Erwartungen eines Unix-Users widerspricht. Ein Unix-Programm macht genau das, was ihm gesagt wird. Manche Leute schätzen das. Andere nicht. Bei vielen Programmen gibt es die Möglichkeit eine Art interaktiven Modus zu aktivieren (siehe z.B. das i-Flag bei rm o.ä.), der vor dem Überschreiben/Entfernen von Daten nochmal nachfragt. Normalerweise ist sowas aber nicht Default or zumindest hinter einem isatty(3) gesichert, da es die Automatisierbarkeit einschränkt.

Wenn du Nachfragen willst, aktiviere eben so einen Modus (erstelle ein Shellalias). Gibts den bei GCC nicht, schreib dir halt einen kleinen Wrapper, der das macht. Sagst ja selbst, dass es trivial ist.

Katastrophe schrieb:

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?

gcc ist ein werkzeugt. nach deiner logik müsste werkzeug zum befestigen von steckdosen so gebaut werden, dass man damit die steckdose nicht kaputt machen kann.

Mr X

alleswashinktisteinvergle schrieb:

Katastrophe schrieb:

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?

gcc ist ein werkzeugt. nach deiner logik müsste werkzeug zum befestigen von steckdosen so gebaut werden, dass man damit die steckdose nicht kaputt machen kann.

Im Allgemeinen sollte das so sein. Bei einem Schraubenzieher wird eine solche Konstruktion sicher schwierig. Aber bei größerem/andere Gerät ist das durchaus wichtig. Oder würdest Du eine Spülmaschine kaufen, die 1% des Geschirrs zerdeppert?

Mr X schrieb:

alleswashinktisteinvergle schrieb:

Katastrophe schrieb:

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?

gcc ist ein werkzeugt. nach deiner logik müsste werkzeug zum befestigen von steckdosen so gebaut werden, dass man damit die steckdose nicht kaputt machen kann.

Im Allgemeinen sollte das so sein. Bei einem Schraubenzieher wird eine solche Konstruktion sicher schwierig. Aber bei größerem/andere Gerät ist das durchaus wichtig. Oder würdest Du eine Spülmaschine kaufen, die 1% des Geschirrs zerdeppert?

Soll das jetzt ernsthaft das gleiche sein?

ScottZhang

Also ich möchte mir vom gcc nicht vorschreiben lassen wie ich meine Dateien nennen zu habe und welche Dateien ich nicht überschreiben darf. Das ist auch überhaupt nicht die Aufgabe vom gcc. Verstehst du? Der gcc hat eine Aufgabe und nur die, für andere Aufgaben gibt es andere Programme, so einfach ist das.

Desweiteren möchte ich dezent auf meine Signatur hinweisen

Ich halte das auch für einen Bug. Du solltest das auf der entsprechenden mailing list ansprechen.

Gegen seine eigene Fehler oder Fehler in der toolchain sollte man sich aber trotzdem absichern. Auch bei kleinen, unbedeuteten Programmen oder Codeschnipseln, schließlich investiert man ja Zeit. Ein Editor, der in einer temporären Datei die Änderung seit dem letzten Speichern sichert und die zuletzt gespeicherte Version sichert ist ja schon ein großer Schritt nach vorne, wenn man nicht weiter automatisieren möchte. (per default erledigt das bspw. emacs so)

Leuten die heute noch keine IDE verwenden ist sowieso nicht mehr zu helfen.

Was hat eine IDE damit zu tun? Die könnte ebenfalls problematische Argumente an den Compiler weiterleiten und der Programmierer könnte nach wie vor problematische make files von der IDE anstoßen lassen.