theoretisch darf man auch sämtlichen code in eine zeile schreiben - muss man das dann als "korrektur" drunterschreiben und dann patzig reagieren wenn man gefragt wird was man damit sagen möchte?
Wozu Destruktor
07/21/2016 20:44
Dr. Coxxy#16
07/22/2016 15:26
Shadow992#17
Quote:
wat?
> int main(int argc, char** argv)
> return 0;
pls
Zu a)Quote:
a) es wurde im Beispielcode explizit system("pause") empfohlen (hier bin ich mir nicht sicher, ob dass wirklich Ziel der Nachricht / Kritik war),
b) "int main()" als Signatur des Einstiegspunktes reicht völlig aus, weil es standardkonform ist und auf argc und argv nicht zugegriffen wird und
c) "return 0" am Ende von main ist unnötig, weil das durch den Standard schon implizit gegeben ist.
Generell ist das sicher alles korrekt, wobei ich den Vorteil von b und c nicht erkennen kann, außer, dass die Source-Datei etwas weniger Bytes hat. Gut, bei b kann der Compiler noch Optimierungen machen, so dass argc / argv gar nicht vom Betriebssystem geholt werden muss, aber das halte ich eher für eine kleinere Optimierung und könnte sogar in der aktuellen Form geschehen, weil der Compiler "merkt", dass argc / argv nie benutzt werden.
Mit freundlichen Grüßen
Jeoni
Zu sagen "system" zu benutzen sei schlecht nur weil man damit "Schaden anrichten" kann, ist totaler Unfug. Das ganze "Wir machen alles so, dass der Benutzer nicht an seiner eigenen Dummheit stirbt"-Zeugs geht mir sowieso freundlich gesagt auf den Keks.
Genau so wie es mir auf den Sack geht, dass mir MSVC "Fehler" wirft, wenn ich "strcpy" benutze anstatt "strcpy_n"... Wenn ich mir sicher bin wie groß das Array maximal ist, warum zur Hölle soll ich dann gezwungen werden strcpy_n zu benutzen?
Natürlich kann man sagen: "Ja du bist dir vielleicht sicher, aber was ist mit den ganzen Anfängern/Leute, die weniger Ahnung haben?"
Das ist ein Argument, welches ich gar nicht abstreiten möchte, aber das dann als "Allheilmittel" anzupreisen ist einfach der falsche Weg. Viel besser is den Leute klar zu machen worauf sie achten müssen und wenn ihnen das zu viel ist oder sie sich darum nicht kümmern wollen, kann man immernoch "sicheren Code" empfehlen.
Aber zurück zum eigentlichen Problem:
Die "Hauptprobleme", die bei system auftreten können sind:
1. Du weißt nie ob der command in "system" ein valider command ist
2. Die commands funktionieren nicht auf allen OS gleich
3. Du kannst dir nicht sicher sein, ob dein Programm welches du ausführen möchtest wirklich auch das ist, was ausgeführt wird.
Zu 1. und 2. passt meine Erklärung von oben, solange man weiß was man tut, gibt es wenig Probleme.
Auch 3. ist nicht wirklich ein K.O. Kriterium, natürlich kann jemand die "notepad.exe" durch Malware o.ä. auf deinem System austauschen oder den Standard-Pfad für deine Bash/CMD umstellen.
Aber wenn das schon passiert ist, dann ist "system" sicher dein letztes Problem, weil keine Malware der Welt, wenn sie schon einmal Zugriff auf deine Hardware hat, wird "nur" den CMD-Pfad ändern...
Zu b) & c)
Ob da überhaupt Optimierung (von OS-Seite aus) stattfindet ist fraglich, denn zumindest unter Windows wird immer argv[0] mit dem Programmnamen gefüllt, welcher auch so viel ich weiß immer dem Programm übergeben wird.
Wenn man kein "return 0" am Ende schreibt kann es bei ein paar älteren Compiler-Kollegen schnell mal zu "[Warning] No return found" kommen. Abgesehen davon ist es manchmal besser konsitent zu programmieren und dafür ein paar Zeilen mehr Code zu investieren.
Wie @[Only registered and activated users can see links. Click Here To Register...] schon sagte, der Standard erlaubt viel und dennoch bleibt es am Ende Geschmackssache und über Geschmack lässt sich bekanntlich diskutieren...
07/22/2016 15:30
.Scy#18
dies trifft auch auf ubuntu zu, demnach nehme ich an, dass dies auf sogut wie allen linux plattformen genau so ist.Quote:
07/23/2016 17:35
MrSm!th#19
Dann tendiere ich zu "ziemlich dämlich". Ich habe einfach nur den Code des OPs übernommen und die Stelle korrigiert, die ich kritisiert habe. Die Kommentare stammen demnach nicht von mir. Und nirgendwo habe ich dort Anspruch auf ein Musterbeispiel für bestpractice C++ erhoben.Quote:
a) es wurde im Beispielcode explizit system("pause") empfohlen (hier bin ich mir nicht sicher, ob dass wirklich Ziel der Nachricht / Kritik war),
b) "int main()" als Signatur des Einstiegspunktes reicht völlig aus, weil es standardkonform ist und auf argc und argv nicht zugegriffen wird und
c) "return 0" am Ende von main ist unnötig, weil das durch den Standard schon implizit gegeben ist.
Generell ist das sicher alles korrekt, wobei ich den Vorteil von b und c nicht erkennen kann, außer, dass die Source-Datei etwas weniger Bytes hat. Gut, bei b kann der Compiler noch Optimierungen machen, so dass argc / argv gar nicht vom Betriebssystem geholt werden muss, aber das halte ich eher für eine kleinere Optimierung und könnte sogar in der aktuellen Form geschehen, weil der Compiler "merkt", dass argc / argv nie benutzt werden.
Mit freundlichen Grüßen
Jeoni
Das ist tbh ziemlicher Unsinn. Genau so entsteht unsicherer Code. Anfänger wissen nicht, wann etwas besser oder sicherer ist und das kannst du ihnen auch nicht mal eben vermitteln, das ist zu einem großen Teil Erfahrung. Genau deswegen ist eins der besten Lehrprinzipien: "Du sollst das niemals anwenden, das verursacht nur Probleme". Wenn die Person weit genug ist, um selbst einschätzen zu können, welche möglichen Konsequenzen die Anwendung von Funktion X hat und wie sie damit umzugehen hat, dann weiß sie auch selbst, dass dieser allgemeingültige Leitsatz doch nicht so allgemeingültig ist und bei Vorhandensein von triftigen Gründen übergangen werden kann.Quote:
Das ist ein Argument, welches ich gar nicht abstreiten möchte, aber das dann als "Allheilmittel" anzupreisen ist einfach der falsche Weg. Viel besser is den Leute klar zu machen worauf sie achten müssen und wenn ihnen das zu viel ist oder sie sich darum nicht kümmern wollen, kann man immernoch "sicheren Code" empfehlen.
Secure by default. Nur so funktioniert Sicherheit. Menschen gehen immer den einfachsten Weg, also gar nicht erst einfache, aber problematische Wege aufzeigen, bevor sie vernünftig selbst darüber urteilen können.
Es geht dabei weniger um Malware als darum, dass du unerwartete Ergebnisse erhalten könntest. Das ist gerade unter Unix ein Problem, wo für X verschiedene Distributionen diverse verschiedenste "Standard"pfade für bestimmte Binaries koexistieren. Und das zu debuggen ist dann auch nicht lustig.Quote:
Zu 1. und 2. passt meine Erklärung von oben, solange man weiß was man tut, gibt es wenig Probleme.
Auch 3. ist nicht wirklich ein K.O. Kriterium, natürlich kann jemand die "notepad.exe" durch Malware o.ä. auf deinem System austauschen oder den Standard-Pfad für deine Bash/CMD umstellen.
Aber wenn das schon passiert ist, dann ist "system" sicher dein letztes Problem, weil keine Malware der Welt, wenn sie schon einmal Zugriff auf deine Hardware hat, wird "nur" den CMD-Pfad ändern...