Zend Weekly Summaries Issue #239

      Comments Off on Zend Weekly Summaries Issue #239

TLK: Reference patch
TLK: Summer of code
REQ: Yahoo! devs
TLK: PHP 5.1 vs Unicode
CVS: __HALT_COMPILER finally got in
PAT: Nothing new

TLK: Reference patch

Something major happened here.

It started off-list, because Derick Rethans initially mailed the
reference patch
he, Marcus Börger and Dmitry Stogov had been
researching for the last several weeks to a small inner developer circle. It ended
up in the public eye because Dmitry argued against releasing a version of PHP 4 that
breaks binary compatibility so late in its career. An incensed Derick – with the
support of his current employer, eZ systems, and several other companies represented
in PHP core development circles – called this ‘totally irresponsible
‘ on Zend’s part, and referred Dmitry to several open bug reports
related to strange and unpredictable segfaults in large code bases. He didn’t
promise that his fix would close all of them, but felt it would close enough to
justify releasing PHP 4.4.

Zeev Suraski argued that the vast majority of PHP 4 users were not seeing those
issues, and the few that were, could apply Derick’s patch. He didn’t want to
fix this in the PHP 4.x tree because it would break module compatibility for
everyone and lead to user confusion. Was he the only person thinking along these

Christian Schneider wanted details about the problem and the implications of the
patch; he’d run into those segfaults, and wanted to see at minimum an easily
accessible document describing the known problems and workarounds. Derick provided
him with two test
but added that it would only be possible to spot the problem by
turning off the Zend memory manager and using valgrind. He also felt it was not
possible to go through a code base of any size and fix every instance without
warnings; in fact he’d already tried to do this himself, and failed.

Ilia Alshanetsky made the good point that some bug reports previously considered
bogus because impossible to reproduce, might well be traced to this issue. He agreed
with Zeev that it wasn’t a common problem, but felt it affected more users than had
been allowed. He also suggested that other bugs outstanding in PHP’s 4_3 branch,
abandoned because fixing them would break binary compatibility, might be fixed as
part of a 4.4 release.

Replying to Zeev, Derick wrote that users didn’t easily encounter the issue
because the Zend MM hid the problem; the segfault was caused by a memory corruption,
which could equally well cause other weird results – for example, objects changing
class on the fly. Not fixing this was not an option, and nor was switching to
PHP 5. Zeev pointed out that Derick’s saying an option was invalid didn’t mean it
was invalid. Breaking binary compatibility within a PHP version family, on the other
hand, was something the team had agreed to avoid some years ago. Providing
information and workarounds and/or asking affected users to upgrade to PHP 5 was
a completely acceptable solution to a problem of this magnitude, when compared
to the cost of fixing it

Wez Furlong felt that the only logical way forward would be a 4_4 branch and
release, and he couldn’t think of any valid reasons not to do that. Zeev raised the
spectre of 0.00001 degrees of global warning being directly attributable to PHP
users having to rebuild everything, and again mentioned user confusion. He also
reiterated his argument about the rarity of problems caused by the bug, saying that
if it were a remote exploit or some such thing he’d agree completely with Derick.
Jani Taskinen pointed out that nobody could guarantee PHP 5.* didn’t have the same
bug at this point in time, and added that he also didn’t have the luxury of
upgrading at present. He also felt that Ilia was probably correct in believing
several ‘hidden’ bug reports could be related to the issue at hand.

PHP user Todd Ruth, who has been reporting reference bugs in PHP 4 for some time
now, sent a heartfelt ‘Thank you! Thank you! Thank you!‘ to Derick, and said
that laying the reference bugs to rest were the most important bug fixes he could
imagine; in his view, they’d led to PHP being seen almost as a second-class
language. He added that he also wasn’t in a position to upgrade his company’s code
base at present.

Rasmus Lerdorf, speaking as another user suffering at the hands of the bug, was
ready to deploy the completed patch and break binary compatibility as soon as it was
available. He had a schedule for migrating his large PHP 4 code base to PHP 5, and
it wasn’t going to change; in the meantime, he would do whatever he could to improve
the current situation. He didn’t believe that other users were all that different,
he wrote, concluding: ‘If we have a fix, we should get it to our users.‘ More
cautiously, he added that it might be a good idea to ask Linux distro package
maintainers what they thought.

Sebastian Bergmann, one of those responsible for maintaining Gentoo’s PHP 4
ebuilds, responded immediately: if there were no PHP 4.4 release containing this
fix, they would probably integrate the patch into the build – effectively forking
PHP 4_3. He didn’t see a 4.4 release as a technical issue so much as a political and
psychological problem ‘only affecting vendors such as Zend‘.

Joe Orton, representing RHEL and Fedora Core 3, felt otherwise, and gave Zeev’s
lone voice some solid support:

Derick pointed out that the bug only affected large code bases, and that was the
problem: ‘Actually, I don’t think it can be worked around. Perhaps technically,
but not practically’.

Marcus couldn’t see the argument against releasing a new PHP 4 version, at all.
However, he felt that the team should look into fixing a bunch of other outstanding
issues ‘to prevent 4.5 from popping up too soon‘, and asked volunteers to
contact Derick, Dmitry or himself for a briefing on Engine internals.

Andi Gutmans surprised everyone by voting for PHP 4.4, saying ‘I think in this
case, the bug… falls into the category of hard to detect and hard to work
‘. He advised, with the voice of long experience, that the urge to fix
other bugs shouldn’t become a Holy Grail, or the new branch would never be

Zeev, brushing off defeat alongside the barely-veiled accusations of conflicting
corporate interests, said he was tired of going through the reasons; he’d simply
thought the release was not justified, given the downsides to it, but everyone else
seemed to prefer the upsides. ‘If everyone here thinks it’s a good idea to go
with 4.4, let’s go ahead and do it
‘. He added that the release notes would need
to be crystal clear, before agreeing with Marcus that other outstanding issues
should be addressed where possible.

Derick proposed to create the new branch next week. He offered to put time into
making it as stable as possible before release, and said he would be very glad to
act as Release Master for the PHP 4.4 series. As for the other issues outstanding –
now was the time to make that list.

Short version: Derick got his way (eZ will be soooo pleased).


One Davy Hellemans wrote in asking when PHP-GTK 2 was likely to be released.
Would it be weeks? Months?

Andrei Zmievski replied, saying that he’d recently upgraded his main machine to
the Mac OSX Tiger release and found that he could no longer run PHP-GTK
applications. There was a slow startup and the fonts looked weird. He suspected an
issue with Darwin’s runtime loader. Christopher Logan backed him up, saying he had
found serious problems in using the Gimp under Tiger and blamed ‘changes in
‘. Ivan Rodriguez confirmed that there were known problems with GTK+
support under the latest Mac OSX.

Daniel Braga mailed the list with a very peculiar PHP-GTK 2 build issue under
Linux. Ivan spent some time trying to help him before Markus Fischer forwarded
Daniel’s output to ‘our configure god‘. Jani promptly fixed
$PHPIZE to fall back to the path setting in PHP-GTK CVS and ensured the
PATH_SEPARATOR check in PHP’s CVS HEAD was only performed by autoconf
versions that understand it, blaming PHP-GTK’s usage of aclocal as he went.

Short version: Environment breakage puts a damper on the pace of

TLK: Summer of code

Adam Maccabee Trachtenberg wondered how on earth the PHP project had managed to
get shut out of Google’s Summer of Code when Perl, Python, and even some projects written in PHP
had made it in? Had the PHP Group somehow missed the boat, hadn’t they been
notified, or was there some reason to choose to stay out?

Ilia simply pointed him to the FAQ
[dead link] entry entitled ‘What is the role of a mentoring
organization?’, but Rasmus explained that this wasn’t it – Group simply hadn’t been
contacted. He’d known about the project, but hadn’t paid enough attention to the
details to spot that eligible projects had a very limited window in which to apply
to join. Like, one day.

Andi mailed internals@ to say that the Group had now written to the project
manager, asking why PHP was neither in Google’s list of eligible projects nor
contacted. The answer they received said simply that it was too late to apply now
and they should wait for next year.

David Zülke wrote in saying that there were some proposals in the scheme that had
the stated aim of improving PHP itself, and provided a link to one such proposal – submitted by himself, encouraged by the
project manager and aimed at namespaces in PHP 5. ‘That’d be sweet, eh? Any
opinions on that one?
‘ (Oh please.)

Marcus was quick to retort that namespaces had been declined for a good reason
and David should search the mail archives for them. However, he also provided a link
to Sebastian’s 2 year old [23rd June 2003] email proposing package
, adding that Timm Friebe used to have a patch with some basic package
implementations which could make an interesting basis for a project.

Short version: Missed opportunity.

REQ: Yahoo! devs

Rasmus mailed spam to the internals list, calling it ‘good
get-a-job-working-with-php spam’:

Short version: America’s PHP community gets a boost.

TLK: PHP 5.1 vs Unicode

Andi wrote:

He envisioned a full PHP 5.1 release at the end of June, and the first
beta of the Unicode version (release number yet to be decided) in the third quarter
of this year.

Greg Beaver, feeling that PEAR 1.4.0 and the single file distribution system
wouldn’t be stable in time for PHP 5.1 on that schedule, promptly adjusted his
target to the Unicode version.

Magnus Määttä put in a two-line email requesting ifsetor() in 5.1
and goto for the third quarter <sigh />.

Marcus wanted to see return by reference at the C level in place; Dmitry was
working on it, but he actually needed to use it. He also asked for the return of
magic __toString() support, filtering and ifsetor().
Johannes Schlüter was quick to back his requests for __toString() and
ifsetor() in particular, and asked about ‘the new date

Andi promised to look into Dmitry’s work, and asked what had happened to the
__toString() patch Marcus had promised. He didn’t see anyone actively
working on filtering, and hoped to allocate (Zend) resources to it ‘in the near
‘, but as it was an extension it would happen in its own time. He also
wanted to put an API proposal for it together first, believing that the API was a
bigger issue than the actual coding. ifsetor() was completely off his
radar: he didn’t believe it was needed in PHP, and it would be even less needed once
there was a filtering API. The important thing was to get PHP 5.1 – with PDO – out
there, allowing the Unicode work to be merged into a new CVS HEAD.

Marcus had forgotten to post that particular patch, and sent it to Andi
immediately. He agreed with him over the need for a filtering API and the priorities

Derick reported that ‘the new date stuff’ should be ready during the week, and
Pierre-Alain Joye added that pecl/date would be immediately updated to work
alongside Derick’s changes, and moved to the PHP core.

Rasmus reported that his filtering framework was in place and also lurking in
PECL, as pecl/filter. He would try to implement some actual filters during
the week. The SAPI hooks for it had been in place for some time; it was fine in PECL
and shouldn’t hold up PHP 5.1, which he was also keen to see ‘out there’.

Jani backed Magnus’ earlier requests, asking ‘Wasn’t there a patch for
goto already somewhere?

Short version: I can hear Zeev groaning from here.

CVS: __HALT_COMPILER finally got in

Source code changes you probably should know about this week include:

  • Jani’s fix allowing builds with --enable-session=shared
  • Dmitry’s ‘valgrind errors only’ fix that inadvertently mended the
    stream_get_line() buffer overrun. There were a bunch of similar
    problems addressed by Dmitry this week, including memory allocation bugs in the
    ‘magic’ object handlers and a large memory leak in list() array key
  • Derick’s fix for memory corruption in stristr()
  • A new ext/mysqli function from Georg Richter,
  • The final __halt_compiler() patch‘ and interface, from
  • Vastly improved performance of bzdecompress() from Ilia

Short version: Sweet.

PAT: Nothing new

Thomas Jarosch mailed in a patch adding a new ext/imap function,
imap_status_current(). He said it had been developed for PHP 4.3.11,
but could also be applied to PHP 5.0.4 – not helpful in either case, as neither the
PHP 4 or PHP 5_0 branches allow new functionality, which is why it got ignored.
Thomas followed up with a backport of imap_getacl() from PHP 5 to PHP
4, at which point Derick let him know the problem.

Antony ‘call me Tony’ Dovgal committed code donated by the nameless PHP user
who’d nicely reported the
ext/odbd bug his/her patch fixed.

Johannes had found an exception to PHP’s background casting that bugged him;

= false;


He’d evidently spent some time looking into the issues, including that of
NULL++ and NULL--, before producing a patch that would
allow increments and decrements of simple types by casting Boolean and
NULL values to long, despite the BC break incurred.

Derick wrote a sympathetic note, saying that he’d provided a similar ‘fix’ some
time in the past, and it had been decided not to promote types in such cases.

Short version: A quiet week for patches.