Gefährlicher Compiler

Naja.
Geht besser, aber eher so mittel "gefährlich".

MaWin schrieb:
> Naja.
> Geht besser, aber eher so mittel "gefährlich".

Ja, man hat ja noch ein Backup und git, aber trotzdem, so etwas dürfte 
heutzutage doch nicht mehr bei einem Compiler möglich sein.

Ach ja:

1

clang --version

2

Debian clang version 11.0.1-2

3

Target: x86_64-pc-linux-gnu

4

Thread model: posix

5

InstalledDir: /usr/bin

Vielleicht trifft das bei neureren clang Versionen nicht mehr auf. Das 
weiß ich leider nicht. Habe hier nur Debian stable im Einsatz.

clang13 macht's auch (und zwar genau das, was verlangt wurde - einfach 
super, wie bei C).

bestellt - gelierfert schrieb:
> clang13 macht's auch (und zwar genau das, was verlangt wurde -
> einfach
> super, wie bei C).

Wo steht im C Standard drin, dass der Compiler nicht überprüfen soll, ob 
er die Quelldatei überschreibt?
Oder wo steht im C Standard drin, dass der Compiler die Quellcodedatei 
"optimieren" soll?

Rust und Gcc machen also nicht was der Benutzer verlangt? Dieser 
überbordende Paternalismus wird langsam tatsächlich gefährlich!

LG, Sebastian

Nano schrieb:
> Habe mal spaßeshalber folgendes getestet:

Offenkundig unter Linux.

Das kann so schicke Dinge wie 2 Namen für eine Datei.


Was passiert bei hardlink out.put auf test rs

ln test.rs out.put

und dann deinen Befehlen

rustc test.rs -o out.put

etc ?

Ich wollte neulich etwas Java lernen und bin schon beim package-Name und 
Verzeichnisstruktur gescheitert.

Anscheinend geht da mittlerweile ohne extra building tools gar nichts 
mehr.

Es sei denn man studiert vorher wie man diese Verzeichnisstruktur per 
Hand anlegt und was wo abgelegt werden soll. Einfach nur krank.

Nicht die Software führt die Befehle aus - du musst dich anpassen.

Jörg W. schrieb:
> Nano schrieb:
>> so etwas dürfte heutzutage doch nicht mehr bei einem Compiler möglich
>> sein.
>
> Warum zum Geier™ soll der Compiler für dich Mitdenken?

Weil ein Computer dem Menschen Arbeit abnehmen und menschliche Fehler 
vermeiden helfen soll.
Und weil es keinen einzigen triftigen Grund gibt, warum der Compiler so 
etwas nicht prüfen sollte.
Und auch Programmieraufwand ist kein Grund, da so eine Prüfung sehr 
schnell im Compiler implementiert ist.

> Spätestens, wenn du ein kaputtes Makefile (oder was auch immer dein
> Buildsystem ist) gezimmert hast und dann eben sowas baust wie
> cc -c foo.c
> cc -o foo.c foo.o
>
> könnte es der Compiler ohnehin nicht mehr direkt feststellen, das
> Ergebnis ist das gleiche Fiasko, wie du es beim Clang halt direkt
> bekommst. (Ähnliches habe ich selbst schon zur Genüge erlebt, eben, mit
> besagten verkorksten Makefiles.

Wenn das öfters vorkommt, dann sollte er halt auch prüfen ob das Output 
File auf *.c oder *.cpp endet. Es ist eine weltweit verbreitete 
Konvention, dass C oder C++ Quellcode auf die Dateinamenserweiterung *.c 
bzw. *.cpp und in seltenen Fällen auf *.cc, *.c++ oder *.cxx endet.

Fürs grobe reicht das vollkommen und der Build bleibt trotzdem 
performant genug.

Alternativ könnte man auch die ersten drei Zeilen parsen.
Der meiste C und C++ Code beginnt mit einer #include Anweisung oder 
einem Kommentar, gefolgt von einer #include Anweisung.

> Im Gegensatz dazu erscheint dein
> Beispiel als eher künstlich produzierter pathologischer Fall.)

Dank TAB Taste ist der auf gescheiten Betriebssystemen ganz einfach zu 
realisieren:

clang te<TAB> -o te<TAB><ENTER>

Das führt bei gegebener test.c Datei zu
clang test.c -o test.c

Zu schnell die <ENTER> Taste gedrückt und schon ist es um den Quellcode 
geschehen.

Und der Fall, dass man es mit Backspace korrigieren will und an die 
ENTER Taste zu früh rankommt, gibt es auch noch.

Nano schrieb:
> Und auch Programmieraufwand ist kein Grund, da so eine Prüfung sehr
> schnell im Compiler implementiert ist.

Warum baust Du es dann nicht schnell ein und schickst den Entwicklern 
ein diff, statt hier den nächsten Nano-Schwafelthread der Sorte "Ich 
hätte das viel besser gemacht!" aufzumachen?

Nano schrieb:
> Zu schnell die <ENTER> Taste gedrückt und schon ist es um den Quellcode
> geschehen.

Wie oft ist Dir das bisher passiert?

Hmmm schrieb:
> Nano schrieb:
>> Und auch Programmieraufwand ist kein Grund, da so eine Prüfung sehr
>> schnell im Compiler implementiert ist.
>
> Warum baust Du es dann nicht schnell ein und schickst den Entwicklern
> ein diff,

Ganz einfach, hast du dir schonmal den Rattenschwanz an 
Nutzungsbedingungen durchgelesen, nur damit du bei GitHub, wo LLVM und 
clang gehostet wird, einen Account erstellen und bei einem Open Source 
Projekt mitmachen kannst?

https://docs.github.com/en/site-policy/github-terms/github-terms-of-service

Also ich habe darauf keinen Bock. Deswegen kriegen von mir github (und 
gitlab Projekte, da ist es genauso schlimm) auch keine Bugreports mehr 
von mir.

> statt hier den nächsten Nano-Schwafelthread der Sorte "Ich
> hätte das viel besser gemacht!" aufzumachen?

Hmmm, du nimmst dich mal wieder zu wichtig. Du musst meine Threads ja 
nicht lesen.

> Nano schrieb:
>> Zu schnell die <ENTER> Taste gedrückt und schon ist es um den Quellcode
>> geschehen.
>
> Wie oft ist Dir das bisher passiert?

Du willst doch nicht Schwafeln, wozu fragst du also?

Warum macht man das so kompliziert?

Ich habe eine Datei xxx.c. Daraus soll ein Executable entstehen. Dann 
nehme ich einfach make:
# make xxx
cc     xxx.c   -o xxx

Keine Tab-Taste, kein -o usw
Und wenn ich mehr brauche, kann ich im Makefile eine Regel angeben.

Nano schrieb:
> Ganz einfach, hast du dir schonmal den Rattenschwanz
Nano schrieb:
> Ganz einfach, hast du dir schonmal den Rattenschwanz an
> Nutzungsbedingungen durchgelesen, nur damit du bei GitHub, wo LLVM und
> clang gehostet wird, einen Account erstellen und bei einem Open Source
> Projekt mitmachen kannst?

Über GitHub nehmen sie Patches gar nicht an, was ist deine nächste 
Ausrede?

Yalu X. schrieb:
> Das ist höchstens so gefährlich wie bspw.
>

1

> irgendein_kommando >test.c

2

>

> Das mit Clang ist mir noch nie passiert (dir offensichtlich auch nicht),
> die ungewollte Umleitung von stdout in eine bereits existierende Datei
> hingegen schon.
Falls es die ›bash‹ ist, da hätten wir noch ›noclobber‹ im Angebot. ;-)

MaWin schrieb:
> Was passiert bei hardlink out.put auf test rs
>
> ln test.rs out.put
>
> und dann deinen Befehlen
>
> rustc test.rs -o out.put
>
> etc ?

Den Fall kann man einfach abfangen indem man die Überprüfung mit der 
eindeutigen File-ID (Widows) macht, wie es ordentliche Programmierer 
eben so machen.

Ich bin mir nicht sicher, glaube aber das make den Fall auch erkennt,
wenn in jeder Regel nur ein Befehl drinnen ist.

Der Vollständigkeit halber:  der MS cl macht es wie clang.
Damit hatte ich aber noch nie Probleme.

Was mir aber schon mal passiert ist:

rm -rf /$(EMPTY_VARIABLE)

Zum Glück war das noch zu Zeiten, wo Festplatten langsam waren.

Aber richtig schlimm ist der Widows File Explorer:
File Markieren -> Rechte Maustaste -> "Umbenennen" ist gleich neben 
"Löschen".  Dafür vergebe ich 10 Liegestütz...

udok schrieb:
> Den Fall kann man einfach abfangen indem man die Überprüfung mit der
> eindeutigen File-ID (Widows) macht

Unter unix Systemen vergleicht man normalerweise device (st_dev) & inode 
(st_ino) Nummer mit stat(2). Device Nummer kann man nehmen, um zu 
checken, ob es auf dem selben Filesystem / Mountpoint ist, und jenachdem 
auch, von welchem Device es kommt usw. Die Inode Nummer ist sollte bei 
jeder Datei des selben device anders sein.

stat(2): https://linux.die.net/man/2/stat

udok schrieb:
> Den Fall kann man einfach abfangen

Natürlich, den mit gleichlautenden Filenamen auch, die Frage ist nur, ob 
es so gemacht wurde oder gar

source/test.c

als anders angesehen wird als

source/library/../zest.c

Sein Schweigen spricht Bände.

M.A. S. schrieb:
> Seit ich mir angewöhnt habe, Umbenennungen mit nur noch mit F2

Danke für den Tipp!

> It is not UNIX’s job to stop you from shooting your foot. If you so
> choose to do so, then it is UNIX’s job to deliver Mr. Bullet to Mr. Foot
> in the most efficient way it knows.
 – Terry Lambert

PittyJ schrieb:
> Warum macht man das so kompliziert?
>
> Ich habe eine Datei xxx.c. Daraus soll ein Executable entstehen. Dann
> nehme ich einfach make:
> # make xxx
> cc     xxx.c   -o xxx
>
> Keine Tab-Taste, kein -o usw
> Und wenn ich mehr brauche, kann ich im Makefile eine Regel angeben.

Wenn ich nur mal schnell was testen will, dann mach ich dafür keine IDE 
auf und lege dort auch kein neues Projekt an, sondern ich nehme einen 
Editor  und schreib die eine kurze Quellcodedatei damit und wenn ich 
dann damit fertig bin und das testen will, dann erstelle ich dafür auch 
nicht erst eine Makefile, denn es ist ja nur ein einzige Datei.
Deswegen gebe ich den Compilerbefehl in der Kommandozeile ein und nutze 
die Tab Taste und dann pass ich halt auf, dass ich die Outputdatei 
entsprechend anpasse. Überschrieben wurde bei mir noch nichts, das 
könnte aber auch daran liegen, dass ich bisher immer gcc für so etwas 
benutzt habe und der hilft diesen Fehler zu vermeiden, siehe oben.

Und sobald der Befehl in einer Konsole mal abgeschickt wurde, kann man 
ihn durch die History und Cursortasten ganz leicht wieder abrufen. 
Insofern ist ein Makefile da gar nicht nötig.

Aber natürlich nutze ich Makefiles bei richtigen Projekten, die bestehen 
aber auch nicht nur aus einer Quellcodedatei, sondern mehreren. Da macht 
der extra Aufwand für die Makefile bzw. Projektdatei in der IDE dann 
auch Sinn.

Jemand schrieb:
> Nano schrieb:
>> Ganz einfach, hast du dir schonmal den Rattenschwanz
> Nano schrieb:
>> Ganz einfach, hast du dir schonmal den Rattenschwanz an
>> Nutzungsbedingungen durchgelesen, nur damit du bei GitHub, wo LLVM und
>> clang gehostet wird, einen Account erstellen und bei einem Open Source
>> Projekt mitmachen kannst?
>
> Über GitHub nehmen sie Patches gar nicht an, was ist deine nächste
> Ausrede?

Es kann natürlich sein, dass jedes Projekt das anders handhabt. Und so 
genau guck ich mir die auf GitHub und GitLab gehosteten Projekte dann 
auch nicht an.

Fest steht aber, dass der Bugreport darüber läuft und da fängt es schon 
an.
Denn wenn man einen Patch einreicht, dann macht es Sinn, dass dafür 
bereits ein Bugreport existiert. Denn dann kann man schön schreiben 
"Here's a patch, this solves Bug #58237305".
Das erhöht die Wahrscheinlichkeit dass er gleich angenommen wird und in 
der Versionshistorie ist der Commit dann auch schön strukturiert 
hinterlegt, falls sich mal jemand fragen sollte, warum damals dieser 
Code dazu kam.
In Maillinglisten geht so etwas ja eher unter.

Yalu X. schrieb:
> Nano schrieb:
>> clang test.c -o test.c
>> # PENG!!!
>
> Das ist höchstens so gefährlich wie bspw.
>
>

1

> irgendein_kommando >test.c

2

>

Ich musste noch nie Code aus einer anderen Datei oder Ausgabe in eine 
Quellcodedatei schieben.

Ich mach das beim Überprüfen von Prüfsummen oder wenn ich die Dateien in 
einem Ordner mit zusätzlichen Informationen beschriften will und die 
Dateinamen dann in einer Textdatei brauche, in der ich die Informationen 
hinterlege, dann nutze ich aber immer den >> Operator.

Beispiel:
ls >> files.bbs
nano files.bbs

> Das mit Clang ist mir noch nie passiert (dir offensichtlich auch nicht),

Ja, ich habe bisher auch immer gcc benutzt.

> die ungewollte Umleitung von stdout in eine bereits existierende Datei
> hingegen schon.

Ja, könnte vorkommen, aber in meinem Fall ist es eher unwahrscheinlich, 
dass es in eine Quellcodedatei umgeleitet wird.


> Dann kommt der Nächste und schreibt
>
>

1

> clang test.c -o test.h

2

>

Das ist eher unwahrscheinlich, denn da ist ja ein zu tun erforderlich, 
also dass er nach dem Tab das c entfernt und ein h hinmacht.
Wenn er aber weiß, dass er eine Executable erstellen will, hängt er da 
eher bin, run oder exe dran oder macht es mitsamt . ganz weg.

> oder auch
>
>

1

> clang test.c -o wichtiges_dokument.docx

2

>

Das passiert höchstens Leuten, die keine Verzeichnisse benutzen und 
alles unstrukuriert im ~/ Ordner liegen haben.

Rolf M. schrieb:
> Nano schrieb:
>> Weil ein Computer dem Menschen Arbeit abnehmen und menschliche Fehler
>> vermeiden helfen soll.
>> Und weil es keinen einzigen triftigen Grund gibt, warum der Compiler so
>> etwas nicht prüfen sollte.
>
> Es gibt noch Millionen andere Fälle, mit denen man sich Daten
> zerschießen kann. Du hast jetzt wahlfrei einen davon rausgepickt. Will
> man die alle abfangen, bestehen die Programme irgendwann zu 95% aus
> solchen Überprüfungen.

Es hat schon seinen Grund, warum gcc, g++ und der Rust Compiler darauf 
achten.
Also ist das eben nicht ein Spezialfall, sondern halt schon etwas, was 
bei Nutzern vorkommt und somit problematisch sein kann.

Wäre doch mal interessant zu erfahren, wie es die Compiler von Intel, 
Microsoft und Co. machen.

Beim OpenWatcom Compiler habe ich es gerade unter FreeDOS überprüft.
Da überschreibt das wcl.exe das Compile and Link Utility die 
Quellcodedatei, wenn man diese mit -fe=DATEINAME also output Datei 
angibt.
Beim Compiler wcc.exe, der allerdings nur Objektcode erzeugt und das 
ganze noch nicht verlinkt, ist es genauso, wenn man mit -fo=DATEINAME 
angibt.

Unter FreeDOS ist das ganze aber dann doch sehr theoretisch, da man wcl 
auch einfach ohne output Datei starten kann und der Watcom Compiler 
automatisch die Quellcodedatei ohne Dateiendung als Namen für die 
Executable nimmt und noch ein .EXE dranhängt.

Beim Microsoft Compiler dürfte das ähnlich sein, denn unter Windows 
bekommen die Ausführbaren Dateien alle eine eigene Dateiendung. Im 
Normalfall also *.EXE.

Wirklich betroffen sind somit nur Unix und Linux Systeme, wo ein 
Programm jede beliebige Dateiendung annehmen kann.
Bei MacOS X weiß ich es nicht.

>> Wenn das öfters vorkommt, dann sollte er halt auch prüfen ob das Output
>> File auf *.c oder *.cpp endet.
>
> Wie du dein Output-File nennst, bleibt dir überlassen. Ich find's nicht
> gut, in der Software zu viele Dinge zu verbieten, von denen der
> Entwickler denkt, dass man sie nicht bräuchte.

In dem Fall ist es aber eindeutig.
Wenn man eine ausführbare Datei will, dann wird man die nicht *.c oder 
*.cpp nennen.

>> Es ist eine weltweit verbreitete Konvention, dass C oder C++ Quellcode
>> auf die Dateinamenserweiterung *.c bzw. *.cpp und in seltenen Fällen auf
>> *.cc, *.c++ oder *.cxx endet.
>
> Es gibt noch andere gebräuchliche Endungen. Bei gcc z.B.:
>

1

>        file.cc

2

>        file.cp

3

>        file.cxx

4

>        file.cpp

5

>        file.CPP

6

>        file.c++

7

>        file.C

8

>            C++ source code that must be preprocessed.

9

>

Da ist eigentlich nur noch cp dabei.
Die anderen habe ich schon aufgeführt und unterscheiden sich bestenfalls 
noch in der Groß- und Kleinschreibung.

>>> Im Gegensatz dazu erscheint dein
>>> Beispiel als eher künstlich produzierter pathologischer Fall.)
>>
>> Dank TAB Taste ist der auf gescheiten Betriebssystemen ganz einfach zu
>> realisieren:
>
> Mir ist das noch nie passert. Allerdings rufe ich den Compiler höchstens
> mal für eine kleines Testprogramm von Hand auf. Bei allem anderen nutze
> ich CMake und Konsorten.

Ich doch auch, aber ich mache von TAB ausgiebig Gebrauch wenn ich das 
von Hand mache.
Im Normalfall ändere ich somit immer die Dateiendung von Hand, da TAB 
immer in *.c endet, falls noch keine andere Datei, als die 
Quellcodedatei im Ordner vorhanden ist.
GCC schützt hier dann halt, clang würde es nicht tun.

Yalu X. schrieb:
> Norbert schrieb:
>> Falls es die ›bash‹ ist, da hätten wir noch ›noclobber‹ im Angebot. ;-)
>
> Ja, ich weiß. Ich wollte nur aufzeigen, dass es außer der Verwendung von
> Clang noch andere Möglichkeiten gibt, Dateien zu überschreiben, die
> weniger an den Haaren herbeigezogen sind.

Das Tabben ist ganz gewiss nicht an den Haaren herbeigezogen.

Die meisten Leute werden sich halt darauf einstellen und wenn sie den 
Fehler mal gemacht haben sollten, besser darauf acht geben. Die größte 
Gefahr liegt also  darin, es mal Ausversehen zu machen, weil man 
ungewollt an die ENTER Taste rankommt, während man eigentlich Backspace 
drücken wollte um die Dateiendung anzupassen.

Insofern ist das ein reales Szenario dass es passieren kann und da gcc, 
g++ und rustc das abfängt kann man stark davon ausgehen, dass es auch 
vorkommt.

udok schrieb:
> Der Vollständigkeit halber:  der MS cl macht es wie clang.
> Damit hatte ich aber noch nie Probleme.

Danke das ist gut zu wissen.

> Aber richtig schlimm ist der Widows File Explorer:
> File Markieren -> Rechte Maustaste -> "Umbenennen" ist gleich neben
> "Löschen".  Dafür vergebe ich 10 Liegestütz...

Unter Windows hast du ja den Papierkorb. Das sollte jetzt kein Problem 
sein.

Wilhelm M. schrieb:
> Du weißt aber schon, dass man, wenn man die default-rules von make
> verwenden kann / möchte, durchaus mit einem leeren / nicht-existenten
> makefile auskommt, oder? Keine IDE notwendig.

Natürlich weiß ich das, aber nochmal, warum soll ich für eine einzige 
Quellcodedatei eine Makefile anlegen?
Du weißt doch hoffentlich schon, dass Makefiles in der Regel dazu da 
sind, zu verhindern, das Code, der bereits compiliert und als Objektcode 
vorliegt nicht noch einmal zu compilieren, wenn er nicht verändert 
wurde.
Makefile haben somit bei nur einer Datei keinen Nutzen, ihr Nutzen 
ergibt sich erst bei mehreren Quellcodedateien.

Yalu X. schrieb:
> Nano schrieb:
>> Das ist eher unwahrscheinlich, denn da ist ja ein zu tun erforderlich,
>> also dass er nach dem Tab das c entfernt und ein h hinmacht.
>
> Also geht für dich die Gefahr nicht von Clang aus, sondern von der
> Tab-Completion. Diese kannst du deaktivieren, um der Gefahr aus dem Weg
> zu gehen.

Die Gefahr ist die Kombination aus beidem und natürlich werde ich die 
Tab Completion nicht deaktivieren, wenn sie einen wesentlichen Nutzen 
hat. Also dummer Vorschlag.



Damit ist nicht nur das von dir beschriebene "Problem" mit
> Clang beseitigt, sondern gleich auch alle anderen Probleme, die durch
> unkontrolliertes Tabben enstehen können, so bspw. beim Kommando
>
>

1

> rm test<tab>

2

>

>
> mit dem du eigentlich test.bin löschen möchtest. Wenn test.bin aber noch
> nicht oder nicht mehr existiert, wird der Dateiname zu test.c ergänzt,
> und weg ist deine Quelldatei. Ohne Tab-Completion wird dies nicht
> passieren.

Ich lösche aber nicht mit

1

rm test<tab>

sondern mit:

1

rm *.bin

Und da nutze ich kein Tab.

Wilhelm M. schrieb:
> Wenn es Dir doch nur um das Testen eines kleinen Beispiels geht (und Du
> ja auch sagst, dass Du Verzeichnisse benutzt ;-) Yeah!), dann schreib
> doch einfach:
>
>

1

> clang src1.cc src2.c

2

>

>
> Dann sparst Du Dir Tipp-Arbeit und der potentielle Fehler kann auch
> nicht auftreten.
>
> Das Ganze hier erscheint mir extrem konstruiert...

Es kommt bei mir auch mal vor, dass ich zum Vergleich noch eine weitere 
Testdatei schreibe.
a.out als Outpuddatei ist daher nicht die Lösung. Ich nutze immer -o um 
die Outputdatei festzulegen.

Wilhelm M. schrieb:
> Nano schrieb:
>> Wilhelm M. schrieb:
>>> Du weißt aber schon, dass man, wenn man die default-rules von make
>>> verwenden kann / möchte, durchaus mit einem leeren / nicht-existenten
>>> makefile auskommt, oder? Keine IDE notwendig.
>>
>> Natürlich weiß ich das, aber nochmal, warum soll ich für eine einzige
>> Quellcodedatei eine Makefile anlegen?
>
> Du hast es mal wieder nicht gelesen oder nix verstanden: OHNE makefile!

Ah, jetzt verstehe ich dich.
Das überschreibt dir dann den Quellcode.

1

$ ls

2

test.c

3

$ make

4

gcc -c test.c

5

gcc -o test.c test.o

6

$ ls

7

test.c  test.o 

8

$ file test.c 

9

test.c: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=f4ce5c42d61f5fcdbeb9da51cf23d1029b11bfcf, for GNU/Linux 3.2.0, not stripped

Also keinesfalls besser, sondern erst Recht ein Grund dem Compiler 
beizubringen, dass er Quellcodedateien nicht überschreiben soll.
Denn so ist das sogar bei gcc möglich, einfach in dem man das Makefile 
nicht anlegt und make angibt.

Wilhelm M. schrieb:
>> a.out als Outpuddatei ist daher nicht die Lösung. Ich nutze immer -o um
>> die Outputdatei festzulegen.
>
> Na, wenn Du das immer nutzt, dann ist ja hier jeglicher Kommentar
> nutzlos ;-)

???

Wilhelm M. schrieb:
> Nano schrieb:
>> Das überschreibt dir dann den Quellcode.
>
> Kann nicht sein, da hast Du wohl noch ein altes makefile rumliegen:
> $ make abc
> g++     abc.cc   -o abc

Oh ja, stimmt. Mein Fehler.
Das war noch wegen Jörgs Einwand #7084421 ganz oben.

Dennoch ist das für mich kein Lösung, da man so *.bin Dateien nicht 
bequem per
rm *.bin
löschen kann, sondern so jetzt explizit immer angeben müsste, was 
gelöscht werden soll.

Jetzt weißt du vielleicht auch, warum ich -o immer benutze und meine 
Executable selbst benenne, einschließlich der Dateiendung.
Weglassen würde ich die höchstens für einen Release der fertigen 
Software.

Nano schrieb:
> PittyJ schrieb:
>> Warum macht man das so kompliziert?
>>
>> Ich habe eine Datei xxx.c. Daraus soll ein Executable entstehen. Dann
>> nehme ich einfach make:
>> # make xxx
>> cc     xxx.c   -o xxx
>>
>> Keine Tab-Taste, kein -o usw
>> Und wenn ich mehr brauche, kann ich im Makefile eine Regel angeben.
>
> Wenn ich nur mal schnell was testen will, dann mach ich dafür keine IDE
> auf und lege dort auch kein neues Projekt an, sondern ich nehme einen
> Editor  und schreib die eine kurze Quellcodedatei damit und wenn ich
> dann damit fertig bin und das testen will, dann erstelle ich dafür auch
> nicht erst eine Makefile, denn es ist ja nur ein einzige Datei.
> Deswegen gebe ich den Compilerbefehl in der Kommandozeile ein und nutze
> die Tab Taste und dann pass ich halt auf, dass ich die Outputdatei
> entsprechend anpasse. Überschrieben wurde bei mir noch nichts, das
> könnte aber auch daran liegen, dass ich bisher immer gcc für so etwas
> benutzt habe und der hilft diesen Fehler zu vermeiden, siehe oben.
>


Hatte ich auch nicht. Kein Makefile, keine extra Regeln.
Ich hatte nur xxx.c angelegt, und auf der Kommandozeile 'make' 
eingegben.
Das war alles.

Wilhelm M. schrieb:
> Nano schrieb:
>> Jetzt weißt du vielleicht auch, warum ich -o immer benutze und meine
>> Executable selbst benenne, einschließlich der Dateiendung.
>
> Nee, erschließt sich mir überhaupt nicht.

Na weil ich dann alle Executables im Ordner mit einem einfachen
rm *.bin
wegräumen kann, ohne jede Datei einzeln eingeben zu müssen.

Ein einfaches
rm *
würde nämlich auch die Quellcodedateien löschen, was ja nicht immer 
gewünscht ist.

Deswegen kriegen Executables bei mir unter Linux immer die Dateiendung 
*.bin

Wilhelm M. schrieb:
> Nano schrieb:
>> Oh ja, stimmt. Mein Fehler.
>> Das war noch wegen Jörgs Einwand #7084421 ganz oben.
>
> Wer sich mit make auskennt (Deine Aussage oben), dem sollte das doch
> klar sein, dass das nicht sein kann.

Ich nutze make immer mit Makefile, nicht ohne. Und wenn doch, dann weil 
ich es vergessen habe, dann hänge ich da aber keine Quelldatei als 
Parameter hinten dran.
Und make ohne Target und ohne Makefile liefert die bekannte Meldung, 
dass es ohne Target nicht weiter weiß.

make quellcodedatei
ist für mich höchst unüblich. Vor allem wenn man noch zu mit TAB zu 
test.c Tabben würde und das .c noch wegmachen würde.

PittyJ schrieb:
> Hatte ich auch nicht. Kein Makefile, keine extra Regeln.
> Ich hatte nur xxx.c angelegt, und auf der Kommandozeile 'make'
> eingegben.
> Das war alles.

Das führt zu

1

make

2

make: *** Es wurden keine Ziele angegeben und keine „make“-Steuerdatei gefunden.  Schluss.

Man kann Kleinigkeiten auch künstlich hochsterilisieren.

+1 Post

man man man... also wenn das deine täglichen Probleme sind die du hast 
und lösen musst :D Hoffe du musst in deiner Software nie nach race 
conditions suchen.

Aber das kann dir ja nicht passieren ;)

Wünsche allen ein erholsame Pfingsten, Bug-Reports gehen da am ringsten.

Wilhelm M. schrieb:
> Beitrag "Re: Gefährlicher Compiler"

Das war schon am Anfang Schwachsinn und wird auch mit nochmaligem 
wiederholen nicht richtiger.

Yalu X. schrieb:
> @Nano:
> Du könntest auch einfach einen Wrapper in Form eines Shell-Skripts
> schreiben, das die Kommandozeilenargumente vor dem eigentlichen Aufruf
> von clang exakt nach deinen Vorstellungen prüft. Das sollte ja nicht
> allzu schwer sein.

Das ist mir schon klar, es geht hier aber ums Prinzip. Das Problem 
müsste bei clang gelöst werden.

Jörg W. schrieb:
> Wie du sehen kannst, war es übrigens ein Bugreport (PR = "problem
> report"), der den Einbau des Tests bewirkt hat. Ergo, solange du (da
> es dich ja stört) nichts tust, sind die Chancen gering, dass bei Clang
> irgendwer was von sich aus unternimmt.

Wie schon gesagt, solange man so viele Nutzungsbedingungen bei github 
durchlesen muss, nur um einen Bugreport zu posten, sollten die clang 
Maintainer erst einmal ein eigene Bugreportseite ohne diese Hürden 
aufmachen, dann kann ich auch Bugs reporten.

Jörg W. schrieb:
> wenn dir
> das Durchlesen von ein paar Richtlinien über die Einreichung von Bugs
> und Patches bereits dermaßen zu viel ist.

Bitte lies richtig, es geht nicht um Richtlinien wie man Bugs einreicht, 
sondern um so Sachen, was die mit deinen Daten machen dürfen, ob sie die 
an Drittfirmen weitergeben dürfen, ob du mit Werbung zugekleistert 
werden darfst, ob du deine Rechte an all dem abgibst, was du uploadest 
usw..

Sourceforge kriegt das mit wenigen Zeilen Text hin, bei github ist es 
mehr wie bei Steam.

Ergänzung:

Also alles Sachen, die ein Open Source Projekt nicht braucht, wenn es 
selber seine git und Bugreport Plattform hosten würde.

Und ja, es gibt Plattformen, die weniger invasiv sind. Gute Open Source 
Projekte hosten selber.


Aber lass mich raten, als du dich bei github registriert hast, hast du 
das ganze Zeug schlichtweg nicht gelesen und einfach unterschrieben.

Nano schrieb:
> Aber lass mich raten, als du dich bei github registriert hast, hast du
> das ganze Zeug schlichtweg nicht gelesen und einfach unterschrieben.

Für Menschen, die Probleme mit dem Lesen und Erfassen langer Texte 
haben, gibt es jeweils noch eine Kurzfassung.

Zum Thema Urheberrecht heisst es z.B.:

> Short version: You own content you create, but you allow us certain
> rights to it, so that we can display and share the content you post.
> You still have control over your content, and responsibility for it,
> and the rights you grant us are limited to those we need to provide
> the service. We have the right to remove content or close Accounts
> if we need to.

Aber Du wirst bestimmt noch weitere Ausreden finden, diesen "Bug" nicht 
einfach zu beheben. Alles ausser "Ich kann es nicht", das würdest Du 
niemals zugeben.

Hmmm schrieb:
> Alles ausser "Ich kann es nicht", das würdest Du
> niemals zugeben.

So etwas wäre ja auch eine Lüge.
Warum sollte ich also lügen?

Und selbst wenn ich dir solche Lügen auftischen würde, würdest du mir 
nicht glauben, weil es trivial ist, die Parameter von *argv[] zu 
vergleichen.
Ups, habe ich dir jetzt verraten, wie man das Problem löst, weil du es 
nicht wusstest?

Wilhelm M. schrieb:
> Mach nen fork des repos, bau Deine Traumlösung ein, fertig.

Mimimimi

Warum sollte ich das machen, dann müsste ich den Fork ja auch noch 
pflegen und alle Änderungen erneut einpflegen.

Dummer Vorschlag von dir.


> Und wenn Du ganz freundlich bist, erstelle eine Pull-Request. Oder sende
> Deine Patch ganz einfach an die ML. Und wenn er gut gemacht ist, wird er
> bestimmt angenommen werden.

Ich finde es ja schon interessant, das du und Hmm wollen, dass ich 
dieses Bug fixe. Könnte es vielleicht daran liegen dass euch dieser Bug 
am meisten stört?
Ich selbst nutze ja gcc und bin daher nicht davon betroffen, schon 
vergessen?

Und der Thread ist nur da, um diesen Missstand bei clang mal kurz 
anzusprechen und ihr beiden macht jetzt ein Theather drauß.

Wilhelm M. schrieb:
> Der Thread ist dazu da:
>
> Beitrag "Re: Gefährlicher Compiler"

Das ist wohl eher der Grund warum du hier so viele Nonsense-Kommentare 
schreibst um den Thread künstlich in die Länge zu ziehen.

Jörg W. schrieb:
> Nano schrieb:
>> ihr beiden macht jetzt ein Theather
>
> Nö, das Theater hast du angefangen.

Nein, ich habe nur über einen Bug berichtet.
Diese ganze Fragerrei und in die Länge ziehen kam von den beiden oben 
genannten und wie ich gerade sehe, auch von dir.

Ihr drei hättet es also nach den ersten 10 Kommentaren einfach damit 
belassen können, denn da war im Prinzip schon alles gesagt.

> Alle anderen hier interessiert dein Bug einen (vom Moderator zensiert).

Der Aufstand von euch drei und die ganze Fragerrei beweist das 
Gegenteil.

> "Ansprechen" kannst du natürlich viel, aber davon ändert sich rein gar
> nichts.

Und mehr habe ich auch nicht gemacht und mehr war auch nicht mein Ziel. 
Aber wenn ihr ständig nachfragt, gebe ich natürlich Antwort.

Nano schrieb:
> Nein, ich habe nur über einen Bug berichtet.

Ein Bug?
Wohl kaum.

MaWin schrieb:
> Ein Bug?
> Wohl kaum.

Netter Versuch.

MaWin macht also auch noch mit.

Leute, wenn wir, also Wilhelm M., Hmmm, Jörg W., MaWin und ich früher 
zusammen im Sandkasten gespielt hätten, dann wäre das bestimmt eine 
riesen Gaudi geworden. :p

Nano schrieb:
> Netter Versuch.

Nicht jedes Verhalten, was dir nicht gefällt, ist ein Bug.

Wilhelm M. schrieb:
> https://github.com/nvbn/thefuck
>
> (hilft in diesem speziellen Fall natürlich auch nicht, trotzdem ganz
> lustig)

Brauchst halt für die Shell nen Befehl, der den vorherigen Befehl 
rückgängig macht.

Also so ne Art multiple undo/redo Funktion, wie bei einem Texteditor.

Das wäre doch mal.

1

rm 10TB_hdimage.img

2

fuck++

3

ls

4

10TB_hdimage.img

:)

Yalu X. schrieb:
> Jetzt würde mich doch mal ganz brennend interessieren, wie viele KLOC
> oder gar MLOC du durch den vermeintlichen Clang-Bug verloren hast, dass
> du deswegen so einen Aufstand machen musst ;-)

Außer einem für das erste Posting erstellten kurzen Testcode bestehend 
aus einem einfachen:
<c>
#include <stdio.h>

int main(){
  printf("Hallo\n");
  return 0;
}
</c>

keinen.

Wie schon gesagt nutze ich gcc und bei ernsthaften Projekten habe ich 
ohnehin Makefiles und Projektdateien.

Moin, -

wenn man ein richtiges Betriebssystem benutzt, gibt es noch mehr 
Moeglichkeiten:

1

$ type hello.c

2

#include <stdio>

3

4

int main(){

5

  printf("Hallo World\r\n");

6

  return 0;

7

}

Compile und Link:

1

$ cc/version

2

Compaq C V6.4-005 on OpenVMS VAX V7.3

3

$ cc hello.c

4

$ link hello.obj/exec=hello.c

Der Linker erstellt das Exec mit dem Namen hello.c, ausfuehren geht 
latuernich:

1

$ run hello.c

2

Hallo World

Aber OpenVMS hat Versionen:

1

$ dir /size

2

3

Directory USER$DISK:[TOM.TMP]

4

5

HELLO.C;2                  4

6

HELLO.C;1                  1

7

HELLO.EXE;1                4

8

HELLO.OBJ;3                1

9

Total of 4 files, 10 blocks.

Das hello.c mit der Version-nummer 2 ist das Executable. Meinen Source 
koennte ich mit einem freundlichen

1

purge/log

loeschen.

Die Versionierung bei OpenVMS hatte mich schon oft gerettet, ist aber 
bei Microsoft-Produkten oder bei Linux nicht angekommen (es gibt eine 
Kruecke bei emacs, das ist aber eine Kruecke).

Genug erzaehlt von der guten alten Zeit[TM].

Gruesse

Th.

Kommandozeilen-History ist doch nur fuer Leute die immer die Tasten auf 
der Tastatur gesucht haben.

Aber Du hast schon recht, heute sind einige Sachen einfacher. Und vor 
allen Dingen kann man mit relativ wenig Aufwand alte Rechner simulieren 
(http://simh.trailing-edge.com/), daher habe ich eine Vax mit 
Gigabit-Anschluss (die spielen aber auch zusammen mit den realen 
10-MBit-Geraeten).

bis denne

Th.

Thomas W. schrieb:
> Die Versionierung bei OpenVMS hatte mich schon oft gerettet, ist aber
> bei Microsoft-Produkten oder bei Linux nicht angekommen (es gibt eine
> Kruecke bei emacs, das ist aber eine Kruecke).

Das Versionsierungsfeature würde mir gefallen.
Gab es Pläne das mal nach Linux zu portieren und falls ja, was ist 
daraus geworden?
Was sagte Linus Trovald und sonstige wichtige Kernelentwickler dazu?

Thomas W. schrieb:
> Kommandozeilen-History ist doch nur fuer Leute die immer die Tasten auf
> der Tastatur gesucht haben.

Also ich finde meine Tasten auf der Tastatur auch im dunkeln, aber finde 
die Kommandozeilenhistory unglaublich praktisch, da sie einem die 
Tipparbeit abnimmt, zuvor eingegebenes nochmal einzutippen.
Warum sollte man 100 Zeichen eintippen (z.b. bei tiefen Verzeichnissen 
mit aussagekräftigen Namen), wenn es mit bspw. 3 Tastenanschlägen auch 
getan wäre?

Was für eine schöne Doku völlig außer Rand und Band geratener 
Programmierwerkzeuge! Die Lücken die das eine reißt muß das nächste 
schließen usw. usf. Krebsartig wuchernde Sprachbürokratie ohne Ende.

Nano schrieb:
> Thomas W. schrieb:
>> Kommandozeilen-History ist doch nur fuer Leute die immer die Tasten auf
>> der Tastatur gesucht haben.
>
> Also ich finde meine Tasten auf der Tastatur auch im dunkeln, aber finde

Ctrl-B (oder Up Arrow) hat OpenVMS auch (20 Kommandos bei der VAX).

Gruesse

Th.

Nano schrieb:
> Thomas W. schrieb:
>> Die Versionierung bei OpenVMS hatte mich schon oft gerettet, ist aber
>
> Das Versionsierungsfeature würde mir gefallen.
> Gab es Pläne das mal nach Linux zu portieren und falls ja, was ist
> daraus geworden?
> Was sagte Linus Trovald und sonstige wichtige Kernelentwickler dazu?

Da es sich im wesentlichen ein Filesystem-Feature ist: Nichts.

Wenn Du ein wenig Interesse hast: Es gibt ein Wikipedia-Artikel ueber 
das Filesystem (Files-11, https://en.wikipedia.org/wiki/Files-11) der 
technisch genug ist um die Konzepte zu verstehen. Wenn Du mehr wissen 
willst, kannst Du  Dich mit der "gray Wall" auseinander setzen 
(https://commons.wikimedia.org/wiki/File:Vax-vms-grey-wall.jpg).

Gruesse

Th.

Thomas W. schrieb:
> Wenn Du ein wenig Interesse hast: Es gibt ein Wikipedia-Artikel ueber
> das Filesystem (Files-11, https://en.wikipedia.org/wiki/Files-11) der
> technisch genug ist um die Konzepte zu verstehen.

Besten Dank.
Ich werde das mal durchlesen.

Jörg W. (dl8dtl) (Moderator) schrub
> Kommandos, denn schließlich hatte eine Disk damals nur 4800 Blöcke, also
> 2400 KiB.  Ja, KiB, nicht MiB …

Google "KiB"

Kib
Kíb
Substantiv, maskulin [der]landschaftlich

    1.
    Zorn
    2.
    Gezänk

Google "KB"

kB, KB
Abkürzung

    Kilobyte

------

Ich weiß nicht ob's an meinem Alter liegt, aber ich kann mich an "KiB" 
genauso wenig wie Google gewöhnen. Gute alte Zeit.

;)

PS: Habt ihr eigentlich keine anderen Probleme?

ach egal schrieb:
> Google "KiB"

Also zum eigentlichen Thema: vermutlich ist es ein Bug ist, aber wie 
groß ist dessen Relevanz? Wenn das ding seit Urzeiten im Clang drin ist, 
und noch keiner danach gekräht hat bis jetzt, scheint die Notwendigkeit 
ja nicht so hoch zu sein... ^^

Aber zurück zur Technik:

Guck dir mal Automake/Autoconf und Gedönse an, was die mit ihrem 
./configure-Scripts erstmal abkläppern... da wird geguckt, was die libc 
bei welchen Funktionen macht, ob der Compiler dies und das und jenes 
kann usw. usf. -> um Eigenschaften von Compilern, Binutils, Shells usw. 
zu abstrahieren, wurde ja sowas wie Automake/Autoconf bzw. CMake 
überhaupt erschaffen.

Soll heißen, lieber fix nen kleines CMake-Projekt aufgesetzt und fertsch 
ist die Laube.


Sicher, für reine Makefile-Projekte mag es schon ärgerlich sein, wenn 
was kaputt geht. Ist aber auch ne Frage, wie bzw. ob man 
Schreib/Lesezugriffe im Folder zulassen will. Was ich meine:

Bei CMake wird auch zu Out-Of-Source-Builds mit separatem Verzeichnis 
geraten, was man btw. spätestens dann machen sollte, wenn man (a) die 
selben Sourcen für unterschiedliche Ziele bauen will (Debug/Release, 
oder x86,x64,arm) oder (b) seinen Source-Ordner sauber halben will, ohne 
sich den Aufwand großer Makefile-Magie machen zu müssen (-> einfach 
Buildfolder löschen). Das Thema VCS als Absicherung gegen versehentliche 
Änderungen wurde ja schon genannt.

Abgesehen davon hast du, wie auch schon genannt, selbst wenn der 
Compiler  perfekt das fehlerhafte Argument erkennt, nen Buildfehler 
drin. Praktisch gesehen also gehupft wie gesprungen, ob der Buildfehler 
nun hier oder da passiert. Besser erkennbar würden solche Fehler durch 
besseres Argumentparsing - mehr aber auch nicht.

Nano schrieb:
> Mehr muss ich dazu nicht sagen, oder?
>
> Und seit wann gibt es clang? Sind doch jetzt schon sicher ein paar
> Jahre.

Wo ist denn das Problem? Der Compiler macht was ihm gesagt wird.
Klar ist es schön, wenn der Compiler mitdenkt, aber darauf würde ich 
mich nicht verlassen.