Zend Weekly Summaries Issue #335

      Comments Off on Zend Weekly Summaries Issue #335

TLK: PHP 5.2.2 release schedule
TLK: Breaking coding standards
TLK: –with-static-icu
TLK: Security contact
TLK: This time it’s real
NEW: Imagick extension gets a boost
TLK: Abstract static function
BUG: To lock or not to lock
TLK: GSoC 07
TLK: Building on Windows
CVS: Registered DOM class changes

TLK: PHP 5.2.2 release schedule

Ilia Alshanetsky, as Release Master for the PHP 5.2 series, kicked off the
week with an announcement that the PHP 5.2.2 release cycle was about to
begin. He planned the first Release Candidate for Thursday of this week, and
asked that anyone with a patch intended for this release commit it over the
next day or two.

Greg Beaver promptly posted yet another reminder about his patch to improve the current
implementation of __HALT_COMPILER(), which allows only one
__COMPILER_HALT_OFFSET__ constant per request. His patch allows
one such constant per file. Ilia later committed Greg’s patch into the
PHP_5_2 branch.

Daniel Rozsnyó put in a plea for his
own patch
for multicast support in ext/sockets, first introduced some ten
weeks ago. He had now updated the patch from the original PHP 5.1.6 version,
although it still isn’t entirely up to date (he wrote that it had been in use
for almost 30 days.) Daniel added that there is now a feature request open for
this functionality; the request is not his own.

Andrey Hristov wanted to know exactly what the situation is when it comes to
evaluating such patches for the PHP_5_2 branch – wasn’t it now the stable
branch of PHP, in theory? – but Ilia confirmed that development work is still
occurring in the 5_2 branch.

Short version: PHP_4_4 is still ‘the stable branch’ at this stage.
Apparently.

TLK: Breaking coding standards

Someone calling themselves ‘js’ had been ‘fiddling with PHP extensions’ and
believed s/he’d found an error in the sapi_add_header_ex()
function in main/SAPI.c:


if (!duplicate)
efree(header_line);

According to the PHP coding standards, a function given a pointer to a
resource should not free it unless the function was a) designed specifically
to do so or b) passed a flag specifying that the arguments should be freed.
Was the SAPI.c code intentional and, if so, what was the reason to
break the coding standards? Also, in this particular situation, what did
‘duplicate’ actually mean?

Tony Dovgal reassured js that the code was intentional, and explained
that there are always exceptions to coding standards. It could, on occasion,
be convenient to free a duplicated buffer and ignore the static copy; Tony
referred js to main/main.c, line 1119 for an example of this in
action. js asked whether it mightn’t be nicer to alter the name of the flag
from duplicate to something more appropriate, like
static or no_duplicate, in such a case? However, as
Tony pointed out, there are plenty of places in the PHP source that genuinely
need attention, and this isn’t one of them.

Short version [Thanks Tony]: Don’t fix what ain’t broke.

TLK: –with-static-icu

Internals newbie Oliver Block had had some difficulty in compiling CVS HEAD
under Windows, and wrote to internals@ for help. He was seeing an error
message about a missing library named icuuc.lib, and wanted to know if
it was possible to download a pre-compiled copy of ICU to build the embryo PHP
6 against?

Edin Kadribasic obliged with download links for the MSVC 6 version
of ICU
as used for PHP 6, and the entire set of precompiled libraries for all
PHP versions
(again, using MSVC 6 as the compiler).

Short version: The unsung win32 hero rides again.

TLK: Security contact

Debian PHP package maintainer Sean Finney wrote to internals@ to introduce
himself and to ask whether there is a designated point of contact for
security related issues in PHP? Sean was interested because some of the MOPB
issues had not yet been backported by the Debian/PHP team; it would be useful
for them to know which fixes were relevant. In particular, he wanted to
confirm the explicit fix for MOPB #44.

Oddly enough, Sean suspected – and Stas Malyshev confirmed – that the fix in
question was applied some two months before the Month of PHP Bugs project
even began. Stas suggested he should write to the non-public security mailing
list if he had any further needs.

Short version: Shh!

TLK: This time it’s real

Long time PHP contributor David Sklar wrote to the internals list. He wanted
to see (and be able to set) a timeout corresponding to ‘clock time
rather than to PHP execution time; under UNIX, the behaviour he hoped for
would be as if zend_set_timeout() used setitimer‘s
ITIMER_REAL rather than ITIMER_PROF. Before
investigating further, David wanted to know whether there are any inherent
problems in using ITIMER_REAL, and whether indeed there would be
any interest in a patch for a new INI directive to set something like
max_real_time alongside or instead of
max_execution_time?

Stas broke the sad news that ITIMER_REAL on some systems happens
to be the same as the alarm() function used by Apache; it’s quite
likely that there would be conflict there.

Short version: Good ideas don’t always work out.

NEW: Imagick extension gets a boost

Scott MacVicar put in a CVS account request. He plans to take over
maintenance of the Imagick extension in PECL, and also to assist Pierre-Alain
Joye with his work on libGD.

Mikko Koppanen requested access to pecl/imagick the same day, citing
his work on the extension alongside Scott.

Pierre promptly backed both account requests, and they went through unusually
quickly.

Short version: It might be worth keeping an eye on pecl/imagick.

TLK: Abstract static function

One Jingcheng Zhang wrote to internals@. It seems that he’d happily been
using abstract static methods until PHP 5.2 came along. As an example,
Jingcheng found them useful to delay the implementation of certain static
class methods, such as dispatchers, and keep them as singleton application
models. He had been somewhat taken aback to find abstract static methods
criminalized (throwing E_STRICT warnings) in PHP 5.2, even
though they are still allowed in interfaces. Why should such a good way to
natively support singletons be disallowed?

Jakob Buchgraber wrote that the concept simply makes no sense from an OO
point of view; a static method always belongs to a specific class, whereas an
abstract method needs to be overridden within the subclass. However, this was
the only response poor Jingcheng received.

Short version: This battle is being fought endlessly off-list too.
(Yes, still.)

BUG: To lock or not to lock

Matt Wilmas posted a message to say that the latest PHP_5_2 snapshot doesn’t
compile under Windows, bailing out with:


main.obj : error LNK2019: unresolved external symbol _php_flock referenced
in function _php_log_err
Release_TSphp5ts.dll : fatal error LNK1120: 1
unresolved externals

Matt had traced this back to a bug
fix commit
from Ilia last week, and wrote that commenting out the
php_flock line allows PHP to build. Meanwhile, of course, the
Windows snapshot distributions weren’t able to build at all.

Rasmus Lerdorf wrote rather crossly that he still saw no reason for that
lock, and had commented on it at the time. Single writes in append mode are
atomic, ‘even on Windows‘; come to that, Matt’s simple workaround was
actually the correct fix and should be committed into CVS.

Ilia apologized for not having replied sooner to Rasmus’ note, explaining
that under Linux the original test script for that particular bug fails when
the lock is removed if the error message is more than 4kb. In that situation,
multiple buffers are used and corruption can occur – hence the need for a
lock.

Richard Quadling jumped in to prove that the same problem could in fact be
reproduced under Windows if there is no lock.

Rasmus wanted to know whether anyone had tested that script after the
multiple calls to fprintf() in the original source had been
condensed to one (as part of the same fix)? He didn’t see how it could
possibly mess up with a single fprintf() call. Richard dropped
out of his depth at this point, but Rob Richards stepped in to confirm that
the test script would actually fail given a single fprintf()
call and no lock under win32. Using flock() (rather than
php_flock()) was enough to fix the problem he saw. Rasmus still
couldn’t see how this was possible, and asked Rob to try a couple of other
approaches, none of which worked. Rob eventually tracked down the problem to
the fact that fprintf() uses stdio; changing it to
use VCWD_OPEN_MODE, write() and
close() would do the trick.

Short version: There’s a solution after all.

TLK: GSoC 07

GSoC 06 alumni Igor Feghali wrote to ask how his application for GSoC 07,
“Foreign Keys: another improvement to PEAR::MDB2_Schema”, was faring. Marcus
Börger explained that no feedback could be given yet; the mentors were
still waiting for Google to assign a number of projects at this stage. Robert
Deaton believed they already had, but Marcus replied that this was simply an
estimate. Igor wondered if he could possibly view the project list with this
line, but another GSoC 07 candidate named Asbjørn Sloth
Tønnesen (isn’t that great? :) wrote that no, only the mentors could
see it.

Short version: The natives are getting restless.

TLK: Building on Windows

A different Igor – Igor Golubev – wrote to complain that he had real problems
building PHP 4.4.x under Windows from source. He’d found on investigation that
this was because the project files in the win32 directory didn’t match the
actual code; for example, php4dll.dsp and php4dllts.dsp both
reference files that don’t exist in ext/pcre. He’d managed to fix
those files, but had received further unrelated errors during compilation.
The more he fixed, the more errors he saw. How on earth had all those Windows
releases been built in the past? And could someone please give him some solid
advice on building the branch from the source?

Richard Quadling promptly wrote asking, too, which MS compiler should be used
– something he’s never been able to figure out.

Johannes Schlüter came up with a list of MS compilers suited for
building PHP 5, stolen straight from the PHP
manual
. He believed – but wasn’t certain – that the Express
edition is also suitable. If all else failed, Windows users could always use
cygwin for building PHP. That said – did Igor really need PHP 4? The new
build system in PHP 5 made life much simpler – and besides, ‘PHP 4 is from
the stone age
‘.

Igor retorted that building with cygwin, as far as he knew, was neither
supported nor working. He did really need to build PHP 4 from source;
he’s a tester for Phalanger, a PHP compiler for .NET, and needed to build a
missing extension for it. The Phalanger project only supports PHP 4
extensions.

Outside that, Igor added, he was simply interested to know how to build PHP
on Windows. He’d never come across any problems with it under Linux/FreeBSD,
and had been amazed to discover how cumbersome it is under Windows.

Short version: The PHP 4 Windows project files could do with
some love.

CVS: Registered DOM class changes

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

  • phpinfo() now knows the difference between the set path
    for php.ini and the copy that was actually loaded [Jani Taskinen]
  • In ext/soap, bug #37013
    (server hangs when returning circular object references) was fixed [Dmitry
    Stogov]
  • In CVS HEAD, ‘undocumented and incomplete support for strings in the
    list() operator’ was removed [Dmitry]
  • Registered classes can now be changed in ext/dom, in 5_2 and CVS
    HEAD [Rob Richards]
  • Relative includes work again on Solaris following a fix for bug #39351 [Tony]
  • GD bug #40858 was closed
    following thread safety improvements to the freetype cache management
    [Pierre]
  • Two MOPB bugs in mb_send_mail() were fixed in the PHP_4_4
    branch [Seiji Masugata]
  • In ext/session, bug
    #40998
    (long session array keys are truncated) was fixed across all
    current PHP branches [Tony]
  • In ext/filter, a single filter can now be passed as an argument
    to filter_var_array(), closing bug #40947 [Pierre]
  • In ext/mcrypt, bug
    #40999
    (mcrypt_create_iv() not using random seed) was fixed
    [Ilia, merged to HEAD by Tony]
  • ext/spl bug #40442
    (ArrayObject::offsetExists does not return a valid result) was
    fixed in the 5_2 branch only [Marcus]
  • The disk_*() functions in the PHP core were cleaned and
    refactored in the 5_2 branch [Tony]
  • token_get_all() now includes line numbers as part of the
    return data [Johannes Schlüter]
  • PDO_MYSQL bug #40822 (pdo_mysql
    does not return rowCount() on select) was fixed in the 5_2 branch
    [Ilia]

In other CVS news, Pierre’s implementation of PKCS#12 support in
ext/openssl came under fire from Dmitry. He wrote a terse note:

Tony, Rob Richards and Pierre united to resolve the problems.

Somewhere along the way, Ilia took Rasmus’ advice about writes and appends
and applied a patch to avoid file locks when appending messages to the error
log file. Tony – who was on a bit of a mission this week – later merged
Ilia’s changes to CVS HEAD.

Short version: An end to the flocking troubles?