A few years ago PHP developers decided to address a problem not their's to solve by implementing a configuration directive called safe_mode. To those unfamiliar with this wondrous invention, this setting is primarily intended to provide file access limits to prevent users from accessing files that do no belong to them. This supposedly should make it impossible to access files of other people in a shared server environment, a common operating environment for PHP where PHP runs as an Apache module and as such has read access to all files accessible by the webserver regardless of the owner. When enabled, safe_mode will perform a uid/gid (user id and group id) check on the file/directory to be accessed and compare it to the uid/gid of the script that is trying to access the file. If the two match then the file operation will proceed as normal and in all other cases it will fail. In theory this is a fairly simple hack to a problem that is not otherwise easily addressed without significant performance penalties suc...

There are a number of tricks that you can use to squeeze the last bit of performance from your scripts. These tricks won't make your applications much faster, but can give you that little edge in performance you may be looking for. More importantly it may give you insight into how PHP internals works allowing you to write code that can be executed in more optimal fashion by the Zend Engine. Please keep in mind that these are not the 1st optimization you should perform. There are some far easier and more performance advantageous tricks, however once those are exhausted and you don't feel like turning to C, these maybe tricks you would want to consider. So, without further ado... 1) When working with strings and you need to check that the string is either of a certain length you'd understandably would want to use the strlen() function. This function is pretty quick since it's operation does not perform any calculation but merely return the already known length of a string available in the zval structure (in...

Ever wonder what it takes to crash PHP, well here is a quick guide ;-). Technically speaking PHP being a high level language should not crash, but reality speaks for itself. By knowing what could make PHP crash it may be possible to implement various safety mechanisms in your PHP configuration that would prevent users from crashing your PHP. This is quite important since a crash is not only a 'bad thing' [tm] in general but can also have several adverse affect on the web server potentially creating a possibility for a local DOS (Denial of Service). So without further ado here is the current crash list: Stack overflow. PHP does not have any internal stack protection choosing to rely upon the system stack without any protection. This means that if you have a recursive function or a method PHP will eventually crash. function a() { a(); } a(); There are 2 solutions to this problem, 1 avoid using recursive functions they are generally a bad idea anyway, and if you MUST use them implement some counter using...

Lately it seems that the possibility of PHP developers agreeing on something is about as likely as peace in the middle-east being declared overnight. After about a two week cease fire, following the long and bloody fight about studlyCaps aka suckyCaps, which ended with a sound defeat of the forces of sanity & reason the PHP developer community is at it again. Once more we can thank [url=http://coggeshall.org]John Coggeshall[/url] for this bit of entertainment, this time centered around wondrous PHP5 feature called "Exceptions". As you may or may not know in PHP5 it is possible to throw exceptions, which you can then catch and theoretically through this process simply error checking process and make it easier to write code. John proposed that all error messages raised by OO code would report errors by throwing exceptions rather then using the current error reporting mechanism. Technically the idea is sound good, since it would allow reduction in the number of error checks, allowing all error tracking be perfor...