Der größte Bug des gcc ist folgendes

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.

Es gibt übrigens auch einen Bug report dazu: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36312

volkard

Katastrophe schrieb:

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.

Lass das Projekt mal mit ma anfangfen (main.c main, wie von Dir vorgeschlagen), dann passiert Die mit fast gleichem Vorgehen, daß der gcc Dein wunderbares makefile kaputtschreibt.
Jetzt ist make buggy, nicht mehr gcc. Hmm, ob wir überall in jedes Programm Daukontrollen einbauen müssen? Das würde mich ehrlich stören. Davon wird Software nur fett, lahm und unwartbar.

Du beschreibst hier aber einen anderen Fall. Es macht einen Unterschied, ob ein übergebenes source file oder ein belibeiges (wie ein make file) überschrieben wird.

volkard

asdfasdf schrieb:

Du beschreibst hier aber einen anderen Fall. Es macht einen Unterschied, ob ein übergebenes source file oder ein belibeiges (wie ein make file) überschrieben wird.

Ich halte das "Problem" für zu irrelevant. Das kommt praktisch nicht vor. Mag nicht sehen, daß jemand diese doch recht nutzlose for/if einbaut, das dann eh nicht ausreicht, sondern nur die Hälfte der Fälle abdeckt wegen nichtkanonischer Pfade, symlinks, mounts

Ich stimme dir zu. Aber als reine DAU-Kontrolle würde ich eine Änderung in diesem konkreten Fall dennoch nicht sehen.

PS: clang verhält sich gleich.

asdfasdf schrieb:

Es gibt übrigens auch einen Bug report dazu: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36312

Danke, der Bugreport beweist, dass dies öfters vorkommt und auch schon andere diese Erfahrung machen durften.

Es ist bedauerlich, dass dieser Bug schon seit 2008 gemeldet wurde und sich bis heute nichts getan hat.

Das ist ne Chance sogar für Programmieranfänger endlich mal in den Credits des gcc zu stehen.

Und diejenigen die gegen so eine Prüfung der Zieldatei sind, die sollten mal bei ihrem Editor die Prüfung entfernen, ob die Datei beim beendet noch schnell gespeichert werden soll. Das fragt nämlich jeder gute Editor nach, aber die Leute hier, die scheinen so etwas nicht zu brauchen, also entfernt das!

volkard

Katastrophe schrieb:

Und diejenigen die gegen so eine Prüfung der Zieldatei sind, die sollten mal bei ihrem Editor die Prüfung entfernen, ob die Datei beim beendet noch schnell gespeichert werden soll. Das fragt nämlich jeder gute Editor nach, aber die Leute hier, die scheinen so etwas nicht zu brauchen, also entfernt das!

ABspecihern vergessen, kam mir schon öfters vor.
Aber Dein Bedienfehler echt noch nie.

camper

Ist doch trivial, einen wrapper um gcc zu verwenden, wenn man sich gegen so etwas absichern will.

volkard schrieb:

ABspecihern vergessen, kam mir schon öfters vor.

Tja, ein typischer Fall von PEBKAC.
Das Problem sitzt zwischen Stuhl und Bildschirm, so etwas vergisst man nicht und wenn man es vergisst, dann sollte man vielleicht doch lieber gänzlich die Finger von Computern lassen. Das weiß man doch.

volkard

Katastrophe schrieb:

volkard schrieb:

ABspecihern vergessen, kam mir schon öfters vor.

Tja, ein typischer Fall von PEBKAC.
Das Problem sitzt zwischen Stuhl und Bildschirm, so etwas vergisst man nicht und wenn man es vergisst, dann sollte man vielleicht doch lieber gänzlich die Finger von Computern lassen. Das weiß man doch.

Du darfst jetzt drüber nachdenken, wie man Abspeichern vergessen kann, denn alle Editoren fragen ja nach, wenn man sie schließt.

Immer in dem Moment, in dem so eine Meldung aufpoppt.
Diese sagt nämlich auch aus, dass du es manuell nicht gemacht und vergessen hast.
Hast du es manuell gemacht, dann poppt da bei guten Editoren nämlich nichts auf.

Das manuelle nicht speichern zeigt nämlich auch, dass du die Daten seit der letzten Änderung auch dann verlieren könntest, wenn der Rechner einfach abstürzt.
Wie weit dein letzter manueller Speichervorgang zurückliegt ist also auch ein Maß für deine Vergesslichkeit.

Katastrophe schrieb:

dass du die Daten seit der letzten Änderung auch dann verlieren könntest,

Korrektur:
Seit der letzten Speicherung.