:rofl:
Ich vermute, copy-paste-Fehler. 
Sent from my iPhone using Tapatalk
fail. Aber jetzt hab ich endlich ein schönes Beispiel, das ich den PP-Studis zeigen kann, wenn sie wieder mal fragen warum ifs ohne Klammern uncool sind.
Ausgezeichnetes Beispiel aus der Praxis. Finde ich gut. 
Sent from my iPhone using Tapatalk
Wird auf derstandard.at berichtet:
http://derstandard.at/1392686067499/…cherheitsluecke
Weitere Vorgehensweisen, dieses Problem zu beheben, sind im Artikel beschrieben.
Von einer US-amerikanischen Sicherheitsbehörde:
http://web.nvd.nist.gov/view/vuln/deta…d=CVE-2014-1266
Habt ihr schon den Diff gesehen?
http://i.imgur.com/XIJlcxC.png
Wie kann man so einen Fehler bei dem Diff "zufällig" einbauen?
Das schaut auf den ersten Blick schon recht absichtlich aus. Andererseits braucht man nur ein bissl rummurksen (ala "oh da fehlt noch ein if, weil Fall xyz ist noch nicht abgedeckt *kopiert if mit fail hin* - ach, bin ich blöd.. steht ja eh da.. *löscht nur if aber das fail nicht mehr"). Wenn ich darane denke, was für abstruse Fehler mir teilweise schon unterlaufen sind.. 
Was mich viel mehr verstört ist, dass die scheinbar keinerlei automatische Tests drüber laufen haben lassen. Bei nem simplen Unit-Test hätte das doch schon failen müssen.. oO
Das mit den Unit Tests war auch mein erster Gedanke
evtl. verdrückt und unabsichtlich den Shortcut für aktuelle-Zeile-kopieren erwischt? (passiert mir öfters..)
Aber normalerweise schaut man sich den diff ja an bevor man committed...
und dass dieser Fehler so lange unentdeckt blieb... is auch komisch
bzgl: Unit Tests: vmtl habens eh welche, nur diesen Testfall habens halt vergessen
oder die NSA is an allem schuld
Hmm, das Ding ist überhaupt recht wild..
dachte zuerst: "na, wenn das eh in jedem Fall failed, dann dürfte ja zumindestens die Sicherheitslücke nicht entstehen".
Bis ich dann gesehen habe, dass das fail-label in jedem Fall durchlaufen wird.
Was von der Benennung hier etwas verwirrend ist.. und ja, man sieht ja wozu das dann führt...
wäre "fail" wirklich ein "fail", dann wäre dieses doppelte goto schneller aufgefallen.
Ja und er gibt ja err zurück und da err kein err ist, läuft es nicht schief 
Hab irgendwo mal bei den Comments gelesen, dass XCode keinen Shortcut für Zeile kopieren/einfügen hat. Auch wäre es unlogisch bei der Änderung diese Zeile anzunavigieren.
Sind "go to" Befehle wirklich so schlimm wie alle sagen? Da ich noch nichts mit C programmiert habe, hatte ich auch noch nichts mit go to zu tun. Die Leute scheinen schockiert zu sein, dass sowas (bei Apple) benutzt wird.
Sind "go to" Befehle wirklich so schlimm wie alle sagen?
Naja, darüber kann man wohl streiten.. der Programmfluss wird halt schwieriger überschaubar, wenn man wild umherspringt.
Zum Error-Handling wird es ja schon öfters mal noch verwendet.
Was in der Situation wohl die beste Lösung wäre?
Würde mich interessieren, was ihr dazu meint.
(abgesehen von {} IMMER verwenden )
- Die Variante mit den tausend verschachtelten ifs erhöht auch nicht unbedingt die Lesbarkeit.
- Im error case sofort returnen bricht diese "one way in, one way out"-Regel, hätte hier das cleanup-Problem und hätte nichts gerettet, wenn stattdessen das return doppelt dringewesen wäre.
- Return-Wert OK/NOK und Error-Number extra speichern hätte das Problem die Sicherheitslücke hier verhindert (wenn "return NOK" fälschlicherweise kopiert worden wäre).
Da ist halt dann wieder die Frage: einen zusätzlichen unschönen Parameter per Pointer mitgeben für den Error-Value? Oder die "get_last_error"-Variante die aber ihre Probleme mit Parallelität hat, und die Funktion recht "unpure" werden lassen würde (was z.B. für Parallelisierung nicht gerade förderlich wäre).
- Wenn man das goto beibehalten möchte: den eigenen Return Wert vom Return-Wert der aufgerufenen Funktionen trennen.
Also z.B. anfangs OK = 0 und dann direkt VOR dem fail-label OK = 1 nur dann wenn wirklich alles durchlaufen wurde. Der bissl eigenartige Fall ist dann halt, wenn OK und "err" dann nicht übereinstimmen.
- Return-Wert OK/NOK und Error-Number extra speichern hätte das Problem die Sicherheitslücke hier verhindert (wenn "return NOK" fälschlicherweise kopiert worden wäre).
Da ist halt dann wieder die Frage: einen zusätzlichen unschönen Parameter per Pointer mitgeben für den Error-Value? Oder die "get_last_error"-Variante die aber ihre Probleme mit Parallelität hat, und die Funktion recht "unpure" werden lassen würde (was z.B. für Parallelisierung nicht gerade förderlich wäre).
Das ist grundsätzlich der Weg, den ich bei "ähnlichen Problemen" gehe. Mag vllt. unschön sein, aber in Punkto Nachvollziehbarkeit sicher leichter zu finden und verstehen.
Was ist eigentlich der Unterschied zwischen goto xyz und xyz() als stinknormaler Methodenaufruf?
Sind "go to" Befehle wirklich so schlimm wie alle sagen?
Kommt drauf an wohin man springt. Vorwärtssprünge aus Schleifen oder Bedingungen hinaus (also sowas wie verallgemeinertes break) sind nicht so schlimm wie wenn du wild zurück und in Schleifen hinein springst.
Die Leute scheinen schockiert zu sein, dass sowas (bei Apple) benutzt wird.
Welche Leute? Dieses Idiom mit Sachen testen und wenn was schiefgeht zum clean up code am Ende der Funktion springen ist in der Systemprogrammierung recht akzeptiert. Der Python-Interpreter verwendets intern auch. Linux auch, glaub ich.
Was in der Situation wohl die beste Lösung wäre?
Würde mich interessieren, was ihr dazu meint.
[...]
- Die Variante mit den tausend verschachtelten ifs erhöht auch nicht unbedingt die Lesbarkeit.
Ein großes großes Oder hätte hier auch gereicht. Aber ja, das ist auch nicht unbedingt super.
In Wirklichkeit gehören die ganzen Überprüfungen hier in eine eigene Funktion ausgelagert. Nur geht dann etwas Kohäsion verloren. Verschachtelte Funktionen wären der Hit, gibts aber in C nicht.
Was ist eigentlich der Unterschied zwischen goto xyz und xyz() als stinknormaler Methodenaufruf?
Ein Aufruf schiebt die Rücksprungadresse auf den Stack, damit man zurückspringen kann. Bei goto ist das nicht vorgesehen.
Danke für die Aufklärung
Welche Leute?
Bekannte, Leute aus dem Standardforum und auch bei Stackoverflow hab ich einen Link gefunden, wo erklärt wird, dass gotos böse sind. (http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF)
Dieses Idiom mit Sachen testen und wenn was schiefgeht zum clean up code am Ende der Funktion springen ist in der Systemprogrammierung recht akzeptiert. Der Python-Interpreter verwendets intern auch. Linux auch, glaub ich.
Hängt dann vermutlich stark mit dem Anwendungszweck zusammen, obs gut oder böse ist. Wahrscheinlich wissen auch viele Leute gar nicht wo goto überall verwendet wird
Und das, Kinder, ist der Grund warum ihr immer geschwungene Klammern verwenden sollt.
tja, die frage ist ob man es auch tut. natürlich hab ichs in OSUE immer brav den studenten vorgebetet, aber privat hab ich bemerkt dass ich zusehends drauf verzichte... und dann gibt es natürlich auch noch coding guidelines die sagen man darf nicht klammern. linux kernel zb. openbsd (man style) läßt es offen.
Was mich viel mehr verstört ist, dass die scheinbar keinerlei automatische Tests drüber laufen haben lassen. Bei nem simplen Unit-Test hätte das doch schon failen müssen.. oO
A test case could have caught this, but it's difficult because it's so deep into the handshake. One needs to write a completely separate TLS stack, with lots of options for sending invalid handshakes.
[edit]zeit für ein neues t-shirt: http://teespring.com/goto-fail-goto-fail[/edit]
Hey, ich hab den Fred erst jetzt gesehen. Dankeschön für den Link, hehe. Zum Glück komm ich so gut wie nie dazu, goto zu verwenden. Und klammern tu ich eigentlich auch immer.
Und klammern tu ich eigentlich auch immer.
Hier könnte vielleicht ein Beziehungspsychologe weiterhelfen. #badPunDay #doILookLikeAnIdiotUsingHashtagsHereOhMyICertainlyDoSorry #EspeciallyIfTheForumAutoseperatesEm
