On the PHPClasses.org blog today there's a new post looking at the security vulnerability that effected not only PHP but lots of other languages making them susceptible to attack from the outside.

In PHP and several other languages used to implement Web applications, arrays are used to store the values of request variables such as $_GET, $_POST, $COOKIE, etc.. IF you receive a request with a large number of request values, until recent versions PHP may run into trouble.

He goes on to explain why there's an issue with the array overloading and what PHP has done in recent releases to help correct the issue - the max_input_vars setting in the php.ini. He also points out that this is not a new issue - it was originally identified back in 2003 (with a video of the original presentation). He points out that the most recent releases of the PHP language have this fix in them and, if at all possible, you should upgrade to protect your applications.

In a new post to his blog Nikita Popov talks about a little trick with inserting values into arrays that can make it take a lot longer than it should (because of how PHP stores its array values in hashtables).

PHP internally uses hashtables to store arrays. The above creates a hashtable with 100% collisions (i.e. all keys will have the same hash). [...] Because every hash function has collisions this C array doesn't actually store the value we want, but a linked list of possible values. [...] Normally there will be only a small number of collisions, so in most cases the linked list will only have one value. But the [included script] creates a hash where all elements collide.

He explains why it works, noting that it's relatively simple to do in PHP because of how it applies a table mask. The slowness comes in when PHP is forced to go through the entire list when it tries to insert. Because of this issue, there's the potential for a Denial of Service attack that could potentially take a server down. There's a fix already in place for the problem, though, so keep an eye out for the next release (that will include a max_input_vars setting to prevent it).

In this recent post to his blog Johannes Schluter talks about a method he's suggested for testing objects in unit tests - overriding the "new" operator to replace specific classes with mocks.

Two years ago at some conference I had a conversation with Sebastian about the need for a way to overload the new operator in PHP so, probably, bad designed code can be tested more easily by replacing specific classes with mocks. [...] Sebastian then pushed the code as part of a new test_helpers extension with some documentation to github and I fixed some bugs in it. The aim of the extension is to collect functionality which might be beneficial for phpUnit and other test scenarios but which should never reach a production environment.

He includes some sample code to show it in action - defining the mock class, using the set_new_overload function to define it as what should be called when the "new" operator is used and a dump of the result.

Martynas Jusevicius has a new post looking at method overloading in PHP5 - a workaround to make it possible at least.

Method overloading (a feature of object-oriented programing which allows having several class methods with the same name but different signatures) is not implemented in PHP, which is a drawback compared to Java. However, PHP 5 provides a way to imitate overloading by catching calls to "inaccessible methods" with magic method __call.

In his example he uses __call to route the request to the correct version of the constructor (__construct0 or __construct1) based on the number of arguments passed in

Eran Gelperin gives an overview of the current state of overloading abilities PHP has in a new blog post today:

Operator overloading is a programming language features that allows operators to act differently depending on the type of data they are operating on. Since OOP lets us create custom types (classes), there are plenty of opportunities to do useful and interesting code manipulations using operator overloading.

He talks about magic functions, the additions that the SPL made, the PECL addition operator and how much its currently being discussed on the PHP internals list.

Thanks to it being posted on reddit, the traffic to a certain post on Michael Kimsal's blog gave him a crash (literally?) course in high load management on a WordPress blog.

The blog post was voted up on reddit, and the server got slammed. So slammed, in fact, that it was unusable for a few hours while I investigated the problem. I didn't know the post was on reddit, but I knew I was getting some traffic.

He spent some time trying to get the Apache server to finally die off and give him back his machine, at least enough to get a feel for what was going on. Part of his problem was not having APC installed like he thought and the other part - WordPress. While friendly on the outside, it's apparently somewhat lacking on the inside.

In a new post to his blog, Matthew Weir O'Phinney talks about a method for overloading arrays in a script written for the PHP 5.2 series.

Several weeks back, a bug was reported against Zend_View that had me initially stumped. [...] I'd read about this some months back on the php internals list, but at the time hadn't understood the consequences.

Basically, __get() no longer returns a reference and returns values in read mode, which makes modifying arrays using overloading impossible using traditional methods.

Unfortunately, this was exactly the functionality that was needed, so Matthew set out to find a way to do just that. His initial method, extending the ArrayObject, worked but still gave errors. On Mike Naberezny's recommendation, though, this too was resolved with a simple call to the __set method instead.

Matthew Weir O'Phinney has a new post on his blog today talking about overloading arrays in PHP 5.2.0 using the magic __get and __construct functions.

Several weeks back, a bug was reported against Zend_View that had me initially stumped. [...] Basically, __get() no longer returns a reference and returns values in read mode, which makes modifying arrays using overloading impossible using traditional methods.

He gives a code example of the problem and two ways to get around it - one using a switch statement to get around the problem and the other ("best solution") was Matthew's option to extend the ArrayObject class.

In a brief new post, Mike Wallner talks about some of the discussion surrounding overloaded array properties lately and something he's discovered about it.

As arrays are the only complex types that are passed by value (resources don't really count here) the solution to described problem is simple: use an object; either an instance of stdClass or ArrayObject will do well, depending if you want to use array index notation.

He includes two code examples, one just trying to overload it in a class with __get (yielding an error) and the other using the constructor to pass an ArrayObject out first, allowing for error-free assignment.

Derick Rethans talks about something he noticed when working with backwards compatibility to PHP 5.1 for the eZ components project - the first of which is that __get doesn't behave itself in some situations.

The first issue is an extra notice in some cases. In our (ezcMailTools) class we implement a method that allows you to "reply" to a parsed e-mail message. you can see we loop over one of the seemingly public variables of the $mail class. However, the ezcMail class does not have this as a public member variable, but instead uses overload.

This all works 'fine' with PHP 5.1, however with PHP 5.2 the following notice was generated for this code:

Notice: Indirect modification of overloaded property ezcMail::$to has no effect in ../Mail/src/tools.php on line 364

The reason for this is that __get() only returns variables in read mode, while foreach() wants a variable in read/write mode as it tries to modify the internal array pointer. As it can't do this PHP 5.2 will now throw a warning on this.

The mentioned code examples are included and he includes the work-around that he found to help keep the issue from popping up again.