Apple-Bug
-
-
Nice.
D.h. sie haben entweder NICHT "treat warnings as errors" an, ODER sie haben die "unreachable code" Warning unterdrückt.
(Mal vorausgesetzt dass der eingesetzte Compiler überhaupt "unreachable code" Warnings erzeugt, aber davon gehe ich mal aus.)
-
hustbaer schrieb:
Nice.
D.h. sie haben entweder NICHT "treat warnings as errors" an, ODER sie haben die "unreachable code" Warning unterdrückt.
(Mal vorausgesetzt dass der eingesetzte Compiler überhaupt "unreachable code" Warnings erzeugt, aber davon gehe ich mal aus.)Die Entwicklungsumgebung von Apple ist ca 10 Jahre hinter dem Stand der Technik zurück. Mit XCode zu arbeiten ist für mich immer wie eine Zeitreise zu "wie es früher mal war", nur im negativen Sinn. Für XCode ist es "normal" das es ein paarmal am Tag crashed, so normal das es ein Auto-Restart-Feature hat.
Von daher wundert mich bei denen nichts...
-
hustbaer schrieb:
Nice.
D.h. sie haben entweder NICHT "treat warnings as errors" an, ODER sie haben die "unreachable code" Warning unterdrückt.gccs unreachable code switch macht exakt gar nichts.
//edit und clang hat die Warnung by default nicht an(und -Wall hat sie nicht drin).
-
über code richtlinien kann man denken was man will - in dem fall wäre eine davon aber sinnvoll gewesen:
blöcke immer mit { anfangen und mit } beenden.if(blablabla) { goto fail; } goto fail;fällt jedenfalls mehr ins auge als
if(blablabla) goto fail; goto fail;ansonsten kann ich dazu nur eines sagen:
irren ist menschlich. dass sogenannte "technik blogs" sich über den fehler geradezu stürzen, ist typisch: der fehler ist für jeden laien sichtbar. jeder stellt sich die frage wie so etwas in einem professionellem umfeld nur passieren konnte usw...die wahrheit ist, dass wohl jeder, der über jahre SW entwickelt, schon fehler gemacht hat. immer wieder auch fehler, die wirklich sofort auffallen sollten, aber eben nicht aufgefallen sind. weil es gerade schnell gehen musste, weil man den wald vor lauter bäumen nicht gesehen hat, ...
hat man den fehler dann erstmal entdeckt (nach tagelanger suche), dann ist es oft wirklich nur eine kleinigkeit, teilweise nur ein einziges falsches zeichen.
aber dieses eine falsche zeichen zu finden, das kann harte arbeit sein.
-
goto fail schrieb:
[...]die wahrheit ist, dass wohl jeder, der über jahre SW entwickelt, schon fehler gemacht hat.
Und _weil_ das die Wahrheit ist sollte man von einem professionellen Entwicklungsteam erwarten das zumindest die sicherheitsrelevanten Codeteile durch umfangreiche Unit-Tests abgesichert sind die automatisch bei jedem Check-In laufen.
Der goto-bug von Apple belegt eindeutig das solche Unit-Tests nicht existieren. (denn alle Unit-Tests die den Code nach dem goto testen müssten ja fehlschlagen) Das ist grob fahrlässig und der Spott ist verdient.
-
loks schrieb:
Und _weil_ das die Wahrheit ist sollte man von einem professionellen Entwicklungsteam erwarten das zumindest die sicherheitsrelevanten Codeteile durch umfangreiche Unit-Tests abgesichert sind die automatisch bei jedem Check-In laufen.
Hehe, der war gut. Wenn dem so wäre, gäbe es viel weniger Bugs. Der meiste Code da draußen wird nach wie vor nicht automatisiert getestet; auch sicherheitskritischer Code. Sieh dir doch die GnuTLS-Sicherheitslöcher letztens an; die waren noch ein ganzes Stück schlimmer.
Der goto-bug von Apple belegt eindeutig das solche Unit-Tests nicht existieren. (denn alle Unit-Tests die den Code nach dem goto testen müssten ja fehlschlagen) Das ist grob fahrlässig und der Spott ist verdient.
Oder die Tests waren einfach nicht umfangreich genug; alles möglich.
Der Fehler sieht für mich nach einem Merge aus, bei dem irgendwas schiefgelaufen ist. Kaputte Merge-Resolutions werden bei Code-Reviews leicht übersehen, ist mir auch schon etliche Male passiert. (Und ja, ich teste meinen Code exzessiv automatisiert.)
-
Die eigentliche Moral von beiden Geschichten ist:
Nutz kein goto!
-
Nathan schrieb:
Die eigentliche Moral von beiden Geschichten ist:
Nutz kein goto!Das wäre zu einfach.
