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

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();
?>