My purity you stole « Finite Hate Machine

My purity you stole

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.

Consider this contrived example:

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

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

This entry was posted on Thursday, January 14th, 2010 at 7:26 pm and is filed under Core Library, Ugly Implementation. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

5 Responses to “My purity you stole”

Grumqa says:

January 14, 2010 at 7:36 pm

Doesn’t C++ sort of do the same thing with virtual functions? What would you have it do instead?

I’d be curious to know if it creates a new function every time it is called with the same arguments.

Owen Jacobson says:

January 14, 2010 at 8:05 pm

No; C++’s virtual function tables are entirely generated at compile time, and the names are real symbols (well, fixed offsets) rather than string literals. This is a little easier to see in Objective-C, where the symbol table is in easy reach, but you can model C++’s behaviour with this C:

#include <stdio.h>
 
/*
class a {
public:
    const char *get_message();
    a(const char *);
private:
    const char *message;
};
*/
 
struct a {
    const char *message;
};
 
struct a_virt {
    const char *(*get_message)(
        struct a *this,
        const struct a_virt *this_vtable
    );
    void (*__constructor__)(
        struct a *this,
        const struct a_virt *this_vtable,
        const char *message
    );
};
 
/* const char *a::get_message() */
const char *a__get_message(
    struct a *this,
    const struct a_virt *this_vtable
) {
    return this->message;
}
 
/* a::a(const char*) */
void a____constructor__(
    struct a *this,
    const struct a_virt *this_vtable,
    const char *message
) {
    /* No base class to delegate to. */
    this->message = message;
}
 
/* The actual virtual table for class a */
const struct a_virt a_virt = {a__get_message, a____constructor__};
 
/*
class b : public a {
public:
    b(const char *);
    void print();
private:
    const char *message;
};
*/
 
struct b {
    /* Fields inherited from type 'a' -- taking advantage
       of an oddity of the C structure padding rules, this
       is even legal as-is. Just ill-advised. */
    const char *message;
 
    /* No new fields in 'b'. */
};
 
struct b_virt {
    /* Methods inherited from a */
    const char *(*get_message)(
        struct a *this,
        const struct a_virt *this_vtable
    );
 
    /* Local methods. */
    void (*__constructor__)(
        struct b *this,
        const struct b_virt *this_vtable,
        const char *message
    );
    void (*print)(
        struct b *this,
        const struct b_virt *this_vtable
    );
};
 
void b____constructor__(
    struct b *this,
    const struct b_virt *this_vtable,
    const char *message
) {
    /* Chain to a::a */
    a____constructor__(this, this_vtable, message);
}
 
void b__print(struct b *this, const struct b_virt *this_vtable) {
    /* Call this->get_message() */
    const char *message = this_vtable->get_message(this, this_vtable);
    printf("%s\n", message);
}
 
/* The actual vtable for type b */
const struct b_virt b_virt = {
    a__get_message,
    b____constructor__,
    b__print
};
 
int main() {
    /* Create a b */
    struct b instance_of_b;
    b_virt.__constructor__(&instance_of_b, &b_virt, "Hello, world.");
 
    /* Call b.print() */
    b_virt.print(&instance_of_b, &b_virt);
}

$ ./virtual-demo
Hello, world.

All of this happens at compile time.

As for the second part of your question:

<?php
 
$x = create_function('', 'return 0;');
$y = create_function('', 'return 0;');
 
print $x == $y; /* Prints nothing (FALSE). */
 
?>

So yes, it does re-create the function every time it’s called, even if you give it the exact same code. This doesn’t really surprise me; caching function bodies is the sort of advanced feature that needs to be implemented differently in every program.

Owen Jacobson says:

January 14, 2010 at 8:12 pm

For some ideas on how to abuse this in Objective-C, consider the links under isa swizzling. (Objective-C calls the pointer to an object’s virtual method table isa.)

Reply

Grumqa says:

January 14, 2010 at 8:22 pm

So does it just purge the function table now and then? It must be doing something so as not to blow up the server because somebody hit a page that creates a function too many times.

Reply
- Owen Jacobson says:
  
  January 14, 2010 at 8:23 pm
  
  Well, see, it’s not a big deal, because the interpreter starts, renders one page, and exits (destroying everything).
  
  Hope you didn’t want to write a long-running program that isn’t a web page in it.
  
  Reply

My purity you stole

5 Responses to “My purity you stole”

Leave a Reply