Contains extension example code, things like creating basic functions, classes, methods, array handling and so on. If you want an example of something just open an issue
Latest commit 3c3c3eb Oct 29, 2014 @mkoppanen Removed unused variables
Failed to load latest commit information.
tests Added example of how to return an object Nov 11, 2013 Initial info regarding #1 Oct 21, 2013
config.m4 Clarify this a bit Oct 19, 2013
extsample.c Removed unused variables Oct 29, 2014
php_extsample.h PHP_EXTSAMPLE_VERSION is a better name. I dont thing zval_ptr_dtor is… Oct 24, 2013


Contains practical examples of PHP extension writing. Things like handling arrays, returning values, creating classes and methods, class constants etc.

This extension is not meant to be a full-blown documentation for writing PHP extensions but hopefully provides useful snippets and patterns to get started.


I'll be adding random examples from time to time. If you need a specific example, just open an issue. Pull requests are welcome as well.


For the development environment you most likely want a Unix-like system like Linux, Solaris or Mac OS X. At the moment I favour Linux because Valgrind support for Mac OS X 10.8 is pretty broken. I would also recommend using debug builds of PHP (./configure --enable-debug) due to optimisations being disabled and there are additional error messages regarding emalloc leaks.

Naturally if you are developing Windows specific extension this doesn't apply. To get started with building on Windows see the following link:

Setting up the extension

The minimal extension usually composes of three files: .m4, .h and .c file. The config.m4 is used by phpize command to generate 'configure' script. The header file normally contains inclusion of several headers like config.h and php.h. The implementation file (.c file) contains the actual code for the extension.

There isn't really enforced naming convention for the files (apart from config.m4) but I tend to favour naming the header as 'php_extname.h' and the implementation file 'extname.c'. This however is a personal preference, nothing more.

Naturally you can break the implementation in several header and implementation files but that's more of personal preference. Usually in extensions composing several classes I tend to break each class into separate .c file.


During debugging your best tools are gdb and valgrind. If you have a debug build of PHP it will tell you when emalloced memory is leaked but for native allocations there won't be any warnings. The way to debug memory leaks is following:

USE_ZEND_ALLOC=0 valgrind php -d extension_dir=modules/ -d script.php

USE_ZEND_ALLOC will turn off Zend MM and you can see leaked emalloced memory in valgrind output. There is an example function called extsample_leak, which can be used to demonstrate a simple memory leak with emalloced and malloced memory.