In the process of some development he's been doing on various shared modules for PHP, Derick Rethans stumbled across an issue with using Valgrind to test his code:

While testing whether I correctly free all memory with Valgrind, I ran into the issue where I couldn't see the stack frames of where the memory leaks occurred in the extensions, and once I even ran into a Valgrind bug. The reason why Valgrind could not show the function names belonging to the stack frames is because PHP had already unloaded the shared extensions from memory.

A work-around he found was compiling the modules, but he wanted something "more correct" and less of a hassle. As a result he added a check for the ZEND_DONT_UNLOAD_MODULES environment flag to the PHP core to handles this case specifically. He includes a snippet of example code showing the Valgrind results with and without the flag.

On Tim's blog today (Design by Tim), he has a new post that talks about "learning to extract()" - using this function to create variables based on $_GET and $_POST entries.

The days of explicitly declaring variables passed in from a form for use - or (gasp) using $_GET['varName'] in your code is no longer needed! Clear as well as clean code is the discussion for variable setting today, and we get to explore how easy it is to extract(), Typically you would have call the variable and then set it.

The world is changing. While that is not bad for small forms or simple tasks but what if your project is larger or lets just say after reading this article you abondon gathering all the $_GET data from your simple form?

He goes on to talk about the different flags that you can pass in for various options (like "overwrite existing variable" or "prefix variable names with this" sorts of things). Of course, this kind of methodology has to be used carefully so as not to create more security issues than it's worth...