Superglobals are even more global than you might reasonably expect.
<?php function foo($_SERVER) { /* do nothing */ } foo('oh dear'); var_dump($_SERVER);
This is obviously unreasonable code, but I don’t think anyone would automatically expect that function call to replace the $_SERVER superglobal’s value with the string 'oh dear'.
string(7) "oh dear"
Hat tip to @mark_story.
Been a while. Have a simple one – what does this print?
$arr[null] = "Null string"; $arr[false] = "False string"; $arr[0] = "Zero string"; print_r($arr);
Okay, let’s say you managed to ensure that your program doesn’t exhaust the heap with anonymous functions, and that you understand the edge cases involved in function-type variables. There are still lots of ways for create_function to bite you in the glutes.
On Thursday, commenter Grumqa asked how PHP deals with the slow accumulation of functions if you call create_function.
It doesn’t.
Yesterday, I wrote about how $f() variable-function syntax works in PHP. While it is pretty bad, it’s also the groundwork for understanding the ways in which create_function is terrible.
No, I mean besides taking a string full of code as one of its arguments.
Early on in PHP’s life, its type system contained only strings, ints, reals, arrays, “resources,” and null. A number of features have been bodged in on top of this minimal system without really extending it. “Function pointer” functionality was one of the first.
I’m still sick, so you get another easy target today. It’s trivially easy to kill the PHP interpreter, dead, without invoking any extensions or unusual language features:
1 2 3 4 5 6 7 8 9 | < ?php function recurse($n) { if ($n <= 0) return; return recurse($n - 1); } recurse(100000); /* You may need to adjust this upwards. */ ?> |
It’s Monday, and I’m sick, so you get some low-hanging fruit today. The following snippet produces a syntax error in PHP:
1 2 3 4 5 6 7 | < ?php function monolithic_dimensions() { return array(1, 4, 9); } print monolithic_dimensions()[0]; // syntax error, unexpected '[' ?> |
Most modern languages have a construct that allows code to run at the end of a block regardless of how flow leaves a block. This allows code to reliably close resources, perform rollbacks, and otherwise maintain invariants relatively easily, even in the presence of exceptions.