Das ist doch mal richtig elegant! Naja, und falsch, da wir nie „Hallo“ in „Hallo Welt!“ finden werden – zumindest nicht mit diesem Source. Viele werden jetzt sagen, dass da was fehlt: Ja, die explizite Typ-Pr\u00fcfung:<\/p>\n
if(false !== ($p = strpos($a,$b))) {\r\n echo \"Gefunden an Position $p.\";\r\n}<\/pre>\nDas w\u00e4ren dann aber auch gleich die schlimmsten Abarten verschiedenster Sprachen \u00fcbernommen: String-Indizierung von C, Weak-Typing und Inline-Assignments – zumindest wenn man sauberen Quelltext schreiben m\u00f6chte, ist solcher syntaktischer Zucker Gift. Aber das ist eine andere Geschichte. Genauso wie das Einf\u00fcgen von Variablen in geparste Strings. Die im obigen Beispiel bereits verwendete M\u00f6glichkeit, Variablen direkt in einen String einzubetten mag f\u00fcr einfache F\u00e4lle zwar ausreichen, verfehlt aber mindestens die M\u00f6glichkeit, Escaping gleich mit zu erledigen. Wer so seine Strings ausgibt hat zumindestens eine neue Stelle geschaffen, bei der unkontrolliert gef\u00e4hrliche Daten an die Welt gelangen k\u00f6nnten. Aber lassen wir das vorerst, da hier weniger die Art der Ausgabe, als vielmehr die \u00fcbergebenen Daten Schuld w\u00e4ren. Aber einwas sch\u00f6nes hat diese Syntax schon: Man kann auch direkt Arrays einbetten:<\/p>\n
$a = array(\"test\");\r\necho \"\\$a[0] = $a[0]\";<\/pre>\nSoweit klar. Aber wehe man will verschachtelte Arrays nutzen, denn dann liefert<\/p>\n
$a = array(array(\"test\"));\r\necho \"\\$a[0][0] = $a[0][0]\";<\/pre>\nnicht etwa die gew\u00fcnschte Ausgabe ‚$a[0][0] = test‘, sondern ‚Array[0]‘. Hups? Was ist da passiert? PHP parst Arrays in Strings zwar, jedoch nicht deren Verschachtelungen. M\u00f6chte man dies erreichen, muss man dies markieren:<\/p>\n
$a = array(array(\"test\"));\r\necho \"\\$a[0][0] = {$a[0][0]}\";<\/pre>\nDann kann man aber auch gleich \u00fcbertreiben:<\/p>\n
$a = array(array(0));\r\necho \"\\$a[0][0] = {$a[$a[0][0]][$a[0][0]]}\";<\/pre>\nGelle?<\/p>\n
Okay. Zugegebenerma\u00dfen ist die Variablen-Syntax innerhalb von Strings nicht ganz logisch. Die Ecken und Kanten von Heredoc und PHPDoc spare ich mir jetzt aber einmal – etwas so schlecht von Perl abgeschautes muss man nicht auch noch kommentieren. <\/p>\n
Von daher lassen wir das und schauen uns daf\u00fcr einmal Referenzen an. Referenzen sollen in PHP in etwa das erm\u00f6glichen, wof\u00fcr es in anderen Programmiersprachen Pointer gibt – nur halt etwas weniger gef\u00e4hrlich. Naja, eine Gefahr ist PHP ja bereits an sich, also brauch es der User nicht auch noch erweitern. Aber zur\u00fcck zu Referenzen. Was macht folgender Code?<\/p>\n
$a[] =& $a = array();<\/pre>\nJe nach PHP-Version entweder ein in sich rekursives Array erzeugen, oder ein Array, in dem ein rekursives Array anzutreffen ist. Halt je nach PHP-Version, aktueller Weltraum-Wetterlage und derzeitigem Ladestatus des beiliegenden Flux-Kompensators.<\/p>\n
Ach ja: Rekursive Arrays, da war ja noch was: wenn man Spa\u00df haben will, versucht man obiges Array einmal zu serialisieren. Dies wird einem von PHP mit dem Hinweis „Out of Memory“ oder „Stack Overflow“ (wieder je nach Weltraumwetterlage) quittiert. Korrekt w\u00e4re „a:{i:0;r:0;};“ Was? r ist noch niemandem aufgefallen beim Serialisieren? Vermutlich deshalb, weil unserialize Daten lesen kann, die serialize nicht einmal generieren kann – einmal ganz abgesehen davon, dass die Rekursions-Pr\u00fcfung zur Kreis-Erkennung im Serialisierungsgraphen fehlt…<\/p>\n
Witzig ist \u00fcbrigens auch die Abwandlung „a:{i:0;r:1;};“. Diese liefert nicht etwa einen Fehler wie „ung\u00fcltige Referenz“ zur\u00fcck, sondern erzeugt einfach ein neues Array, was dann in das bestehende eingeh\u00e4ngt wird (und in dem dann die korrekte Rekursion auf sich selbst stattfindet). Wobei Serialisierung, da war ja noch PHP 6 … Ja! Da soll das mit der Serialisierung, den __wakeup- und den __sleep-Methoden abgeschafft werden! Aber nicht ohne im gleichen Atemzug Serialisierung nach XML einzuf\u00fchren. Zumal __wakeup und __sleep ja gerade erst in der 5er Version eingef\u00fchrt wurden. Naja. War halt eine der Irrungen der Kindheit.<\/p>\n
Genauso kindlich, wie das Type-Hinting in PHP4. Ja, man konnte PHP4 sagen, welchen Datentyp man erwartet und sich dann eine Meldung generieren lassen, sollte dies nicht der Fall sein. Nunja, eben dieses Feature, was nur Basis-Typen in PHP4 und nur Klassen in PHP5 unterst\u00fctzt. Bessere Kompatibilit\u00e4t kann man gar nicht gew\u00e4hrleisten. Doch: Array geht in beiden Versionen! Wahrscheinlich ein Grund mehr, das in PHP6 endlich mal zu \u00e4ndern, damit wenigstens Type Hinting nicht mehr interoperabel ist. Aber gut: Daf\u00fcr l\u00e4sst sich das ja seit PHP5 \u00fcber einen Error Handler emulieren – wenn auch die Performance dabei arg in die Knie geht; aber was soll’s: Wir ham’s ja!<\/p>\n
Ja, wir haben es: Endlich sind sie da: Anonyme Funktionen! Zumindest f\u00fcr all jene, die PHP 5.3 einsetzen. Diese Funktion, die es endlich erlaubt, ohne mit create_function unkontrollierbare Speicherl\u00f6scher aufzurei\u00dfen, syntaktisch pr\u00fcfbare Quelltext-Bl\u00f6cke an der Stelle einzubauen, wo sie hingeh\u00f6ren. Wie? Was soll an create_function Speicherl\u00f6scher rei\u00dfen? Glaubt ihr nicht? Wohl noch keinen Code, wie folgendes Beispiel gesehen?<\/p>\n
$result = preg_replace_callback(\"\/a\/\", create_function(\"return 'b';\"), $text);<\/pre>\nM\u00f6glichst in einer Schleife, damit es sich auch lohnt \ud83d\ude09 Ja, sowas geht heute effizienter:<\/p>\n
$result = preg_replace_callback(\"\/a\/\", function($m) { return 'b'; }, $text);<\/pre>\nund da wir gerade dabei sind, f\u00fchren wir auch gleich noch Closures ein – und erg\u00e4nzen f\u00fcr den Spa\u00dffaktor gleich noch die n\u00e4chste Inkonsistenz:<\/p>\n
$answer = 0;\r\n$foo = function($bar) use (&$answer) { $answer = $bar; };\r\n$foo(42);\r\necho $answer;<\/pre>\nWas soll daran inkonsistent sein? Nunja … Passing By-Ref wurde eben erst deprecated. Ein Grund mehr, es bei Closures frisch neu einzuf\u00fchren. W\u00e4re ja sonst logisch…<\/p>\n
Wer’s nicht kennt: Pass-By-Ref ist das, was so undurchsichtig gehalten ist, dass es nicht nur auf jeder PHP-Version anders funktioniert, sondern zudem sogar noch unterschiedlich angefordert werden muss. Schrieb man also in PHP4 im Aufruf das & vor die Variable, so geh\u00f6rt es in PHP5 in die Parameterzeile – oder so. Und w\u00e4hrend PHP4 Objekte per Default kopiert, sorgt PHP5 bei Angabe des Referenz-Operators f\u00fcr das Kopieren. Ich habe nicht erst eine Klasse zwischen PHP4 und PHP5 umgeschrieben, weil sich dieses Verhalten grundlegend umgekehrt hat. Wenigstens darauf kann man sich verlassen …<\/p>\n
Eigentlich nicht mal darauf. Manche Fehler werden wenigstens konsequent fortgef\u00fchrt. Autoloading w\u00e4re da ein Beispiel. Wenn einmal ein Script eine __autoload-Methode enthalten hatte, konnte sich keine weitere Datei einen eigenen Autoloader leisten, au\u00dfer diese haben kooperiert. Dies mag f\u00fcr kleinere Skripte durchaus gehen, ben\u00f6tigt man jedoch ein oder mehrere Frameworks, so schie\u00dft man sich damit effektiv ins Knie. Also \u00e4rgenzen wir doch einfach einmal eine SPL-Bibliothek, die dieses Autoloading regelt. Nur gut, dass wir nun die H\u00e4lfte vergessen und man somit wieder f\u00fcr jede PHP-Version Sonderbehandlungen anstellen darf. Was aber wenigstens bleibt, ist die fehlende M\u00f6glichkeit, ohne Exception-Workarounds PHP darauf hinzuweisen, dass eine Klasse nicht geladen werden kann, ohne dass PHP gleich darauf durch diverse Speicherfehler wegschmiert. Dies ist die einzige Stelle, an der ich ernsthaft die Verwendung von eval ben\u00f6tige – was bei entsprechender Policy das Script zwar auch zum Absturz bringt, aber das w\u00fcrde es ja sowieso … Von daher ja kein Verlust!<\/p>\n
Apropro kein Verlust: schon jemand einmal versucht die Sicherheits-Funktionen von PHP verstanden? Ja, ich meine diese Kr\u00fccken, die wohl besser unter Black Magic h\u00e4tten bekannt gemacht werden sollen, statt sie Safe Mode und Magic Quotes zu nennen. Eben diese Kr\u00fccken haben extra erst daf\u00fcr gesorgt, dass hunderte von Anwendern erst recht richtige Sicherheitsl\u00fccken bei sich aufgerissen haben, weil durch das verworrene Verhalten dieser Funktionen alles M\u00f6gliche, nur nicht das vom Anwender spezifizierte Verhalten aufgezeigt haben. So geh\u00f6ren SQL-Statements escaped. Laut PHP mit einem Backslash – je nach DBMS aber mit was ganz anderem. Dabei wollen wir mal noch nicht darauf herumhacken, dass nicht einmal MySQL sich einig ist, was denn nun einen Backslash verdient. Wie soll das dann wohl PHP erraten. Ganz magisch halt, indem es einfach mal vor alles, was suspekt erscheint einen Backslash pflastert. Wer dann aus Versehen franz\u00f6sische Backticks und andere falsch escapete Unicode-Sonderzeichen seiner Eingabe spendiert, hat seinen Payload schon fast durchgebracht. Und da dieses Escaping nicht nur f\u00fcr Datenbank-Befehle operiert, sondern auch f\u00fcr eine Reihe anderer Kommandos verliert man schnell mal die \u00dcbersicht. Wenn man dann noch nicht einmal zuverl\u00e4ssig erkennen kann, ob dieses Escaping auch funktioniert, ist das Chaos perfekt.<\/p>\n
Die Open Basedir Restriction jetzt zu flamen liegt mir fern. Dieses Feature funktioniert zur Ausnahme ja \u00f6fters sogar mal. Zumindest meist dann, wenn man das Funktionieren gerade nicht gebrauchen kann. F\u00fcr den umgekehrten Fall gibt es cURL und diverse andere Bibliotheken, die diesen Schwachsinn nicht ganz so ernst nehmen.<\/p>\n
Wer also eine Sprache sucht, die in ihrem Design nicht einmal f\u00fcr Gewinner des IOCCC verst\u00e4ndlich wird, sollte sofort einen Blick auf PHP werfen. Komprimierter kann man Designfehler nicht zusammenfassen: Selbst Oracle ist gr\u00f6\u00dfer \ud83d\ude09<\/p>\n
![\"Flattr](\"http:\/\/blog.benny-baumann.de\/wp-content\/plugins\/flattr\/img\/flattr-badge-large.png\"){kind=icon}
<\/a><\/p>","protected":false},"excerpt":{"rendered":"