Zend Weekly Summaries Issue #336

NEW: PHP 5.2.2 RC1, PHP 4.4.7 RC1
TLK: Application-wide variables
TLK: PHP 6 TODO
TLK: The battle of the ASP tags
BUG: More flocking troubles
TLK: No exceptions in _toString
TLK: ZF Unit Test anomaly
CVS: Ncurses gains HOME and END support
PAT: Interpolated strings

NEW: PHP 5.2.2 RC1, PHP 4.4.7 RC1

Ilia Alshanetsky and Derick Rethans, as Release Masters of the PHP 5.2 and
PHP 4.4 series respectively, announced the availability of the first release
candidates following Stefan Esser’s Month of PHP Bugs:

The focus or this release is twofold. Number one, we are continuing to
stabilize the language, with over 60 bug fixes in the 5.5.2 release.
The second goal was to improve the security of the language through
an internal audit as well as by addressing previously unknown bugs
identified by MOPB. As you can imagine both these goals result in a
rather extensive set of changes, so testing to make sure no new bugs
or regressions were introduced is critical. Therefore, I would like
to ask everyone, over the next few weeks to give this RC a shot with
your code base to ensure there are no problems. I want to make this
release go out as soon as possible given the security improvements
that it brings, with the next RC slated at just over 2 weeks from
today (April 26th) and the final in early May.

If you come across any problems, feel free to identify them by
replying to this e-mail or creating a bug report on http://bugs.php.net.

The first release candidate of PHP 5.2.2 is available for download here:

href="http://downloads.php.net/ilia/php-5.2.2RC1.tar.bz2">http://downloads.php.net/ilia/php-5.2.2RC1.tar.bz2
(262e36555c083d103259fea165faabaf)
href="http://downloads.php.net/ilia/php-5.2.2RC1.tar.gz">http://downloads.php.net/ilia/php-5.2.2RC1.tar.gz
(04e979787670d3d5e1c3e289104b65fa)

The first release candidate of PHP 4.4.7 is available for download here:

href="http://downloads.php.net/derick/php-4.4.7RC1.tar.bz2">http://downloads.php.net/derick/php-4.4.7RC1.tar.bz2
(2ff585134f85fa992af7d953e4645810)
href="http://downloads.php.net/derick/php-4.4.7RC1.tar.gz">http://downloads.php.net/derick/php-4.4.7RC1.tar.gz
(72c25db4e65ae8a985914472403a5f83)

Windows binaries for both, including PECL extensions and debug pack, are
available from href="http://downloads.php.net/edink/">http://downloads.php.net/edink/.

Short version: It’s really important to test this one.

TLK: Application-wide variables

Oliver Block wanted to know whether there had ever been any discussion about
‘application variables’? He explained; while session variables are used to
store values between scripts for a single user, ‘application variables’ would
store values across an entire application for all users.

Someone named Jarisma Chaves da Silva suggested using the file system or
cookies for storage, but Andrey Hristov suggested APC ‘until someone
implements _APP and it gets accepted‘. Richard Lynch, who has been
following internals@ forever, wrote that this has come up time and time again
since the days of PHP 3.0 release candidates. He referred Oliver to the
several solutions in the list archives, as well as MCache and
MemCache, before explaining the problems of implementing
_APP. These include overhead, locking issues, stale data,
replication, and the violation of the basic premise of PHP as a ‘shared
nothing’ architecture that will scale easily. Oliver would do better to go to
the PHP general mailing list, describe his shared data need and see what
people there recommend.

Ádám Bankó wrote that he uses ORM for sharing data between
application processes, and started talking about his GSoC 07 project again (see
weeklies passim).

Tijnema! thought the whole idea would mess up when two users were using the
same scripts on the same Apache. Andrew wasn’t sure, but supposed it could
also pose a security risk. Oliver pointed out that the difference is in the
scope; there shouldn’t be a way to share application-wide variables between
different domains unless the application programmer designed it that way.
Still, he’d been more interested in the rationale behind the missing feature
than in demanding it.

Richard summarized the situation again:

For all these reasons, and more, you're really better off just using
the right weapon for YOUR needs than having something kinda sorta
maybe that might work for you from the PHP Dev Team.

Whether your needs dictate a DB, LDAP, MCache, MemCache, NFS files,
SysV shared memory, custom daemon, or trained squirrels is up to you.

He concluded that PHP doesn’t have _APP in the first place
because it’s really not a very good idea.

Short version: Much ado about nothing.

TLK: PHP 6 TODO

Lukas Smith was cleaning up the href="http://oss.backendmedia.com/PhP60">PHP 6 TODO list, and wanted to
bring up a few of the topics there for review and discussion. href="http://news.php.net/php.internals/28746">It was a hefty list.

Johannes Schlüter was the first to respond. He confirmed that
safe_mode is now gone from CVS HEAD (along with
magic_quotes), but was unsure about the fate of
safe_mode_exec_dir() or the proposed new INI directive,
open_basedir_for_include. He recalled Dmitry Stogov removing
zend.ze1_compatibility_mode from HEAD, but he also recalled Zeev
Suraski reinstating it a couple of months later and asking ‘When did we
decide on that?‘ The new ternary shortcut is admittedly not quite
ifsetor(), but comes fairly close to it, and
__toString() was already fixed in PHP 5.x.
allow_url_fopen and allow_url_include are also in
PHP 5.2.

Marcus Börger thought the zend.ze1_compatibility_mode
reversion had only been in PHP 5.x, and Johannes – on checking – reaffirmed
that it had. Marcus also pointed out that ifsetor() would be
faster than his ternary shortcut, which generates error messages even if the
silence operator @ is used.

Moving on down the list, Andrey Hristov wrote that he’d implemented
persistent zvals at extension level by doing some magic with
reference counting, and it definitely had some disadvantages. The need was to
ask the Zend Engine not to clean up what the zval points to when
it’s cleaning up the zval, and to prevent the user from changing
that value.

Stas Malyshev argued that persisting zvals between requests
would in fact be problematic. A persistent zval wouldn’t be able
to use the regular memory allocator, because it cleans up at the end of a
request, so would need a specialized one to clean up at shutdown. This in
turn means that the Engine would need to know which allocator dealt with the
variable, because mixing allocation types in the same context would cause
problems. All in all, zval persistency isn’t a simple thing to
implement, and Stas wasn’t convinced that the potential uses he saw for it -
persistent resources and caching – justified the expense, particularly as
there are workarounds for both. Could anyone see other reasons for them?
Andrei Zmievski could: persistent zvals would allow objects or
arrays to be used as properties or constants in internal classes, which he’d
been wanting for some time. Stas felt this was do-able if constants weren’t
directly accessible in userland, so long as they were initialized on startup.
Properties were more problematic. Andrei disagreed;
read|write_property handlers could do the work, and besides,
disallowing userland access was an artificial restriction. Stas wanted to
know why Andrei needed ready-made persistent zvals if he had
those handlers? He could construct any zval he wanted once a
property had been read, and do anything he liked once a property had been
written, so what was the point? Andrei stepped back to his original request
for objects/arrays as internal class properties and constants: ‘last time
I looked, it required having persistent zvals‘. Stas asked him for a use
case. Mike Wallner promptly came up with one: initializing a static class
property, or a default property, with an array. He also suggested Stas try
doing

through an extension – the implication being that it isn’t currently
possible.

Back to Lukas’ list. Tony Dovgal commented that more tests would resolve the
problem of BC issues arising from changes in the parameter parsing API. He
was all for inviting IBM to add Unicode support to PDO, ‘as long as it
doesn’t involve signing a legal paper to submit a patch‘.
safe_mode_exec_dir() without safe_mode made zero
sense to him, and he didn’t like the idea of
open_basedir_for_include much either. Tony was willing to take
on the regex work, and asked whether Lukas recalled or had any links to
previous discussions on the subject? When it came to other extension-related
tasks, he was very much against moving any extensions from PECL into
the PHP core – ‘It should be the other way round‘. Derick Rethans,
however, commented that pecl/fileinfo is still scheduled for
inclusion. The reason it hadn’t been fast tracked to PHP 5.x was that the
database needs to be bundled so that the functionality doesn’t rely on any
external files.

Tony noted that Rob Richards had already done some work on
XMLSec (XML security), but he wasn’t sure of its status. He’d
post the patch for removing ASP-style tags ‘in a minute…‘

Edin Kadribasic, who must have some kind of psychic affinity for any mention
of ASP tag removal, responded immediately with a request for Tony to leave it
alone. There was no advantage in removing it, and doing so would break
existing applications. Tony disputed both assertions – of which, more later.

Rob Richards wrote that a XMLSec extension is close to an alpha
release, and provided a
detailed status report on the implementation, its WS-Security
functionality, the implications for ext/soap, and the unsuitability of
axis2 (WSF) as a core extension.

Short version: PHP 6 is coming along nicely, on the whole.

TLK: The battle of the ASP tags

Tony started it. He posted href="http://tony2001.phpclub.net/dev/tmp/kill_asp_tags.diff">a patch to drop
asp_tags in CVS HEAD, saying that if there were no objections he’d apply
it the next day.

Almost 70 emails later, it was evident that five people backed Tony (none of
them on the PHP development team) and over a dozen supported Edin’s protest
(including Ilia, Andi Gutmans, Rasmus Lerdorf, Marcus Börger and
Derick).

As PHP user Nicolas Bérard-Nault commented, ‘Purity in itself may
be an argument, but not in a language that deems itself pragmatic‘.

Short version: The ASP tags won.

BUG: More flocking troubles

Following last week’s single write/append issues, Richard Quadling wrote that
he was still experiencing missing test data, despite Ilia’s fix. His
test shell script:

resulted in 23,973 lines written to the log file; there should have been
26,000. The only explanation he could think of was that the lock was working,
but the write wasn’t waiting for the file to become available.

Ilia replied that the current implementation doesn’t actually use any locks.
It uses direct io, where locks aren’t needed for append operations. Richard
asked bluntly why, in that case, there were missing entries? By this time
he’d managed to reproduce the corruption he’d been seeing in the first place,
by replacing 5000 with 100.

Rob Richards, who was able to reproduce the missing entries (but not the data
corruption), suggested that this was probably now a Windows-only issue. On
debugging, he’d found that no errors are thrown. The file is opened
successfully every time, and the correct number of bytes are written every
time, but whether the write made it into a physical file or not depended on
the load on his system at the time. Adding a lock resolved the problem
completely.

Short version: Nothing about Windows is the same as in any other OS. Ever.

TLK: No exceptions in _toString

PHP user Guilherme Blanco was trying to implement something called href="http://en.wikipedia.org/wiki/Poka-yoke">Poka-Yoke in PHP. As he
explained it, the basic idea was to try to close all doors until only one
door remains open – the correct one. In his project, this translates to
overwriting superglobal variables and delivering the encapsulated
PokaYoke object to the end programmer. The idea was to prevent
the user directly accessing the value by storing it in an intermediary object
containing rules to retrieve the correct type of data, including filter
support. So, $_SUPER would be an instance of the
PokaYoke class, and $_SUPER['offset'] an instance
of PokaYokeDataHolder. $_GET['offset'] in
Guilherme’s project currently calls the
PokaYokeDataHolder::__toString() method. He didn’t want to allow
this, since it might contain unsafe data; the accessor should be
something like $_GET['offset']->getInteger(), for example. In an
attempt to disallow this, he throws a PokaYokeException inside
__toString(), which should work -except that,
unfortunately, PHP doesn’t allow exceptions to be thrown within
__toString(). Guilherme felt strongly that this limitation
should not exist. If something goes wrong and the application needs to know
about it, the application should have control over the means, not the
language interpreter.

Johannes explained that there is no way to ensure that an exception thrown
during a cast to string would be handled correctly by the Zend Engine, and
that this won’t change unless large parts of the Engine are rewritten. He
added that there have been discussions about such issues in the past, and
suggested that Guilherme check the archives.

Guilherme thanked Johannes for the explanation, and noted for the benefit of
future PHP users that __toString() will, strangely enough,
accept trigger_error().

Short version (thanks Guilherme): It’s not Pokemón, ok?

TLK: ZF Unit Test anomaly

Sebastian Nohn wrote to the internals list to say that the Zend Framework
unit test Zend_Date_DateObjectTest passes under PHP 5.2.1, but fails under a
snapshot of the PHP_5_2 branch. He didn’t know whether the problem was a ZF
bug or a PHP bug, and asked if the developers from both projects could come
together to resolve it.

Tony grumbled that referring to a test he’d never seen was less than helpful,
and asked for a short reproduce script. Sebastian obliged:

Tony thanked him, called it a ‘nice catch‘, and asked the list as a
whole what the most correct output for 1 000 000 000 000 000 is when float
precision is 14? Up until recently, PHP had given it as
1E+15, but PHP 5.2.2-dev gives 1.0E+15. Either
seemed okay to Tony – and, apparently, to most of the regulars on IRC – but
there needed to be a firm decision.

Tijnema felt that the second is more precise, but noted that the first has
the advantage of retaining back compatibility. Sebastian, similarly, pointed
out that if there was to be a different behaviour from PHP 5.2.2 on, it
needed to be documented in the change log and release notes. Meanwhile,
Dmitry Stogov had written to explain that the float formatting algorithms had
been changed due to licensing issues, and the new algorithms aren’t 100%
compatible with the old ones. Sebastian asked for more details about this,
but Marcus wrote that nobody should be relying on a given output format for
float values in the first place. Dmitry echoed this advice, saying that it
was bad practice to use echo $float or
var_dump($float) because the output value is reliant on the
system, CPU and INI settings. printf() or
number_format(), on the other hand, would give a deterministic
result.

Sebastian got into an argument with Marcus at this point over the need or
otherwise to document the change of a value that should never be relied upon,
and several others joined in. Somewhere in the middle of it, Sebastian tried
to prove that printf() also gives different results on the same
system, but Tony pointed out that outputting an integer following a
float-to-string conversion was also wrong. Marcus backed down on recognizing
that the discussion had been about the general output format from the start.
He promptly agreed with Sebastian and (by that time) Rasmus that the format
should remain the same, particularly since Tony had now produced a patch to
fix it.

Short version (thanks Marcus): Persistence sometimes pays dividends.

CVS: Ncurses gains HOME and END support

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

• Zend Engine bugs #41026
  (segfault when calling self::method() in shutdown functions) and
  #41075 (memleak when creating default
  object caused exception) were fixed [Tony]
• Core bugs #41037
  (unregister_tick_function() inside the tick function crashes
  PHP) and #40931
  (open_basedir bypass via symlink and
  move_uploaded_file()) were fixed [Tony]
• An integer overflow in ZEND_SIGNED_MULTIPLY_LONG() was
  fixed [Jani Taskinen]
• In ext/pdo_oci, bug
  #41043 (pdo_oci crash when freeing error text with persistent connection)
  was fixed in the 5_2 branch [Tony]
• In GD, bug #41048 (PHP 6
  Segmentation fault issue) was fixed [Scott MacVicar]
• Support for the HOME and END keys was added
  to ext/ncurses in the 5_2 branch [Georg Richter]
• TSRM bug #41063
  (chdir doesn’t like root paths) was fixed [Dmitry]
• Reflection bug #41061
  (“visibility error” in ReflectionFunction::export()) was fixed
  in the 5_2 branch [Johannes Schlüter]
• In ext/json, bug #41034
  (json_encode() ignores null byte started keys in arrays) was
  fixed in PHP_5_2 branch [Ilia]
• The core sprintf() utilities now have support for
  %I64(u|d) [Tony]
• In ext/date, bugs #40290
  (strtotime() returns unexpected result with particular timezone
  offset), #39965 (Latitude and
  longitude are backwards in date_sun_info()) and href="http://bugs.php.net/39416">#39416 (Milliseconds in
  date()) were fixed, and the timezone database was updated to
  version 2007.5 [Derick]
• gdImageFilledArc with large angles no longer eats CPU in
  any current branch of PHP [Pierre]
• In ext/pdo_mysql, bug
  #40935 (pdo_mysql does not raise an exception on empty
  fetchAll()) was fixed in the 5_2 branch [Ilia]

In other CVS news, Tony intervened when a correction for an existing
pack/unpack test for a bug under 64-bit systems
broke the test under 32-bit Linux machines. Brian Shire was already aware of
the problem, but wasn’t sure yet why Linux was affected and nothing else.
Could it be Darwin specific, and if so, should he simply remove that test for
Darwin for now? Tony agreed that it wasn’t such a critical problem if the
problem only existed on Darwin/Intel machines, but went off to test for
himself under Darwin/PPC. In the meantime, Brian reverted his changes pending
further investigation.

Tony applied a fix in ext/mysql for href="http://bugs.php.net/41083">bug #41083 (mysql_ping()
requires MYSQL_OPT_RECONNECT to be set since MySQL 5.0.13) that
Andrey Hristov took issue with. Andrey pointed out that there were reasons
for disabling automatic reconnection; for example, a broken connection would
mean lost transactions and connection-specific variables. It should therefore
be left to the application to decide whether to reconnect or die, and Andrey
asked Tony to revert his changes – which didn’t work for MySQL versions
between 5.0.3 and 5.0.13 anyway – and mark the bug report as bogus.

Tony simply pointed Andrey to the PHP documentation, which states:

mysqli_ping, mysqli->ping() — Pings a server connection, or
tries to reconnect if the connection has gone down.

He also noted that the bug couldn’t be fixed for those particular
versions of MySQL because there had been a MySQL API breakage that precluded
it.

Andrey argued that the fix was wrong anyway; reconnect should only be set for
the duration of the mysql_ping() call, assuming reconnect was set
to off in the first place. (He wasn’t too clear in his language here, which
led to some confusion on Tony’s part.) He also felt strongly that the
documentation should be fixed to say that mysql_ping() won’t
reconnect if the INI directive mysqli.reconnect is set to
off, with libmysql version 5.0.3 and up, full stop.

Towards the end of the week, Derick quietly opened a number of new CVS
accounts with a short message: ‘Welcome GSoC people.’

Short version: Some confusion over the intended behaviour of mysql_ping().

PAT: Interpolated strings

Someone named Andrea wrote to internals@ to highlight the fact that href="http://bugs.php.net/38236">bug #38236, although fixed in the
PHP 5.x code base, was still present in PHP_4_4
branch. S/he had adapted and tested the fix used in the PHP_5_2 branch, and
reported that all seemed well. Stas subsequently applied the patches.

Patch king Matt Wilmas came up with href="http://news.php.net/php.internals/28744">a very long explanation
for a patch bringing ‘a major optimization for heredocs/interpolated
strings‘. It was such a long email that it defeated its purpose – nobody
had time to read it.

Short version: Short and sweet wins the day.