Zend Weekly Summaries Issue #328

      4 Comments on Zend Weekly Summaries Issue #328

TLK: Sequence handling in ext/soap
TLK: Runtime JIT revisited
NEW: PHP 4.4.5
TLK: RC announcements
TLK: Inconsistent charset names
BUG: IMAP on Windows
REQ: fileinfo for 5.2.2
CVS: Andrei’s week off
PAT: Mini-wars and chocolate bars

TLK: Sequence handling in ext/soap

Lukas Smith kicked off the week with a small piece of bad news; he’d found
the need to re-open a bug
about the handling of sequences in ext/soap. Dmitry Stogov
had addressed the initial complaint – that a single element in a SOAP client
response was returned as an object rather than as an array – by introducing a
new option to be passed to the SoapClient constructor:


Lukas had tried to use it, and found it problematic because it didn’t work as
expected. He’d anticipated having an appropriate array returned, regardless of
whether the sequence was empty, contained a single element, or contained
multiple elements. The thing that finished him off was turning on the new
feature and finding array(null) where he’d expected to see an
empty array…

Short version: Needs a bit of work.

TLK: Runtime JIT revisited

Dmitry posted the patch he’d promised during an off-list discussion with
those directly involved, alongside a fair chunk of said discussion. In his
solution, JIT will only be runtime where
zend_register_auto_global_ex() is called with 1 as
the final argument, in place of zend_register_auto_global(). For
the benefit of list followers, he added that the reason the patch was so big
was that it included a reversion of Sara’s original autoglobals CV
. Dmitry had reimplemented that, using

Pierre-Alain Joye liked the patch, and wrote that it actually implemented the
concept he’d described in his initial
. He went on to say that he’d been communicating with Dmitry
off-list, and now had a road map in place:

  1. Implement the callback to decode the input
  2. Support multiple calls of http_input_encoding, GPC must be re-encoded
    (rearm JIT)
  3. A new function is required and a couple of changes in the hash
    creations (call dtor, etc.)
  4. Add test cases
  5. Implement unicode support in ext/filter

Pierre wouldn’t have time to work on any of this for over a week, and asked
if anyone else on the team was able to look into it any earlier. There were
no takers, on-list at least.

Andrei Zmievski asked whether Dmitry’s implementation had runtime JIT
per-element, or for the entire array at once? Pierre responded; the whole
array would be JIT’d, in the same way as compile-time JIT works currently.
There were no further questions, and Dmitry committed his changes into CVS
HEAD at the end of the week.

Short version: Half the team were at some conference this week.

NEW: PHP 4.4.5

Derick Rethans, as Release Master for the PHP 4.4 series, announced the
release of PHP 4.4.5 as follows:

The full release announcement, available on php.net, lists
many of the same security fixes that were made available in PHP 5.2.1 last

Downloads: http://www.php.net/downloads.php#v4

Changelog: http://www.php.net/ChangeLog-4.php#4.4.5

Short version: No nasty surprises, plenty of security benefits –
please upgrade ASAP.

TLK: RC announcements

Following Hannes Magnusson’s unilateral decision to remove the conference
announcements away from the php.net home page
and subsequent off-list proposal for redressing the issue (read: scorched
corpses on IRC), Tony Dovgal suggested that PHP Release Candidates should be
announced there. He hoped that this would promote the amount of feedback the
team get from the community prior to a full release; did anyone have any

Ilia Alshanetsky felt that it would only make sense to advertise the first
Release Candidate of the cycle, since later RCs tend to have very few
changes. Tony didn’t think this mattered, and Lukas saw the discrimination as
less than transparent from the end user perspective. Pierre agreed that all
releases should be announced, and thought perhaps a little image or logo
should accompany the announcement to clarify its status. One Alexey
Zakhlestin suggested a block containing both ‘latest testing release’ and
‘latest stable release’, with the ‘testing release’ part only appearing when
appropriate. Tony, noting that this is a similar approach to that taken by the QA site, agreed that this would be a good
idea. Mike Wallner and Derick also backed it.

I posted a message to remind everybody why RC announcements had disappeared
from the home page in the first place – briefly, user confusion – and asked
that it be made excruciatingly clear, both in the announcement and on the
download page, that Release Candidates are for test purposes only. Tony
didn’t see the problem with simply calling a Release Candidate by its name,
but I educated him off-list about bug reports in the past stemming from
confusion between ‘Release Candidate’ and ‘Current Release’. Not everyone
knows what a Release Candidate is, and the fact that the php.net home page is
written exclusively in English is unhelpful here. Tony slyly asked me to help
with the wording.

Meanwhile Greg Beaver had been on IRC trying to resolve the same issue, but
using layout alone. He suggested separating the announcement blocks, with the
current release block always above the test block. Tony liked this idea. He
felt that a full explanation of the term ‘Release Candidate’ should go on
qa.php.net and be linked from the ‘test block’, and volunteered to write it.
He asked Hannes to prepare a patch for the php.net home page, given that
Hannes is involved in that area already. Sebastian Nohn asked whether the
‘Providing QA for PHP’ block could be made available as an RSS feed while
they were at it.

Richard Lynch came up with some solid suggestions, including those that had
already been agreed (of having a stable release block prior to a test release
block). He advocated an extra page between the Release Candidate link and
download page, which would contain something very clear such as:

You are downloading a RELEASE CANDIDATE.
This should be used for TEST PURPOSES ONLY.

and force the user to click one more time. The slight inconvenience would be
a Good Thing™ in this situation, he felt. Richard also suggested that
the term ‘Release Candidate’ should be replaced with ‘Unstable’ or ‘Test’ in
the link text.

Hannes, who didn’t really see any point in ‘scattering boxes all around‘,
came up with a
that included a single box listing the current PHP 5 and PHP 4
versions, followed by any current Release Candidates. To him it was obvious
that the Release Candidate links shouldn’t be directly to the tarballs (heh).
They should point to dedicated download pages on the QA site, something like
qa.php.net/#v5 and qa.php.net/#v4, where there should also be ‘a big fat box
explaining the concept of Release Candidate
‘. The stable links should remain
as they currently are, pointing to the
download page
on the main site. This way, the only major change would be
in the way the Release Master posts a new release; all current items would
need to go into a new file, include/version.inc,
in the phpweb module. This in turn would allow the team to provide an
atomic feed with direct links to the stable releases and notification of
Release Candidates.

I liked the sound of that, but wanted to know why Hannes’ conference/call for
papers header block – the compromise solution agreed on IRC – hadn’t made it
into CVS yet. He explained that Sean Coates was working on a nicer way to do
that. Tony wanted to divide the block into two parts: Releases and Release
Candidates, as agreed. Hannes pointed out that it effectively is, since the
feed comes as two separate arrays, but Tony wanted the difference to be
emphasized. Mike Ford, coming late to the discussion, strongly recommended
avoiding the word ‘release’ when it comes to Release Candidates. ‘Preview’ or
‘Test’, or even ‘Next version’, would be far less open to misinterpretation.

Jochem Maas and Tony concluded the debate with an exchange of prose
describing the role of a Release Candidate, which gradually grew more and
more purple as the hours went by. I promise I will fix that block of text
before it gets anywhere near your sensitive eyes.

Short version: PHP users know rather more about Web design than the
core team.

TLK: Inconsistent charset names

Mathias Bank wrote to internals@ to complain that utf-8 has different names
throughout PHP, depending on where it is used. He’d found that, when using
the functions in ext/tidy, the charset is known as
utf8‘. Moving over to html_entity_decode(), the
same charset is called ‘UTF-8‘. Mathias saw the difference as
confusing, and pointed out that it means having to check the manual more
often than should be necessary. Would it be possible to agree on a single

Mike Wallner responded with the explanation that the character sets supported
by the underlying Tidy library are defined by it; the naming is therefore out
of the PHP team’s hands. He ended his note with a link to the manual page for
tidy_set_encoding(), which lists the supported character sets;
the function itself became obsolete in Tidy 2.0.

Short version: Upgrade libtidy while you’re at it.

BUG: IMAP on Windows

Stas Malyshev wrote in asking if anyone knew how to build the IMAP module
successfully under Windows? His own attempts had ended abruptly in a clash of
symbols (sorry) between c-client and PHP, and he couldn’t see a good way to
avoid it.

Frank Kromann advised him to modify and rebuild IMAP itself before attempting
to build the PHP extension; the c-client link flag /MT in
Makefile.w2k needs to be /MD.

Short version: Moving to MSVCRT fixes the clash?

REQ: fileinfo for 5.2.2

Kevin ‘Shai’ Waterson noticed that his beloved ext/fileinfo is still
out in the PECL cold in PHP 5.2.1, despite the long discussion only a few weeks ago about reinstating
it in the core. Given that several developers on the core team had backed his
original request for its return, Kevin hoped to see it back in place very
soon. After all, ‘it’s just silly not having the ability to verify a file
type as a standard feature…

Short version: Suggesting it on Lukas’
TODO Wiki might help further
the cause.

CVS: Andrei’s week off

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

  • Core bug #40335
    (Compile fails when using GCC 4.1.1/binutils 2.17) was fixed in the PHP_4_4
    branch, prior to the PHP 4.4.5 release [Tony]
  • Another core bug, #40109
    (iptcembed() fails on non-jfif jpegs), was fixed in PHP_5_2
    and CVS HEAD [Tony]
  • In ext/simplexml, bug
    (addAttribute() may crash when used with
    non-existent child node) was fixed [Tony]
  • In the 5_2 branch only, core bugs #40432
    (strip_tags() fails with greater than in attribute), #40465 (Ensure that all PHP
    elements are printed by var_dump) and #40455
    (safe_mode_exec_dir gets executed) were fixed [Ilia,
  • Core proc_open bugs #34794
    (proc_close() hangs when used with two processes) and #39322
    (proc_terminate() destroys process resource) were fixed in 5_2
    and HEAD [Nuno Lopes]
  • Zend Engine 2 bug
    (echo ... | php -a function allocation eats
    memory) was fixed [Dmitry]
  • FastCGI bugs #40352
    (FCGI_WEB_SERVER_ADDRS function gets lost) and #40414 (endless
    fork() loop when running FastCGI) were fixed in 5_2 and HEAD
  • Another FastCGI bug, #40286 (PHP FastCGI
    with PHP_FCGI_CHILDREN doesn’t kill children when parent is
    killed), was fixed in all three current PHP branches [Dmitry]
  • In ext/soap, bug
    (Partial SOAP request sent when XSD sequence or
    choice include minOccurs=0) was fixed
  • There are now safe_realloc(), safe_erealloc()
    and safe_perealloc() functions in PHP_5_2 branch and CVS HEAD
    (affects internals only) [Stas]
  • In ext/json, bug
    (json_encode integer conversion is inconsistent with PHP)
    was fixed in the PHP_5_2 branch [Ilia]

The only other thing worth noting this week is that Philip Olson got around
to making the bug reporting system issue a weekly Bug Summary Report for PHP
6 to the internals list (43 bugs listed already!). He also ‘detoured’
version-agnostic bugs, i.e. site or documentation issues, and developers for
these reports will now get a direct weekly reminder.

Short version: Nothing happening in CVS HEAD specifically, but a
fair number of core and FastCGI bugs cleared this week.

PAT: Mini-wars and chocolate bars

Christopher Jones did his usual thing and provided a bunch of minor
improvements for the oci8 extension. Tony applied his efforts to the 5_2
branch and CVS HEAD.

Nuno posted one of his proc_open fixes to the list for peer
review (later applied) before silently fixing the ftp_ssl_connect() bug highlighted
by Mehdi back at the start of the year.

Dmitry went on a bit of a mission after this and cleared a bunch of
outstanding patches, including Mike Wallner’s fix for
zend_llist_remove_tail(), Caroline Maynard’s patch allowing C++
extensions using compiler/executor globals to build against PHP, and Andy
Wharmby’s fix for assert_options(ASSERT_CALLBACK). Ilia asked
him to revert the latter, arguing that the patch brought a performance
penalty with it. I pointed out that this would leave anyone attempting to use
assert() with no way of querying the callback setting, and asked
whether I should fix the manual to reflect reality or wait for a less
intrusive fix to turn up? Ilia confirmed that he meant the manual needed
fixing, and alerted me to the minor battle then raging on the bug report opened by Andy
when his patch was first ignored on the list. Dmitry, claiming that the
original patch also fixed a SIGSEGV, went to find another
approach. Nuno asked for a test script for the segfault, but Dmitry – who by
now had found a way to avoid the performance hit – replied that he was unable
to reproduce it. I waited for Ilia to complain that the new code will only
return a string rather than support mixed values, but he didn’t – and it’s
definitely better than we’ve had for the last few years. A static method used
as a callback simply returns ‘Array’ as the callback name rather than

Short version: All we need now is a fix for the fix.