Zend Weekly Summaries Issue #352

TLK: Type-hinted returns revisited
BUG: pcntl_alarm
TLK: Regarding ext/curl
TLK: ICU extension in the core
TLK: SOAP attachments
BUG: Interbase blob_id
NEW: PHP 5.2.4 RC1
REQ: Self-caching PHP files
CVS: About that mystery extension...
PAT: Dynamic static referencing, openssl and more

TLK: Type-hinted returns revisited

David Duong, following up on the exchange a couple of weeks ago on the same subject, asked the million-dollar question: 'If I, or someone else decided to make a patch for this, and assuming it worked exactly like I described, would it be accepted?'

Stas Malyshev took time to explain that language level is the wrong level to catch type errors such as the distinction between a FALSE or NULL value and an object. It would be better to check for that kind of error in userland code, where the error handling takes place. There is a difference between restricting external input values to specific types and restrictions on internal output value types; the latter comes close to declaring variable types, which have no place in dynamic interpreted languages. Outside anything else, there'd be no way to know from outside a library whether the function being called had a return type restriction or not. All in all, Stas saw no use for the proposed functionality; but he ended by noting that 'others may disagree'.

Larry Garfield and Jeremy Privett both agreed with Stas that any further type checking should be the responsibility of the application code. David argued that his entire proposal had been about interface design; where Stas had written "I'm going to return only type X so I'm making a restriction for myself to return only type X", David's point had been more "Any interface that implements me must provide a method X that takes Y as input and must return Z". One Will Fitch noted that there may well be a place for type-hinted return values in interface design. The core development team remained silent on the matter.

Short version: The problem lies in restricting the restriction.

BUG: pcntl_alarm

Someone named Nico Sabbi wrote in to report a bug. He'd found that pcntl_alarm() fails completely under a multi-threaded Apache worker; the alarm is never delivered. Richard Lynch promptly quoted the relevant manual page, which explicitly states that Process Control functions shouldn't be called in a Web server environment. Core developer Tony Dovgal relies on other places for his documentation; he quoted from the alarm manpage, which explains that the call arranges for a SIGALRM signal to be delivered to the process.

Short version: Bug reports should go to bugs.php.net. (And yes, this was a quiet week.)

TLK: Regarding ext/curl

Daniel Stenberg, primary author and maintainer of the libcurl library, wrote to internals@ asking for help in improving the current situation with documentation and support for ext/curl users. He wrote that there is a lot of confusion among PHP users, which he ascribes primarily to the naming of the curl extension and the mention of libcurl in the php.net documentation. Daniel's experience has been that PHP users believe they are using curl (which is a command line tool) or libcurl itself (which is a library written in C). When those users come to his site looking for further advice, they discover that they are using neither. However, they discover this after coming across the libcurl documentation, which (naturally enough) uses the same option names as those used by the PHP wrapper.

I'd been exchanging mail with Daniel over the previous week, having come across those issues myself in the line of duty, and wrote to fill everyone else in on the situation. I'd looked at the wrapper and libcurl sources, found the extension in much need of some love, and felt strongly that this should be given before the documentation issue is addressed. However, I was about to disappear on vacation, so I'd put this on my personal TODO list pending my return.

Rasmus Lerdorf got involved. He pointed out that the CURLOPT documentation on php.net isn't quite as minimalist as Daniel seemed to believe. Furthermore, the PHP binding is a very thin wrapper on top of the libcurl library, and it makes no sense to hide the fact; the opening paragraph on the relevant page already introduces the extension adequately in his view. That said, he'd be prepared to accept any suggestions for changes that Daniel might make.

Stas also got involved, pointing out that most other extensions in PHP are also named for the underlying library: MySQL, JSON, DOM and SOAP, to name but a few. Those PHP users are using libcurl, after all, albeit indirectly. It would make no sense to rename the extension to php/curl, since ext/curl refers to the filepath for the extension source. Calling it PHP/CURL elsewhere (as Daniel does on his site) doesn't imply 'PHP's curl extension' to a PHP user. In fact, most people wouldn't know what PHP/CURL was. Stas agreed with Daniel, though, that the documentation on php.net could be improved.

Derick Rethans pointed out that calling the extension something unrelated, like the 'mombamoolo' suggestion Daniel had thrown out on a whim, has been tried before with very little success. He cited the satellite and universe extensions, both of which were related to the CORBA library. If you didn't know the extensions themselves, how would you find them?

One Alan Milnes wrote offering help with the documentation, and PHP manual editor Philip Olsen - who is short of active contributors at present - promptly pounced on him.

Meanwhile, Gwynne Raskind had contacted me off-list to say that she was also interested in remedying the problems with the curl extension. We threw a few ideas at one another, and ended by agreeing to start work on it together in September.

Short version: Watch out for the cURL gurls (sorry Gwynne, couldn't resist it).

TLK: ICU extension in the core

Marcus Börger picked up the news about the new ICU extension in PECL rather late. He wrote that he'd like to see this one in the PHP core. Stas responded; he hoped for this too, but reported that there is a lot of work yet to be done. Ext/intl at present has only two functional modules, and needs to have at least seven.

Short version: Coming along slowly.

TLK: SOAP attachments

Lukas Smith wrote to internals@ asking about attachment support in the SOAP extension. He wanted to know if anyone was working on adding the feature, and if so, whether there was an anticipated date for the implementation? If not, perhaps someone had found a way to extend the extension in userland code to provide support for attachments? Lukas wasn't sure whether this was actually the intended approach at this stage.

Short version: The ensuing silence probably means nobody tried this yet.

BUG: Interbase blob_id

Lester Caine, PHP's only Firebird/Interbase user (probably), wrote that he'd been working through the issues of getting his legacy applications to run under PHP 5.2.3. He'd finally tracked down one problem to the wrong kind of return value (0x %i) for a blob_id in the extension, and wanted to know whether the same issue had arisen in other modules?

PEAR's Lorenzo Alberton pointed him to the two existing bug reports about that particular issue (okay so Lester is not PHP's only Firebird/Interbase user). Lester confirmed that bug #41429 describes the problem he's seeing, and disputed the 'bogus' status of bug #41345 on the grounds that it reports the visible effects of that same bug. He ended by asking plaintively, 'Can who ever messed the code up roll it back please?'

Short version: There are better ways to report bugs.

NEW: PHP 5.2.4 RC1

Ilia Alshanetsky, as Release Master for the PHP 5.2 series, announced the availability of the first Release Candidate for PHP 5.2.4 as follows:

As promised two weeks ago, the 5.2.4RC1 was released today and the
sources for the release can be found here:

http://downloads.php.net/ilia/php-5.2.4RC1.tar.bz2
(md5sum: 43e28d2aa55b6c8bcd67da16e24b225a)

Windows binaries should become available in short order as well.

This release has been long in the making and the changelog is a bit
intimidating, so we definitely need a lot of testing for this
release. I would like to ask everyone to give this RC a shot and see
how it behaves with their code and hopefully not find anyegressions.
If you do find any, please let us know. Now that RC1 is out, I would
like to ask all developers to refrain from making any feature
additions to 5.2.4 at this time and only apply bug fixes. I am hoping
to have RC2 released within 2 weeks from now and if it proves to be
stable move onto the final release a week from then. So, if all goes
well we should have 5.2.4 out within a month or less.

One exception to the rule I'd like to make known is Stas' ini system
patch, which I feel we should include, but that's still being
currently discussed. Aside from those, no feature additions, please.

Edin Kadribasic wasn't far behind with his Windows binaries:

http://downloads.php.net/edink/php-5.2.4RC1-Win32.zip
http://downloads.php.net/edink/php-5.2.4RC1-win32-installer.msi
http://downloads.php.net/edink/pecl-5.2.4RC1-Win32.zip
http://downloads.php.net/edink/php-debug-pack-5.2.4RC1-Win32.zip

Uwe Schindler was the first to report any problems. He'd found a couple of configuration issues under Solaris 2.10. Tony managed to reproduce one of them, which Jani Taskinen promptly fixed while muttering under his breath about Solaris in general. Uwe, Ilia and Tony worked together on the second, but were unable to come up with a generic fix for the special case Uwe had fallen across.

Lester, now that he had a bug report to quote, asked for it to be fixed before the 5.2.4 release. Tony asked bluntly why he couldn't just fix it himself, since he's one of the few capable of testing it, and offered a helpful link showing the code changes in CVS since the last known working version. Lester, however, demurred; he had no way to build PHP under Windows, and no time to play around with it either as he was still testing PHP 5.2.3. Surely fixing the bug was the responsibility of someone with CVS access? Tony pointed out that that fixing it would need someone with a Windows build environment, an Interbase installation and the will to help, but that CVS access isn't essential when it comes to posting a patch. That said, he'd been discussing the situation with Marcus and had recently applied a patch that ought to fix the problem. Would Lester care to test? Pierre-Alain Joye added meaningfully that the interbase extension lacks tests, which are written in PHP, and without those in place it's hard to pick up breakages. Lester ignored this, but did at least test Tony's fix and report success there. Lorenzo did likewise, while Lester got into a debate about PDO and Firebird (not for the first time) that went on for some time without going anywhere it hadn't been before.

Meanwhile Scott MacVicar put in an update request for the bundled MySQL library used in the Windows build, and Tony added his own for the t1lib and libtidy libraries.

Finally, one Matteo Beccati wrote that he wasn't sure if he'd found a bug. A broken script throwing a fatal error had altered its message from "Nesting level too deep - recursive dependency?" in PHP 5.2.3 to "Allowed memory size of 134217728 bytes exhausted (tried to allocated 24 bytes)".

He hadn't.

Short version: PHP 5.2.4 feature freeze. Please test.

REQ: Self-caching PHP files

A systems administrator named Constantin B. wrote to the internals list with a request. His team runs PHP across multiple backend servers. He generally uses rsync to synchronize the code; some of backends run entirely on an NFS feed. The problem is that PHP developers like to see their changes live, and the sysadmins didn't want to let them touch 'the holy rsync script'. Constantin's idea was to allow sysadmins to force every require/include call to make a local copy of the included files, perhaps using a new streams wrapper, localcache:/, that could be set using an INI directive.

Rasmus didn't like that idea, and wrote that it didn't sound like something that should be part of PHP at all. A generic file system caching mechanism could be implemented using FUSE, and there are implementations of rsyncfs available that would fulfill Constantin's needs. Constantin replied that he'd expect a simple implementation within PHP to be portable and more readily available for real-world use than 'experimental and too abstract' implementations, but - as Rasmus explained - a portable implementation in PHP would be far from simple. Constantin only needed something that would work with his own setup, and there are ways to resolve the issues there without changing PHP. A simple cron job to check the local files against the remote copy and update files atomically would do the task 'even without any fancy file system layers'. It made no sense to Rasmus to add a complicated caching layer to the language just to avoid the need for a little cron script.

Arnold Daniels wondered whether Constantin's setup couldn't be simplified, since it's pretty complicated as it stands. That said, he recommended DRBD as a tool for low-level file change detection and synchronization, although noting that DRBD can be difficult to set up.

Short version: Best to choose the right tool for the job in hand.

CVS: About that mystery extension...

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

Prior to the 5.2.4 release candidate:

• In ext/session, bug #42135 (Second call of session_start() causes creation of SID) was fixed in PHP_5_2 branch only [Ilia]
• Also in 5_2 only, core bug #42142 (substr_replace() returns FALSE when length > string length) was fixed to work in the same way as substr() [Ilia]
• In ext/xsl, a user specified class can now be returned from transformToDoc [Rob Richards]
• In ext/simplexml, bug #41833 (addChild() on a non-existent node, no node created, getName() segfaults) was fixed [Rob]
• In ext/oci8, bugs #42134 (oci_error() returns false after oci_new_collection() fails) and #42173 (INTERVAL and TIMESTAMP type fixes) were fixed [Tony, Christopher Jones]
• get_loaded_extensions() now has an additional parameter which, if set to TRUE, returns Zend extensions [Johannes Schlüter]
• PDO bug #41971 (PDOStatement::fetch and PDOStatement::setFetchMode causes unexpected behavior) was fixed in the 5_2 branch [Ilia]
• There is now a script to generate tokenizer data from zend_language_parser.h [Johannes]
• In the SOAP extension, bug #42151 (__destruct functions not called after catching a SoapFault exception) was fixed [Dmitry Stogov]
• Zend Engine bug #42119 (array_push($arr, &$obj) doesn't work with zend.ze1_compatibility_mode=On) was fixed (no merge to HEAD required) [Dmitry]
• Core bug #42164 (Internal Sendmail Support is ALWAYS disabled) was fixed [Johannes]
• In ext/pdo_sqlite, bug #41831 (pdo_sqlite prepared statements convert resources to strings) was fixed in 5_2 only [Ilia]

After the release candidate:

• The embed SAPI now has a hardcoded INI, the same as in the cli SAPI [Stas]
• Both snprintf() and spprintf() now have I, I32 and I64 support [Tony]
• An elderly leak in the user filters code was fixed, closing bug #36492 [Sara Golemon]

In other CVS news, Andrey Hristov added a bunch of changes into the mysterious new ext/mysqlnd introduced into CVS HEAD last week. It's now possible to switch statistics collection on or off via an INI setting, among other things.

I tracked down Georg Richter, also of MySQL AB, to get the lowdown on the new extension. Georg confirmed that mysqlnd is in fact not an extension as such - in the same way that ext/libxml isn't - but an entirely new MySQL library, specifically written for PHP. Because it works directly with the Zend Engine, mysqlnd is faster than the external MySQL library currently shipped with the PHP distribution. For the same reason, mysqlnd also saves on memory usage; it doesn't need to copy so many data structures around as does libmysql. Another distinct advantage is the licensing; because mysqlnd is a bundled client library that will ship as part of the PHP source, it's PHP licensed. The extension you'll actually be enabling will still be either ext/mysql or ext/mysqli; only the underlying library will change, where mysqlnd is available and enabled. As a bonus, ext/mysqli will also now offer persistent connections for the first time.

All this has been planned for some time for PHP 6, but Georg explained that there are now plans to backport the native driver (yep, that's what the 'nd' part means) to the upcoming PHP_5_3 branch, and also to add full PDO support there eventually. Finally, Ulf Wendel in particular has been working hard to gain almost complete code coverage in the MySQL related sections of the test suite - almost 90% in CVS HEAD, according to the gcov page - to ensure that the transition to the native library is as smooth as is humanly possible.

Short version: You can find more in-depth coverage about mysqlnd in Ulf Wendel's blog.

PAT: Dynamic static referencing, openssl and more

Richard Lynch offered up a patch - his first ever - along with a new test script. The patch makes pg_convert() in ext/pgsql use PCRE rather than POSIX regex, and also removes a stray closing parenthesis in the PG_TIME pattern, probably fixing an unreported bug there. Poor Richard didn't get any immediate feedback on the list for his efforts.

Etienne Kneuss posted a far more interesting patch, this being his third attempt in five months at extending the language parser to allow dynamically referencing static class members: $classname::foo(), $classname::CONST and $classname::$member. Johannes thanked Etienne for his work, and promptly asked Ilia if the fix could go into the PHP 5.2.4 release. Andi Gutmans intervened to point out that this isn't really a fix; besides, he felt that the Reflection API was the way to approach 'these dynamic things'. In fact, Andi added, he'd like to see an E_STRICT message that recommends that approach to users. A small storm blew up. Arnold Daniels pleaded eloquently for the dynamic constructs, and gained some heavyweight backing from Derick, Lukas, Sebastian and Marcus as well as from other PHP users. Everyone wanted to know why Andi thought the slower Reflection API should be used here, given that it's designed for introspection. Andi agreed to review the patch, given that people felt so strongly about it, and Johannes was able to commit it into the Zend Engine (in both CVS HEAD and the PHP_5_2 branch) later in the week.

Meanwhile, Dmitry had been busy looking into ext/openssl, and produced a patch that extends support for the crypto API. It provides access to OpenSSL digest and cipher functions (via openssl_get_md_methods(), openssl_digest(), openssl_get_cipher_methods(), openssl_encrypt() and openssl_decrypt()), extends the existing functions openssl_pkey_new() and openssl_pkey_get_details() to access the internal values of DSA, RSA and DH keys, provides a new function to compute a shared secret for two DH keys (openssl_dh_compute_key()) and extends some existing functions to support the name of a crypto algorithm, as well as numeric constants. While being similar to Wez Furlong's existing patch in that it implements the OpenID protocol in PHP, Dmitry's version has fewer new functions and works with big numbers as strings rather than as resources. The rest of the team were enthusiastic - particularly Jani, Pierre and Rob Richards, who needed the functionality for XML Sec. Stas found a couple of minor errors in the patch, which Dmitry promptly fixed. Then came a bit of a delay; it seems that Dmitry was holding out for approval for the patch in the 5_2 branch, which wasn't immediately forthcoming because of the timing. Pierre applied some pressure, and the patch eventually went into CVS HEAD only.

While on the subject of ext/openssl, Moritz Bechler wrote to internals@ to remind the team about his CRL patch - feature request #40046 - which could, he noted, also go into CVS HEAD at this point. His most recent copy was available online, although he hadn't updated the report itself; he'd managed to lose his password for that in the interim period. Pierre asked Moritz for a couple of test scripts and examples alongside his proposal, pointing out that this would make it much easier to test the code.

Stas turned up with a patch to improve Apache module configuration handling. His new code introduces ZEND_INI_STAGE_HTACCESS, which should be used for explicitly routing values set in .htaccess to the appropriate handlers rather than (as currently) ZEND_INI_STAGE_ACTIVATE, which routes values set in either httpd.conf or .htaccess. The patch would, Stas noted, provide a proper fix for CVE-2007-3378, with minimal impact on existing extensions. He knew of no extensions that rely on ZEND_INI_STAGE_ACTIVATE, but if there were any, they could easily be fixed. Ilia agreed that this looked like a good solution to the problem, but hesitated a little over introducing a new INI stage in a minor release. Marcus thought it should be left until PHP_5_3 for that reason, but Ilia pointed out that this is a security fix and, as such, really ought to be in PHP 5.2.4, despite the minor BC breakage. Stas promptly applied the patch in CVS HEAD and the 5_2 branch, at which point Stefan Esser picked up on it. He asked whether there were any plans to add a symbol so that extensions could detect support for the feature at runtime, since it was a required security fix and would probably end up being backported to PHP 4. Stas demurred, saying again that he hadn't come across any extensions using the INI access stages in a way that could lead to breakage. However, Stefan's Suhosin extension apparently does use them in that way, even though the check had never worked correctly (and now will). In the event, Stefan decided to simply define INI_STAGE_HTACCESS within his extension where it doesn't exist, to get around the BC issue.

Next up was David Soria Parra, with a patch to make getopt() available on Windows systems. He'd used getopt.c and getopt.h from the FreeBSD libc to implement this, alongside a couple of configuration fixes, and reported that it worked for him on a Windows XP 32-bit machine with a VC 2003 build.

And finally, Richard Quadling offered an untested patch to fix bug #25361, although noting that this isn't actually a PHP bug per se. He followed this with a simpler solution - also untested.

Short version: Lots going on, but nothing new for PAT this week.