Zend Weekly Summaries Issue #304

      Comments Off on Zend Weekly Summaries Issue #304

TLK: Win32 snaps failure
TLK: Etiquette
TLK: GD development
TLK: Upgrading guide
NEW: PHP 5.2.0 RC3
REQ: Testers for ext/filter
TLK: DllMain and libxml2 [continued]
TLK: In other worlds
CVS: Session loading order sorted
PAT: MySQLi connection sharing

TLK: Win32 snaps failure

Richard Quadling was Not Happy. He wrote to internals@ to complain that the last
successful Windows build on the
snaps machine
was dated August 27th!

Edin Kadribasic, who is responsible for all the official Windows builds,
responded to the accusation. He explained that the build failure was due to a patch
Ilia Alshanetsky had applied to the PHP core, which contained the line:

char stmp[MAX_LENGTH_OF_DOUBLE + EG(precision)
+ 1];

Richard wondered if it mightn’t be better to have:

char *stmp;
stmp = emalloc(MAX_LENGTH_OF_DOUBLE + EG(precision) + 1);

Correct, replied Edin. That’s why Tony Dovgal committed exactly that fix some
hours previously.

Short version: Yep, that kind of week.

TLK: Etiquette

Sebastian Bergmann used this quiet list moment to try to do something about the
problem of ‘increased rudeness‘ from the development team, both on the
mailing list and on IRC. He explained that other Open Source projects he contributes
to have a written policy when it comes to developer interaction. Gentoo Linux, for
example, make it very clear that a certain level of professionalism and courtesy is
expected from the developers, both toward one another and toward their users. If
only the PHP team had a similar policy and could discuss technical issues without
becoming offensive or personal…

Unsurprisingly, those publicly backing Sebastian’s plea were the members of the
dev team least likely to become either offensive or personal. Andi Gutmans
reiterated the need for professionalism when representing the PHP project, and Lukas
Smith blamed himself needlessly for things having ‘got out of hand‘.
Disagreements and even politics were to be expected, but the technical discussions
that should dominate the landscape stood more chance of doing so if things were
discussed in a polite manner, wrote Lukas.

Short version: Slapped wrists all round.

TLK: GD development

Thomas Boutell, the father of GD (note: no vowels) wrote to internals@ asking
whether anyone else could help Pierre-Alain Joye along with GD development. He wrote
that he hadn’t seen any movement in the project since it had been moved to php.net
under Pierre’s stewardship back in April, and was uncertain what – if anything – to
do about it.

On a related note, he had been wondering why there is no apparent official
relationship between the PHP team and the ImageMagick project, which includes an
unofficial PHP extension. Although GD is his baby, it has what Thomas termed ‘a
very 1989 API… written by a guy with no formal background in graphics algorithms
‘. Short of a full rewrite, there is no way to improve the quality of GD
output. The best thing about GD is that it has a simple API at the C level, but this
isn’t necessarily helpful to the end users of a language wrapper. ImageMagick, on
the other hand, is much more sophisticated, and has a coder-friendly API in
MagickWand. The ImageMagick license didn’t appear to be an issue – so why, Thomas
asked, is the outdated GD supported in the official PHP builds, and not

New PECL contributor Olivier Hill felt that he could probably help Pierre in some
way. He uses the GD API extensively, and hasn’t come across many limitations. He
promised to look into the PHP implementation and contact Pierre if he felt his input
could make a difference.

Pierre was a little taken aback to find his work on the project viewed as ‘no
‘, and listed his achievements over the last few months. Security fixes
had been distributed all round, and PHP had been released with those fixes. He
agreed that a release was now due, but pointed out that there was a lot of work to
do there regarding configuration management, test scripts and QA. Ensuring that GD
development could move forward in its new environment was no small job.

Thomas seemed happy with Pierre’s assurances, and wrote that he was ‘looking
forward to great things in GD 2.0.34

PHP user Jared Williams elaborated on that unofficial ImageMagick extension,
explaining that he had been responsible for producing the official Windows builds
for it until recently. The aim had always been to move it across to PECL; the lead
developer simply hadn’t found the time to do so. Jared went on to say that the
ImageMagick API is massive; to the best of his knowledge almost 480 of its functions
have been wrapped and are available for use in PHP. Introducing it into PECL would
create a lot of work in terms of documentation, support and maintenance.

Short version: Rumours of the death of GD development are greatly

TLK: Upgrading guide

Lukas Smith, who had spent some precious free time adding more
to the 5_2 upgrade guide, wrote to internals@ to complain that he’d had no
feedback following his request for noteworthy items. His only resources had been the
NEWS file and a couple of core developers’ blogs. Lukas added that the
NEWS file was missing ‘all PHP 5.1.x releases since 5.1.4‘, just in
case it mattered.

Ilia Alshanetsky felt that missing those releases from the NEWS file was OK –
presumably because they came out after 5_2 became the main branch for development.
Lukas’ changes for README.UPDATE_5_2 looked fine to him, and he subsequently
applied the patch.

Short version: Probably everything’s in there already.

NEW: PHP 5.2.0 RC3

Wearing his Release Master hat, Ilia announced the latest PHP 5.2.0 release
candidate as follows:

Andi Gutmans asked if Ilia could post the announcement on the front
page of php.net too? His experience was that posting on internals@ alone didn’t
bring the project enough beta testers. I pointed out that there has been a lot of
user confusion in the past when RCs were announced on php.net and distributed via
the download page, and this is why release candidates are simply announced on the
internals list now. Perhaps we should find a happy medium? Lukas pointed to his
primary tester mailing
; admittedly Wez Furlong was still in the process of configuring it, but
once running it would be an effective way of notifying the world about PHP release
candidates. I was more concerned that the download page wouldn’t enter into the
equation, having been bitten by that following a previous binary compat breakage.
Couldn’t there be a consistent link page just for RCs, perhaps with a paragraph on
it explaining exactly what RC means? ‘You mean like http://qa.php.net/? ;-)‘ wrote Ilia. I agreed that linking
to there from the php.net home page would leave no room for error.

Pierre, who’d been about to write much the same thing, mentioned that it might be
a good idea to remove old RCs from the qa.php.net front page as new ones are added.
I concurred, but also asked if someone could make up a link page explaining the role
of release candidates. Andi didn’t think this necessary; ‘“Release Candidate” is
a very well known term, and no one will confuse that with an official

Ilia agreed to put up the php.net announcement as soon as the Windows binaries
were ready. Edin wasn’t far behind in announcing them:

Short version: I wish I had Andi’s confidence!

REQ: Testers for ext/filter

Pierre, having integrated a bunch of additions and changes into the filter
extension and released a new PECL beta, wrote to the list asking testers to focus
particularly in that area. Since the extension is enabled by default in PHP 5.2, its
code is used in every single query. It was therefore hugely important that any
problems found when using it were reported prior to the full PHP 5.2.0 release.

By ‘bugs trackers’, Pierre meant either the PHP bug reporting system at
http://bugs.php.net (under the
‘filter’ category), or the bug reporting system linked from the PECL project page at

Short version: Like the man says…

TLK: DllMain and libxml2 [continued]

It was Edin that finally pushed the issue. He was concerned that we would reach
the 5.2.0 release date without resolving it, and wanted to know for sure which way
to jump. He wrote that libxml2 is currently linked statically into php5ts.dll
because of the current policy, by which PHP should be able to run in a basic
configuration – regardless of the SAPI – with nothing but php5ts.dll. Given
that the basic configuration now includes several XML extensions, it had become
necessary to link libxml2 into php5ts.dll. Edin’s personal feeling was that
it should stay that way, since ‘past experience tells us that breaking that rule
creates massive problems for users

I didn’t want to interrupt the thread (this was, after all, important stuff) so
wrote to Edin off-list asking why the same argument doesn’t work for PDO and/or
SQLite? Unfortunately, Edin didn’t realize immediately that this was private mail,
so we ended up bouncing that one around publicly in between attempts to keep the
thread focused. My argument was there there’s no database client built into
php5ts.dll, whereas there probably should be at least one. Edin pointed out
that Wez Furlong’s idea had been to allow PECL updates without a full PHP upgrade. I
thought it would be possible to work around this if SQLite 2 were built-in and the
PDO drivers (including php_pdo_sqlite2.dll) were built as shared, but took
Edin’s point that this approach would create problems for SQLite2 users at a later

Andi successfully ignored our off-topic discussion, and responded to Edin’s
initial post. He didn’t see any problem with having libxml2.dll placed in the
same directory as php5ts.dll; in contrast, static linking made the system
extremely inflexible and prevented users from being able to upgrade one component
without upgrading the entire PHP build. There was no performance impact in dynamic
loading. All in all, he felt strongly that statically linking libxml2 was ‘a
really bad design decision
‘, and averred that there have been problems with
statically linked third party libraries throughout PHP’s history.

Rob Richards was sitting on the fence over this. Although building libxml2 as
shared would certainly make his life easier, it was also likely to increase the
number of bogus bug reports through making Windows installation more complicated.
Plenty of users have problems just with enabling extensions, due to DLL
requirements… Andi argued that there were no problems so long as the DLL files are
in the PHP directory, and he thought either the PHP distribution .zip or the
.msi installer must have been putting them somewhere else for this to be an
issue. I pointed out that the old .msi didn’t even install extensions, and
the new one is still in beta. Andi confused me by replying that we need to fix that,
and acknowledging that his own explanation only covered CGI installations. Rob
intervened to point out that a third party DLL in the same directory as
php5ts.dll wouldn’t necessarily take precedence over another version of the
same DLL elsewhere on the system (and in fact, it doesn’t). Under Apache, wrote Rob,
if some other module is loaded prior to PHP that also happens to use
libxml2.dll, the search order for libxml2.dll changes. PHP could
easily end up using a DLL other than that in its own directory, and the same would
then hold true for libxml2’s dependencies, such as iconv. Although CLI should always
use the DLL within the PHP directory, other SAPIs could not be relied upon to do so.
(Note: CLI confusion occurs when the DLL doesn’t exist in the PHP directory but does
exist elsewhere in the search paths!)

Edin pointed out to Andi that ‘the most optimal way to make the Windows build
has been discussed on this list several times during the past 3-4 years, including
the question of which extensions are built in and what libraries to link
‘. The current design has worked well for PHP during this time. He
went on to argue that requiring five or more DLL files in PATH just to
run “Hello world” in any SAPI but CLI/CGI would be less than sub-optimal. There
would also be the increased potential for collisions with other free software using
the same libraries as those shipped with PHP. Finally, Edin reminded Andi of the
sheer volume of bug reports that came in from Windows users after MySQL was
unbundled from the PHP core. That was after ‘de-bundling’ a single library; libxml2
being built as shared would be more complicated than that.

Andi wrote that he couldn’t remember any public decision being made over libxml2,
and asked Edin precisely what the current situation is and what he intended to do
now? That said, it would probably be best to stick with the status quo for the time
being and discuss approaches for PHP 5.3. He really didn’t like the idea of
statically linking libxml2, and the fact of its not being standard MS practice had
led to the current DllMain issue. Edin pointed out that the story began
in 2002, when Zeev Suraski pushed for libxml2 source to be bundled in PHP.
This had never actually happened, but one result was that PHP 5 has had libxml2
bundled in its Windows distributions ever since. There were no problems whatsoever
with this arrangement, until the recent problem with libxml2 and Windows Server 2003

Short version: PHP 5.2’s safe.

TLK: In other worlds

In PHP-GTK corner, Christian Weiske spent the week trying to revitalize the
project; as with the main PHP mailing list, everyone either was away, had been away
or was about to go away. He succeeded in giving Andrei Zmievski a nervous twitch by
requesting (among other things) a review of my ancient implementation of
GPointer support. Eventually I recalled that Andrei had, in fact,
rewritten and committed that patch at the time – but it was a nasty moment.
Christian also brought up something that he believed to be an E_STRICT
issue and everyone else regarded as a Zend Engine/GTK+ incompatibility. His
workaround for it involved renaming a handful of methods, thereby avoiding any
inheritance issues. Andrei presumably gave him permission to do this off-list; the
changes are in CVS, at any rate. I wasn’t overly happy about taking this approach;
it meant breaking BC, as well as diverting from the GTK+ API, and I still felt there
had to be some better way of getting ZE to acknowledge relationships between ‘our’

Over in PECL, there were some interesting new packages in among the releases.

Tony Dovgal kicked off the week with rar-0.3.1 (beta), which contains an updated bundled unrar and
will work with PHP 4. Derick Rethans was close behind him with a timezone database
update, timezonedb-2006.11 – this being a monthly occurrence.
pecl/timezonedb is a drop-in database used by PHP’s date extension, and can
be a bit of a life-saver for people not wanting to upgrade the whole of PHP over a
timezone issue.

Newcomer Mikael Johansson was next with two brand-new packages. The first of
these was wbxml-0.1.0
, a wrapper extension providing PHP with WBXML (Wireless Binary XML)
conversion capabilities using the libwbxml library. The second was ocal-0.1.0 (beta), offering
Oracle Calendar connectivity via the appropriate SDK, itself part of the Oracle Collaboration Suite.

Kellen Bombardier of the IBM team followed up with his release of ibm_db2-1.5.0 (alpha) – an
extension providing support for IBM DB2, IBM Cloudscape and Apache Derby.
AUTOCOMMIT and stored procedures fixes prompted the release.

Finally, there was the pecl/filter release mentioned by Pierre earlier,
which includes a great many fixes from Ilia and Tony as well as from Pierre.
Although the extension is an intrinsic part of PHP 5.2, the PECL version of filter-0.10.0 (beta) is
needed if you need the same functionality in PHP 5.1.

An interesting (if re-presented) proposal came in from Olivier, at Pierre’s
request. He hoped to introduce a wrapper for a C implementation offering Double
Metaphone capability; a better version of the original Metaphone library present in
PHP 4 core, and much faster than the existing PHP implementation of the Double
Metaphone algorithm. Metaphone allows words to be broken down into phonemes; the
advantage of Double Metaphone is that it gives better results with languages other
than English. The C library Olivier planned to use, written by Maurice Aubrey and
available through CPAN, is released under the Artistic License,
which Olivier understood to be compatible with the PHP License. The only thing
Olivier was uncertain about was the name; he didn’t know whether to call the project
pecl/doublemetaphone or pecl/double_metaphone.

Short version: A double metaphone by any other name would s-m-e-ll as

CVS: Session loading order sorted

Changes in CVS that you should probably be aware of include:

  • Zend Engine bug #38624
    (Strange warning when incrementing an object property and exception is thrown from
    __get method) was fixed [Tony]
  • Streams bugs #38199
    (fclose() unable to close STDOUT and
    STDERR) and #38661 (mixed-case URL breaks url-wrappers) were fixed [Tony,
  • In ext/dom, bug
    (getAttribute selects attributes by order, even when
    prefixed) was fixed [Rob]
  • In ext/curl, bugs #38637 (curl_copy_handle() fails to fully copy the cURL
    handle) and #33770
    (https:// or ftps:// do not work when
    --with-curlwrappers is used and SSL certificate is not verifiable)
    were fixed [Ilia]
  • Reflection bug #38653
    (memory leak in ReflectionClass::getConstant()) was fixed [Tony]
  • Following some changes to the module loading order to prevent the
    much-reported crashes on shutdown, ext/session‘s save and serialization
    handlers now throw an E_WARNING rather than an E_ERROR
    if an invalid argument is passed to them at runtime [Tony]
  • The bundled PCRE library was upgraded to version 6.7 in PHP_4_4, PHP_5_2 and
    CVS HEAD [Ilia]
  • The OpenSSL extension gained two new constants,
    PHP_5_2 branch only [Pierre]

There was a brief spat between Stefan and Tony when Stefan pointed out, in his
usual abrasive manner, that certain recently committed code could lead to an integer
overflow. Derick Rethans somehow separated the pair, and Ilia later applied a fix,
crediting Stefan for noticing the problem.

Tony went on to achieve a great deal during the week, despite this bad start. One
major contribution was his elimination of leaks and segfaults when mixed parameter
types are converted during a function. He moved parameters designated as zval*
throughout the source to zval**, using PHP 5’s internal
type representation Z to identify these ‘pointer pointers’ during
parameter parsing. Andrei pointed out that this would actually need to change in PHP
6, but the idea remains sound. Other major items included his clean up of
ext/tidy, which has had a lot of issues in ZTS builds lately, and some work
making it possible to apply multiple filters in ext/filter.

Meanwhile Andrei was busy completing the API for UTF-8 strings in CVS HEAD. This
included implementations of add_property_string[l][_ex](),
add_assoc_utf8_string[l][_ex]() and
add_next_index_utf8_string[l], as well as the
macros. He went on to do a bunch of work on ext/pcre, including an
implementation of Unicode support for preg_match[_all]().

Mike Wallner was also heavily engaged with CVS HEAD. Having committed several
improvements to the new output API (and having documented them in
README.NEW-OUTPUT-API), he updated ext/zlib to utilize it as best he
could without porting the streams API. Edin pulled him up over a requirement for
zlib, pointing out that many systems don’t have it, but Mike appears to have
missed that post. Nuno Lopes also had concerns when he saw
ob_gzhandler() disappear, and wrote asking whether
ob_start("ob_gzhandler") would still work? Mike assured him that not
only would it still work, it would now be as fast as using

Short version: Output buffering in HEAD could do with some serious

PAT: MySQLi connection sharing

Having started the task of editing the README.UPDATE_5_2 file, I was
testing my way through the changes listed there. The new CLI reflection options,
--rf, --rc and --re, weren’t working at all
for me. Eventually I realized they relied on a definition that was missing from the
Windows configuration files, and supplied the trivial fix via the internals list.
Johannes Schlüter applied the patch.

Working at a slightly deeper level, extension writer Evan Nemerson was looking
for a way to share the MySQL connection in his own extension for an RDF triple store
built on top of MySQL 5, with ext/mysqli. Since the mysqli header isn’t
installed, there was no way to do this without patching the extension itself. Evan
offered a trivial function, mysqli_get_connection(), that would take a
zval* and return a pointer to a MySQL object. He wrote,
somewhat apologetically, that this was the least intrusive hack he’d been able to
come up with. There was no response to his mail, so Evan’s patch is sitting in the
PAT directory awaiting a verdict.

Short version: Cheap and cheerful connection sharing for the mysqli API
in PAT.