Zend Weekly Summaries Issue #334

      Comments Off on Zend Weekly Summaries Issue #334

TLK: EG(class_table)
TLK: Hacker’s guide?
TLK: GSoC 07 [yet again]
TLK: GSoC 07 – dbobj [continued]
TLK: Clashing classnames
TLK: More GSoC 07
CVS: Pipe/socket server support for win32/FastCGI
PAT: Jani’s back on the case

TLK: EG(class_table)

Sebastian Bergmann had been looking at the way classes are stored in the
executor globals (EG) class table. He wanted to know if he could
rely on child classes always being stored after the parent class,
because – if so – he could rely on the organization of the output of

Stas Malyshev explained that this isn’t so much a written rule or convention
as a logical outcome of the parent/child relationship. You can hardly define
a child class of a parent that doesn’t exist… so, unless ‘some very
nasty extension
‘ defines classes in a different order, it always falls
out this way.

Andrei Zmievski asked about classes defined in an extension loaded using
dl(), but Stas pointed out that any class would be appended to
the table in the same way; dl() is irrelevant here. If a loaded
extension defines classes derived from existing classes, the child will
naturally come after the parent. If the extension defines both the parent and
child class, then – theoretically at least – it could be done in such a way
that the child class would enter the class table before the parent. However,
in Stas’ opinion, that would be a ‘quite broken‘ extension.

Short version: After, yes – immediately after, no.

TLK: Hacker’s guide?

Would-be GSoC 07 participant Ian Young wrote to internals@ enquiring about
the ‘PHP hackers guide’ referred to in the GSoC planning page on php.net.
He’d been unable to find any such guide in the official documentation, and
wondered if it were simply a reference to the README files included in the
source code? Tony Dovgal thought it was probably an oblique reference to the
(largely outdated) Zend API
, but Nuno Lopes corrected him; he’d added the line with the
full intention of writing one, which is why it still says “TBD”. He hoped to
have something together in time for GSoC 08, but there’s nothing out there as
yet. In the meantime, Ian should ask his questions on the internals list or on

Sara Golemon later provided a list of the resources currently available:

  • http://www.php.net/zend
    Official documentation. Not as well maintained as the userspace portions of
    the manual, but still very useful.
  • http://www.zend.com/php/internals
    – Walkthrough driven, focuses on extension development, but includes some
    “general internals” information in places.
  • Extending and Embedding PHP (ISBN: 067232704X) – Expanded version of http://www.zend.com/php/internals
    , covers more of the sticky bits of navigating the PHPAPI.
  • Advanced PHP Programming (ISBN: 0672325616) – Primarily aimed at
    userspace development, but has a large section on extension development and
    working with the APIs exposed by PHP.
  • The internals mailing list (internals at lists dot php dot net)
  • The PECL development mailing list (pecl-dev at lists dot php dot

– along with the usual disclaimers for those resources written by herself.

Short version: Use the source, Luke!

TLK: GSoC 07 [yet again]

One Davi Vidal wanted to expose his project idea, but wasn’t sure how to do
that. Tijnema! pointed out that the deadline had already passed. It didn’t
stop Davi writing about his plans for a Web 2.0 webmail application
similar to gmail‘. Alexey Zakhlestin wondered what on earth this had
to do with PHP, and Davi backed down on realizing that GSoC isn’t really
there to pay Web developers for the summer.

Meanwhile, Thomas Koch was upset to discover that the status of his PHPUnit
related application had been set to ‘ineligible’ some minutes before the GSoC
deadline, with no comment and no name given. Who had kicked his project out,
and why? Sebastian Bergmann wrote back promptly to explain that ‘ineligible’
– in GSoC terms – simply means that no mentor should vote on it. At least,
that was the way he understood it, which was why he’d altered the
setting. He added that there had been a number of student applications for
that particular project idea, and Thomas’ wasn’t the best.

Mark Wiesemann cited Google’s
own interpretation
of ‘ineligible’, which clearly states that it’s
intended for use only with applications that are spam. Lukas Smith came to
Sebastian’s defence, explaining that the GSoC mentor interface is ‘utter
‘ when it comes to weeding out less strong applications (I can vouch
for this). The team were simply using the only tools available to achieve
their aim.

Mark, however, pointed out that it was possible Google itself would mark any
application from Thomas as spam next year because his 2007 application was
marked as such in their eyes. Lukas agreed that he had a point there, and
promised to provide feedback to Google on the matter.

Short version: There’s no nice way to give GSoC project assessments currently.

TLK: GSoC 07 – dbobj [continued]

Jeff Moore, picking up late on the ORM discussion, wrote that he felt the aim
of creating a standard ORM tool for PHP was too big a project for GSoC. He
suggested a smaller, related project – addressing core object serialization
issues across multiple formats. When it came to an ORM tool, however, he felt
that an implementation in C would be far less flexible than one written in
PHP. It might be a better idea to profile the existing PHP ORM solutions and
implement common denominators or key functions in C, leaving the rest to user

Ádám Bankó pointed out that, the submission deadline having
passed, he couldn’t reasonably change his project aim at this stage. That
said, he felt that rethinking the serialization support in PHP would be a
good project of potential benefit for many. However, he concluded, ‘don’t
wait for me to do it, because I won’t

He disagreed with much that Jeff wrote – particularly the idea of
array/object conversion – but conceded that many would agree with Jeff’s
point about having only a very basic common-denominator ORM implementation in
C. Ádám ended by noting that he has already explained a great deal
about his goals and the way he plans to achieve them, on this very list. If
Jeff could see any technical problems with his proposal, he shouldn’t
hesitate to share them.

Short version: Once it’s done, it’s done.


Sebastian, picking up on a comment Tony had made when fixing some minor bug
in the milter SAPI, wondered why on earth it was still part of the PHP core.
Can SAPIs not be moved into PECL?

Tony wrote rather bitterly that he’d been talking about this for years. The
problem is that there is no pecl install equivalent for SAPIs,
so moving them to PECL would effectively mean dropping them altogether.
Personally, he finds it hard to care about ‘some unused and unsupported

Daniel Rozsnyo suggested a special place in CVS for abandoned and unsupported
code, but Tony pointed out that PECL, as often as not, is used for exactly
that. He cited a number of extensions that have been added or moved into PECL
and then never released.

Short version: Fear the wrath of Wez when you speak such thoughts!

TLK: Clashing classnames

Mauro Infantino wrote to internals@ asking for a viable solution to a
recurring problem – the naming of classes. Years ago, his team built a
framework. To his everlasting regret, they used non-prefixed class names
because we thought it was more elegant‘. That framework, over the
years, has been installed alongside each of their internal applications, in
hundreds of servers. Hundreds of applications reference those class names.
And now they want to upgrade from PHP 5.1 – which is no longer maintained –
to PHP 5.2.

It wasn’t possible for them to modify and test the entire code base just for
a point upgrade, particularly given that they were likely to have to do so
before upgrading to PHP 6. So what Mauro needed now was a workaround for the
problem that caught them out without warning – the core DateTime
class. Could the team add an INI setting to prevent that class definition?
Even an undocumented one? He would send the patch if needed.

Recognizing desperation when he sees it, Rasmus Lerdorf suggested Mauro
should simply rename the class in ext/date/php_date.c. All that’s
needed is to find the line

INIT_CLASS_ENTRY(ce_date, "DateTime",

and put whatever name you want there.

Short version: Remember, this particular class was renamed to avoid a clash…!

TLK: More GSoC 07

David Duong, who presented his HyperWiki project last week as an idea for
GSoC 07, wrote to say that he’d submitted something completely different
instead, called ADatabase. It’s a database abstraction layer that will either
translate or emulate a subset of standard ISO SQL statements, intended for PHP
5.1 and up. The biggest part of the project would be driver development,
initially for MySQL, SQLite, PgSQL and MSSql. David wrote that he would
appreciate any comments or suggestions.

Finally, one Adrian Nita of Bucharest wrote to say that he’d applied –
hopefully not too late – to work on the ‘Refactory of Jaws for PHP 6’
proposal on the GSoC planning list.

Short version: The clans are gathering…

CVS: Pipe/socket server support for win32/FastCGI

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

  • Core bug #40915
    (addcslashes unexpected behavior with binary input) was fixed
    across all current PHP branches [Tony]
  • In ext/simplexml, bug
    (autocreating element doesn’t assign value to first node) was
    fixed [Rob Richards]
  • Two mail() security fixes were made in the PHP_5_2 and
    PHP_4_4 branches following Stefan Esser’s reports MOPB-33-2007 (message
    ASCIIZ byte truncation) and MOPB-34-2007 (header injection through
    subject and to parameters) [Ilia Alshanetsky]
  • Memory leaks were stemmed in the milter SAPI, fixing bug #40392 [Tony]
  • The FastCGI SAPI now supports external pipe and socket servers under
    win32 [Dmitry Stogov]
  • In ext/oci8, PECL bug #10194 (segfault in Instant Client) was fixed [Tony]
  • Core bug #40921
    (php_default_post_reader crashes when post_max_size
    is exceeded) was fixed in the PHP_5_2 branch [Ilia]

In other CVS news, a patch of Ilia’s to add a lock to the
error_log file (fixing bug
) was challenged by Rasmus. He argued that there should be no need
for a lock during a single write in append mode.

Tony’s fix for bug #40586
(_ENV vars get escaped when magic_quotes_gpc is on)
in the PHP_4_4 branch was reverted at Derick Rethans’ request.

Short version: Hopefully this will be the end of the MOPB fixes.
Thanks Stefan!

PAT: Jani’s back on the case

Richard Quadling chased up on his offering last week to prevent the console
window from springing up under Windows when CLI scripts calling external
applications are run (bug #33664).
Stas later resolved the bug in a different way.

Having survived Afghanistan, Jani Taskinen found himself fiddling with PHP
source code again. He came up with a couple of patches this week. The first
would allow get_declared_(classes|interfaces)() to return the
user and internal class/interface data as an associative array, with
internal and user keys (passed as an optional
parameter) determining the type of return value. Jani felt that offering a
fine-grained return value would make the functions more consistent with
similar ones, such as get_defined_functions(). Marcus suggested
that it might be better to use a flag to offer the return value options of
[internal/user], [user], [internal] or [[internal], [user]].

Undaunted, Jani made a second offering introducing a new configuration
option, --with-config-file-path, which allows the name and full
path of any file to be set as the PHP INI file during the build. Nobody
seemed very sure whether he was joking or not.

On the subject of jokes, Andrew Brampton filled the gap on April Fool’s Day
with his well-received British Patch:

Short version: It’d have been funnier in Welsh.