<?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.

$arr[null] = "Null string";
$arr[false] = "False string";
$arr[0] = "Zero string";
 
print_r($arr);

It’s…

Array ( [] => Null string [0] => Zero string )

Surprise!

It gets better:

$arr[null] = "Null string";
$arr[false] = "False string";
$arr[0] = "Zero string";
$arr[''] = "Empty string string";

gives

Array ( [] => Empty string string [0] => Zero string )

Hat tip to Will for this one.

The program argument to create_function is a string. This has two immediate knock-on effects that can really ruin your afternoon.

One: create_function’s arguments are strings, which means they’re invisible to any syntax highlighting, code navigation, or refactoring features you might be using to help make sense of the code. Any attempt to implement these properly for create_function will be heuristic at best.

Two: create_function’s arguments are strings, which means they interact with PHP’s string interpolation rules. The following program has a very subtle bug:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<?php
 
$axes = array(1, 2, 3, 4);
$dimensions = array_map(
    create_function(
      "$x",
      "return $x * $x;"
    ),
    $axes
);
 
/* Prints several errors and then nothing (FALSE); should print 1 (TRUE) */
print_r($dimensions == array(1, 4, 9, 16));
 
?>

Can you see it? Here’s the fixed version:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<?php
 
$axes = array(1, 2, 3, 4);
$dimensions = array_map(
    create_function(
      '$x',
      'return $x * $x;'
    ),
    $axes
);
 
/* Prints 1 (TRUE) */
print_r($dimensions == array(1, 4, 9, 16));
 
?>

The PHP developers do think this is a problem: this is one of the motivations for the PHP closures RFC.

It doesn’t.

<?php
for ($i = 0; $i < 100000; $i++)
    create_function("", "return 0;");
?>

This script fairly reliably kills the interpreter with the message “Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 40 bytes) …”. You can postpone it by increasing PHP’s memory limit, but if you call create_function an arbitrary number of times, eventually you will murder the interpreter. The only safe way to use create_function is by ensuring you only call it a bounded number of times, and at that point, why not use a normal function and be done with it?

Naturally, the PHP team doesn’t think this is a problem.

No, I mean besides taking a string full of code as one of its arguments.

Consider this contrived example:

1
2
3
4
5
6
7
8
9
10
11

<?php
$input = array(1, 2, 3);
 
$monolithic_dimensions = array_map(
    create_function('$elem', 'return $elem * $elem;'),
    $input
);
 
/* Prints Array([0] => 1, [1] => 4, [2] => 9) */
print_r($monolithic_dimensions);
?>

On the face of it, this looks like a decent approximation of functional programming idiom. However, every time PHP executes create_function, it adds a new function to the global function table.

What’s really happening is a little easier to see if you look at create_function’s return value:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<?php
 
$square = create_function('$elem', 'return $elem * $elem;');
 
print gettype($square) . "\n"; /* Prints string */
 
/* Prints
0  []
108	[l]
97	[a]
109	[m]
98	[b]
100	[d]
97	[a]
95	[_]
49	[1]
*/
for ($i = 0; $i < strlen($square); $i++) {
    print ord($square[$i]) . "\t[" . $square[$i] . "]\n";
}
 
?>

Yup. PHP is creating a function at runtime, with an “impossible” name (the zero byte isn’t allowed in function statements) to avoid collisions with user-defined functions.

The initial implementation simply took a string and looked it up in the interpeter’s global function table, then invoked it:

1
2
3
4
5
6
7
8
9

<?php
 
function add($x, $y) {
    return $x + $y;
}
 
$f = "add";
print $f(1, 2); /* Prints 3 */
?>

This probably got implemented in a couple of hours while Rasmus or one of his minions debated how it should work on IRC, and it shows:

• Because a “function” variable is any arbitrary string, there’s no way to statically validate them. Static analysis of PHP is a crap-shoot anyways, so this isn’t a big loss on its own, but overloading one type (string) to do something magic introduces more chances for programmer confusion, too.
• Attempting to call an undefined function is a fatal error, as it should be. However, since it’s trivial to create a “function” variable that refers to an undefined function, this is a lot more headache-inducing than it needs to be. The presence of function_exists doesn’t help; it just makes generic code that much more verbose.
• There are multiple code paths that result in a string being evaluated as a function name, and they don’t all have the same semantics. call_user_func doesn’t abort your script if you pass it a bogus name, but you can’t tell if the called function might return FALSE, you’ll never know it because call_user_func returns that value to indicate errors.
• Several early examples of how to use this feature showcased scripts that accepted function names straight out of user input, which is a security disaster on par with arbitrary code injection. Just because you only created HTML fields for certain names doesn’t mean malicious or bored users won’t start stuffing garbage in there.

Unfortunately, when PHP 4 introduced a simple object model to PHP (necessitating a new variable type, for objects — but more on that later), the PHP team opted not to clean up this hole in the language. Instead, support for methods and static methods was bolted on top. Instead, the $variable() syntax was extended to accept arrays as well. All of the following variables might be callable:

Function names as strings.

$f = "add";

Instance methods, as an array.

$ops = new MathOperations(); $f = array($ops, "add");

Static methods, as an array.

$f = array("StaticMathOperations", "add");

Static methods, as a string.

$f = "StaticMathOperations::add";

There’s no real way of knowing if a value is callable unless you try.

PHP 5.3’s closure syntax addresses some of this: closures are handled as a resource type within the PHP interpreter, finally. However, they come with their own weird implementation limitations.

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. */
?>

This script dies unceremoniously (on Linux, with a segmentation fault) when the PHP interpreter runs off the end of its own stack. This is the kind of behaviour that gives security researchers nightmares, since segmentation faults and bus errors usually go hand in hand with code injection exploits. It’s also a pain to diagnose: you need to break out gdb, because the PHP interpreter is too dead to explain what went wrong.

Other modern languages either monitor the depth of the stack and abort gracefully when it gets too large (Python, Ruby, Java, C#) or prevent large stacks from scribbling over sensitive parts of the program (Perl, Lisp, Haskell). The FreshBooks dev blog illustrates a few examples.

Predictably, the PHP developers don’t think this is a problem.

1
2
3
4
5
6
7

<?php
function monolithic_dimensions() {
    return array(1, 4, 9);
}
 
print monolithic_dimensions()[0]; // syntax error, unexpected '['
?>

Of course, it’s trivial to work around:

1
2
3
4
5
6

<?php
/* ... */
 
$temp = monolithic_dimensions();
print $temp[0]; // Prints 1
?>

In almost every other language with array-indexing syntax, any expression can be indexed if it evaluates to an array. Consider Python:

1
2
3
4

def monolithic_dimensions(): 
    return [1, 4, 9]
 
print monolithic_dimensions()[0] # Prints 1

Or Ruby:

1
2
3
4
5

def monolithic_dimensions
    return [1, 4, 9]
end
 
print monolithic_dimensions()[0] # Prints 1

Or even C:

1
2
3
4
5
6
7
8
9
10

#include <stdio.h>
 
int const *monolithic_dimensions() {
    static int const dimensions[] = {1, 4, 9};
    return dimensions;
}
 
int main() {
    printf("%d\n", monolithic_dimensions()[0]); /* Prints 1 */
}

Of course, since there’s no formal language spec for PHP, there’s no way to know whether this is by design or by accident.

First, let’s look at a simple C++ RAII example, using objects that do nothing except log their own destruction:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

#include <iostream>
#include <string>
 
class LogsDestruction {
public:
  LogsDestruction(std::string name) {
    this->name = name;
  }
 
  ~LogsDestruction() {
    std::cout << this->name << std::endl;
  }
 
private:
  std::string name;
};
 
int main() {
  LogsDestruction a("A");
  LogsDestruction b("B");
}

If you build and run this, you can see that objects a and b are destroyed in last-to-first order:

$ CXXFLAGS='-W -Wall -pedantic -std=c++98' make raii
g++ -W -Wall -pedantic -std=c++98    raii.cpp   -o raii
$ ./raii 
B
A

This order is guaranteed by the C++ language spec.

Now let’s see what happens with the equivalent PHP program:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<?php
class LogsDestruction {
      function __construct($name) {
	     $this->name = $name;
      }
 
      function __destruct() {
	     print $this->name;
             print "\n";
      }
}
 
function raii_example() {
  $a = new LogsDestruction("A");
  $b = new LogsDestruction("B");
}
 
raii_example();
?>

Running this from either a web request or the PHP command-line interpreter gives:

$ php raii.php 
A
B

Surprise!

This is guaranteed to bite you if you have multiple resources that need guaranteed cleanup in the same block. The only workaround available in the language is to do at most one cleanup per function:

1
2
3
4
5
6
7
8
9
10
11
12
13

<?php
/* ... */
function raii_example_inner() {
  $b = new LogsDestruction("B");
}
 
function raii_example() {
  $a = new LogsDestruction("A");
  raii_example_inner();
}
 
raii_example();
?>

Exceptions were added to PHP in PHP5, allowing blocks of PHP to terminate abruptly. Constructs like

1
2
3
4
5

<?php
$h = fopen("config.ini");
$str = some_local_function($h);
fclose($h);
?>

do not guarantee that $h gets closed reliably: if some_local_function throws an exception, flow never reaches line 4 and never closes the handle. For most things, this isn’t actually as big a deal as it would be in other languages: connections, file handles, and other resources are all closed at the end of each request anyways.

However, sometimes you care what order resources are closed in, or you want to perform some cleanup actions with a resource before closing it, and then the lack of a finally clause hurts. One PHP project I’ve worked on talks to an AMQP broker; AMQP has a defined connection teardown process that’s necessary to verify that published messages are actually being processed. The ideal way to handle that would look like:

1
2
3
4
5
6
7
8

<?php
$amqp = new AMQPConnection(/*...*/);
try {
    /* Publish messages using $amqp */
} finally {
    $amqp->close();
}
?>

Without finally (or with blocks/using statements, for the Python and C# programmers out there), the obvious solution is much uglier:

1
2
3
4
5
6
7
8
9
10

<?php
$amqp = new AMQPConnection(/*...*/);
try {
    /* Publish messages using $amqp */
} catch (Exception $e) {
    $amqp->close();
    throw $e;
}
$amqp->close();
?>

Note the near-mandatory duplication.

Of course, it’s possible to work around the lack of automatic resource management syntax by using an idiom from, of all things, C++:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<?php
class Closing {
    private $closeable;
    function __construct($closable) {
        $this->closeable = $closeable;
    }
 
    function __destruct() {
        $this->closeable->close();
    }
}
 
/* ... */
$amqp = new AMQPConnection(/*...*/);
{
    $close_amqp = new Closing($amqp);
    /* Publish messages using $amqp */
}
?>

However, this relies on understanding the interactions between scope, object lifespans, and PHP’s optional garbage collector, which are non-trivial.

The PHP development team doesn’t think this is a problem.