Zend Weekly Summaries Issue #217

      Comments Off on Zend Weekly Summaries Issue #217

TLK: Of chickens, eggs, and Apache 2 (again)
TLK: realpath_cache revisited
TLK: Startup order
REQ: PHP 4.3.11 and 5.0.4
FIX: Shared libraries
TLK: Shutdown order and dl
FIX: php_hostconnect
TLK: extract issues
TLK: win32 build issues
TLK: Geeks and superheroes
PAT: Internet family

TLK: Of chickens, eggs, and Apache 2 (again)

Hans Zaunere of New York PHP evidently celebrates Christmas. We were almost into
the New Year before he responded to Rasmus Lerdorf’s contention that Apache 2
pre-fork wouldn’t be recommended until the majority of PHP users switched to using
it. Hans retorted that this presents something of a chicken-and-egg situation;
production sites won’t make the move until PHP recommends Apache 2 in some way,
unless there were some killer feature in the new API. He also made the point that
the entire AMP platform is on the move, with significant new versions of all
components (Apache, MySQL, PHP) and a shift to 64-bit support. He suggested that
using some of the new Apache 2 features could be a step towards the next generation;
allowing PHP to reach into Apache 2 to a level similar to that of mod_perl could
provide significant new features, such as having PHP control URL rewriting and

Marc Richards wrote that it wasn’t quite that simple: the users feeling the need
for Apache 2 just don’t happen to be on the PHP development team, and the issue
won’t be addressed until this is no longer the case. He added that he sees some
value in staying with the product under active development. For example, Apache 2’s
new LDAP and WebDAV features won’t be available until Apache 2.2 is released, but
upgrading the server from Apache 1.3 at the same time as setting up those features
would be more painful than staying current.

Rasmus asked why we should try to push PHP users away from a proven, stable
platform. He also made the point that the apache_hooks SAPI – which allows the
functionality described by Hans – has been available for Apache 1 for some years,
and isn’t actually a very popular feature.

Hans replied that the reason he wouldn’t recommend apache_hooks to clients is
that the SAPI is still marked EXPERIMENTAL. He felt, though, that it had the
potential to be as popular as mod_rewrite.

George Schlossnagle intervened to explain that apache_hooks is probably
non-functional at present, adding that the reason making it work properly is low on
his TODO is that it doesn’t have many users. (More chickens and eggs, eh?) Rasmus
backed him, saying that a version of apache_hooks based on Apache 2 wouldn’t be
magically non-experimental, as the internal PHP code would be mostly the same.

However, Hans’ chief point was that the killer solution or feature would drive
PHP users’ adoption of the new server. He gave anecdotal evidence of early
experiments with PHP 4/Apache 2/threaded in production, saying that it ran fine for
him, but he’d returned to Apache 1.3 simply because there was no compelling reason
to live on the edge. ‘A chicken-and-egg problem, but perhaps it’s time to think
about incubating the egg

But which egg?‘ asked Rasmus, making the point that the next-generation
killer web server might not be from the Apache stable at all.

Short version: The grass roots are stirring. But actually Joe Orton’s
working steadily on the Apache 2 SAPIs :)

TLK: realpath_cache revisited

Rasmus, while auditing the realpath_cache code in the TSRM (Thread
Safety Resource Management) directory, found a return check in a
REALPATH_CACHE clause that appeared to have no good reason for
existence. He wrote in to the internals list asking whether something had been
altered that made the check redundant.

Andi Gutmans replied that it did indeed appear redundant, and promised to look
into it. The Zend team did so, and the check was removed later by Dmitry Stogov.

Short version: Minor optimization for realpath caching.

TLK: Startup order

Moriyoshi Koizumi wrote to the list, saying that the order in which activation
functions were called on request startup:

  1. zend_activate()
  2. sapi_activate()
  3. php_hash_environment()
  4. zend_activate_modules()

didn’t make a lot of sense, given that
php_hash_environment() can call initialized input handlers prior to the
modules. Some settings stored in the module globals leak over requests as a result,
leading to recent reports from Japanese users of a fatal bug in his mbstring

Is there a good technical reason behind the ordering?

Andi explained that the sessions module needs COOKIE arrays to be
initialized prior to activation, which was the chief reason for the separation of
zend_activate and zend_activate_modules.

Short version: Robbing Peter to pay Paul.

REQ: PHP 4.3.11 and 5.0.4

Alan Knowles wrote asking whether there were any updates on the release schedule
for PHP 4.3.11 and 5.0.4. He was getting daily bug reports about broken code with
both 4.3.10 and 5.0.3.

Andi responded, saying that he and Ilia Alshanetsky, as the respective Release
Masters, had agreed to roll the fixed versions at the beginning of January. This
decision was taken because a lot of people were on vacation over the Christmas
period, meaning that there weren’t many beta testers around. However, it was
possible that the first release candidates could be rolled next week if there were
no pending patches.

Rob Richards immediately announced a pending patch for 5.0.4, but said that
before applying it he needed an answer as to whether or not
zend_fetch_property_address_inner and
zend_fetch_property_address were going to fall back to
read_property when get_property_ptr_ptr returned

Andi gave a short update:

Short version: Blame Christmas.

FIX: Shared libraries

Rasmus wrote again, saying that the version of ltmain.sh in cvs.php.net
was from an old version of libtool that isn’t compatible with newer versions.
Specifically, shared_ext was not defined, leading to libraries being
generated without the .so extension. He was working around the problem by
deleting the file and forcing his local libtool to generate a replacement
ltmain.sh, but wondered if there was any reason for not either providing a
newer version of ltmain.sh or using buildconf to force the local libtool to
be used.

Jani Taskinen responded, saying that the reason for bundling libtool was to take
one variable out of the equation when it comes to different build environments, and
the libtool generated by the bundled ltmain.sh should always be used. He
asked for a fuller description of Rasmus’ problem.

Rasmus explained that, on both FreeBSD and Linux, libphp4 and all shared modules
were being created without an extension. This was the cause of at least one bug report, and
possibly also the root of the more frequently reported issue whereby
libphp4.la was created without there ever being a libphp4.so.

Paul Querna backed up Rasmus; on FreeBSD 5, running buildconf from a CVS snapshot
would make install libphp4 instead of libphp4.so. Gareth Ardron had
also come across the issue at various times, with both PHP 5 and PHP 4.

Short version: Libtool confusion is leading to installation problems on
some platforms.

TLK: Shutdown order and dl

Alan wrote in again, this time complaining that he was seeing segfaults at
shutdown when using dl() with his extension. It worked perfectly when
the extension was loaded from php.ini, or if he compiled the debug version.
Was this a known issue, and was it fixable for CLI usage?

He added his own guesswork: possibly it was because modules were being destroyed
before the objects created by those modules. A workaround might be to check for
sapi == cli, skipping zend_deactivate_modules() and simply
calling sapi_deactivate() in the main.c function

Wez Furlong sympathised:

Andi responded to this, saying that he couldn’t quite remember the full
explanation but he believed it to be a chicken-and-egg problem.

Short version: Some egg! Some chicken!

FIX: php_hostconnect

Alex Torkhov, while trying to port Sara Golemon’s new PECL extension libssh2 to
Windows, found that it wouldn’t link unless he defined
php_hostconnect() as a PHP_API function in
main/php_network.h. Why wasn’t it already defined that way in 4.3.10? (Note:
network functions are completely streams-based in PHP 5.)

Alex also reported this as bug #31403,
and Jani the bug-slayer promptly went in and fixed it.

Short version: The win32 port of libssh2 is on its way.

TLK: extract issues

Moriyoshi Koizumi wrote in again to say that he was looking into three related
bug reports about extract(), namely bug #25708, bug #29493 and bug
. He’d found that the problems were caused by an unavoidable
zval_separation on sending arguments to the function, for which he
could find no workaround. He’d got stuck over a couple of partial fixes:

Moriyoshi asked for suggestions.

Marcus Börger saw Moriyoshi’s problem as being a good reason for implementing
pass_as_const – something he’d wanted to do while working on array
optimization back in the autumn. This pass type wouldn’t touch the passed variable
at all, and would be compatible with temporary variables. He asked what Andi thought
of the idea.

Moriyoshi felt that this feature would become necessary, and added that it would
also make the output of debug_zval_dump() more reliable than it
currently is, as implicit separation of zval instances gives bogus
reference counts there.

However, Andi replied that there were good reasons not to implement the new pass
type, saying that the earlier attempt had made the code base more complex without
bringing any real benefit. He didn’t feel that making debug_zval_dump()
reliable was a good enough reason to add it now, either.

Moriyoshi said that, this being the case, we’d better get rid of
extract(EXTR_REFS), which could never work as advertised. However, he
wondered whether it would also be considered too complicated to introduce a new
argument modifier which would pass non-variable scalars to the function as normal,
but pass variables as though they were forcefully referenced.

Short version: pass_as_const is spurned again.

TLK: win32 build issues

David Strauss wrote to the internals list detailing a small problem in
cgi_main.c that prevents it from being compiled properly with certain
compilers. Basically socklen_t is defined differently in php.h
and in WS2tcpip.h, both files being included (effectively) in
cgi_main.c. php.h defines it as an unsigned integer, whereas
WS2tcpip.h defines it as signed. On David’s VectorC compiler, this leads to a
terminal error. On the snaps.php.net build log, it leads to a ‘benign redefinition of
‘ warning, repeated 58 times.

Shouldn’t the lines in php.h be altered to something like:

# ifdef PHP_WIN32
typedef int socklen_t;
# else
typedef unsigned int socklen_t;
# endif

Wez replied, saying that only the MSVC compiler and libc were supported under
Windows, and that changing that particular typedef was ‘slightly tricky’.
He’d left it as it now is due to compilation issues when using older versions of
MSVC and the platform SDK, this redefinition being benign.

However, if David could test his proposed change on MSVC 6.0, VS.Net and VectorC
and make sure that everything still worked, it would be possible to commit it.

Frank Kromann volunteered the information that adding:

typedef int socklen_t;
#define HAVE_SOCKLEN_T 1

to main/win95nt.h kills these warnings with Visual Studio 6.0.

Short version: If King Wez calls it ‘slightly tricky’, it’s probably impossible.

TLK: Geeks and superheroes

Georg Richter, Zeev Suraski, Antony Dovgal, Jani, Ilia, Andi, Moriyoshi, Rasmus,
Wez and Rob all exhibited super-geekdom by continuing to tweak PHP source over the
Christmas period.

The more interesting moments included Ilia’s attempt to turn off the
expose_php ini setting by default, on the grounds that it was ‘a
total waste of bandwidth/cpu
‘; Andi promptly reverted his change, pointing out
that the statistics generated by this information were used by Netcraft, php.net and
PHP advocacy websites, and that even Microsoft had now copied the idea. He asked
that Ilia discuss ‘such significant changes‘ on the internals list before
committing them. Ilia responded that the server information could be viewed as a
security risk, saying that it made it too easy for anyone trying to identify
exploitable PHP servers before attempting to compromise that server. Andi retorted
that this was true of any web server information, and that sites that really didn’t
want to expose the fact that they were using PHP could use .html, turn off error
reporting and set expose_php to off. He felt that it should be left to
the user to do so.

Short version: Security freaks, take note.

PAT: Internet family

Only one patch this week: Nicolas Bérard Nault sent in a new function,
inet_getaddrfam(), to get the internet family of an address. The
function will return AF_INET or AF_INET6, or
FALSE if the address is incorrect.

Nicolas asked for comments, but has received none to date.

Short version: inet_getaddrfam() is sitting in the PAT directory awaiting review.