In this third post of the PHP's Source Code for PHP Developers series, we're going to expand on the prior posts to help understand how PHP works internally. In the first post of the series, we looked at how to view PHP's source code, how it's structured as well as some basic C pointers for PHP developers. The second post introduced functions into the mix. This time around, we're going to dive into one of the most useful structures in PHP: variables.

He starts with one of the most important variable types used in PHP's source - the ZVAL. This is one of the keys to PHP's loose typing and can be thought of as "a class with only public properties". He gets into more detail with the properties of this "class" (value, refcount__gc, type and is_ref__gc). Also included is a look at how it's actually used - creating new ones, getting the value of them, converting their types and how the internal PHP functions parse their variables.

There's a lot more covered about variables in the post so if this is interesting stuff to you, be sure to read it all. They've done a great job of explaining one of the more complicated parts of the internals that power PHP.

The issue of PHP strings equaling zero has come up a few times recently. [...] Running that will display Equals zero!, which at first glance probably doesn't make much sense. So what is going on here?

He gets into the specifics of what's happening - a bit of type jugging, less strict comparison since it's the "==" versus "===" and how the PHP manual talks about strings being converted to numbers.

While I still think it is odd that the string gets cast as an integer instead of the other way around, I don't think this is a big deal. I can't recall a single time where I've ever run into this issue in a PHP app. I've only seen it come up in contrived examples like the ones above.

Back in September, Socorro received a security bug relating to the method we were using for processing inputs for the duration of certain reports. The vulnerability included a proof of concept, with an alert box popping up on production when the link was followed. [...] I was quite surprised at the root cause of the vulnerability. We had opted to compare the incoming data against a known set of valid values - a common practice when whitelisting certain inputs. [...] As expected, when this [example] code is tested, a string of '3' and an integer of 3 work equally well, and a string of '5' and an integer of 5 fail equally.

This automatic casting that PHP does internally caused another issue as well - if the string passed in even started with a valid number from their whitelist set, it still passed.

At first we thought this surely had to be a bug in PHP. However, Laura Thomson told me "If comparing two values, type juggling is performed first, which means that the string is converted to a number. This is done by taking the first number found in the string. So this may be confusing/a quirk/a gotcha, but it isn't a bug." And she's right: this isn't a bug per se, but it's certainly an interesting "gotcha."

One of the features originally planned for PHP 5.4 was scalar type hinting. But as you know, they weren't included in the release. Recently the topic has come up again on the mailing list and there has been a hell lot of discussion about it. Yesterday ircmaxell published a blog post about his particular proposals. The reactions on reddit were mixed. On one hand it is clear that people do really want scalar type hints, on the other hand they didn't seem to like that particular proposal.

He gets into some of the details of some of the current proposals and their problems like the strict versus loosely-typed nature of PHP and type hinting that was included but not enforced. One he does like, however, is one based on casting - how the variable ends up being cast rather than the specific type it is when it comes into the function/method. This one still has its flaws, so he suggests another method - weak type hints but with stricter input validation (without casting). He also briefly mentions something called "box based type hinting" that would allow users to define their own hinting rules.

Don't worry - code examples (pseudo-code obviously) are included for each of these proposals to help you understand the differences.

As any of you who follow the PHP internals list know, scalar type hinting has been a hot topic as of late. You'll also know that I've submitted two new RFC (Request For Comment) proposals for inclusion of two new major features in the PHP language. I figured it was worth going into both RFCs and patches a little deeper, explain my rationale and (hopefully) garner some more visibility of the proposals.

He shares the details of the two main RFCs that are proposed right now - parameter type casting hints and object scalar casting magic methods (both with code examples). Right now, they're only in the patch stage and there's talk of improving the current casting functionality of PHP before something like one of these goes into place.

Since PHP 5 you can use type hinting to specify the expected data type of an argument in a function declaration. When you call the function, PHP will check whether or not the arguments are of the specified type. If not, the run-time will raise an error and execution will be halted.

Included in the post are code examples showing how to define custom types in a function definition and what happens if you pass the wrong type in. Also mentioned is one of the main limitations to hinting - the fact that it can't be used on default PHP variable types.

In most web applications today, there is a need to allow users to upload images, audio and video files. Sometimes, we also need to restrict certain types of files from being uploaded - an executable file being an obvious example. Security aside, one might also want to prevent users from misusing the upload facility, e.g. uploading copyrighted music files illegally and using the service to promote piracy! In this article, we'll look into a few ways in which we can achieve this.

The trick to his example is in using the Fileinfo PECL extension. With the help of this extension you can look inside the file and pick out the "magic bytes" (the first few bytes of a file) and see what MIME type the file really is. He includes a simple example of using the extension on a file and a file upload script that checks the type and handles the file accordingly.

In an earlier article on the strong typing I've described the typehint mechanism that provides data type enforcement for the values sent to the methods and functions. Unfortunately said implementation does not protect against another problem associated with the dynamic typing of variables: a lack of type enforcement when overwritting value of an existing variable. In order to control the type of data, I decided to introduce to PHP the concept of autoboxing known from other languages such as C# and Java.

He talks briefly about what autoboxing is (wrapping primitive types into objects automatically) and links to a library that can be used to accomplish it. A bit of sample code is included showing how to create an AutoBoxedObject and how to use it in practice on some string values.

While setting some svn properties at work, we wondered about the correct MIME type for .php files.

He found several in the official IANA list including "text/php", "application/php" and "application/x-http-php" - all valid but none of them considered a standard. He talks about the ones supported by linux distributions (like Debian/Ubuntu) and some reasoning that might make "application/php" the best choice of the list. He points out some downsides to the choice, though, including the fact that something starting with "application/" should considered "machine readable" only despite PHP just being text.

I want to parse PHPDoc code. Let me explain a little bit what I want to do. Imagine a dummy function documented with PHPDoc. [...] PHP has a great reflection API, but as at least in the current PHP version (as far as I know) we only can get the PHPDoc as a string, without parse it. I need to get the parameters and the type of them with reflection. [...] But the type is different.

His script (based loosely on a bit of a component from the Zend Framework) parses the file and its comments and grabs the variable types from the PHPDoc blocks on each method and associates them.

If you're looking for a more mature solution than just this script, take a look at Docblox, a PHP 5.3 documentation generator.