Zend Weekly Summaries Issue #367

December 31, 2007

Uncategorized

TLK: Visual Studio 2005 (again)
TLK: PDO performance
TLK: Optional scalar type hinting
RFC: Accessible compiler info
TLK: Question about superglobals
REQ: Bring back allow_call_time_pass_reference
TLK: Restore output buffer in case of exceptions
CVS: Oracle 8 support dropped
PAT: Etienne joins the clan; str_split patch

11th November – 17th November 2007


TLK: Visual Studio 2005 (again)

Elizabeth Smith revisited the topic of providing PHP builds created with VS
2005. She knew it would be impossible to provide only VS 2005 builds
until Apache – and various other third-party libraries – made the move, since
the runtimes will crash and things will blow up‘. However, she would
like to provide non-threadsafe VS 2005 builds for Windows users. The process
needed to be well planned; ‘PHP users are notorious for not testing things
that aren’t available right on the downloads page, and people at Microsoft
have made the request that binaries be made available on the php.net
site.
‘ Elizabeth was prepared to create VS 2005 builds of the third-party
libraries that link into PHP to avoid runtime issues that would otherwise
originate from them, but noted that the actual problems would remain unknown
until there is widespread testing. She also recognized that this would be
a big job‘, but felt it important for php.net to be proactive about
the migration.

Stas Malyshev has been compiling his work builds with VS 2005 for some time,
and wrote that he hadn’t come across any problems. However, VS 2005 binaries
are linked against ‘libraries which may not be installed by default
(read: a different C runtime), and in some cases users would need to install
href="http://www.microsoft.com/downloads/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee&displaylang=en">this
package for them to work at all. Elizabeth, who has been quietly providing
unofficial VS 2005 and 2008 builds of PHP for a while, acknowledged this
point. Although she personally hadn’t hit any runtime issues, she was aware
that others had. However, official php.net builds were needed so that people
could start testing and/or using them on a broader scale. Stas was all for
it, commenting that VC8 is a better compiler (than VC6).

Andi Gutmans also backed the proposal, noting that there are actually
VC8-specific optimizations in the Zend Engine. He added that he’d recently
had a similar discussion with Edin Kadribasic and John Mertic, and both had
been supportive in principle. He suggested that Elizabeth contact Edin
directly and offer her assistance.

Then I butted in. One of the disadvantages of running late with these
archives is that threads long forgotten by everyone else are right in front
of me. I’d only recently covered href="http://devzone.zend.com/article/2741#Heading6">the ‘let’s kill off
VC6′ discussion from October, so I probably came across as unhinged
here… whatever. It made no sense to me to lose the “runs on your toaster”
advantage of the lowest common denominator, or to be tied to shipping the C
runtime, or to drop native support for Windows systems pre-dating XP (as per
the October discussion). I believed that multiple CRT versions of PHP on the
download page would lead to user confusion; even Edin’s NTS option had proven
confusing for some. The only thing that made sense was offering test builds
(as per the current discussion). To that end, the only real issue was that of
incompatible third-party libraries, since PHP itself has a CL
build system that is known to work across all current MS compiler versions. I
wasn’t at all happy about php.net being pushed into distributing our own
builds of third-party libraries just so we could continue to support Windows.
However, if we were going to do that, we should set up edge case tests in the
known problem areas (multiple I/O calls, data structures passed around), and
run them over binaries built with the full range of compilers. That
would be genuinely useful.

Stas likes a good argument too. He pointed out that the l.c.d. compiler is 10
years old and produces slow code, whereas VC8 is the best available today. He
wasn’t against keeping the VC6 build for the official PHP 5.x releases, but
felt that snapshots were a good candidate for test builds. Besides, all the
platforms that natively include the version 6 CRT are able to support the
version 8 CRT library… I asked if Stas had read to the end of my post. All
I wanted was to find a way of upgrading and testing that wouldn’t alienate
the PHP user base. Having more than one official build would mean having to
explain ‘C runtime’ to practically every PHP newbie, which didn’t bear
thinking about, whereas third-party “experimental” library collections built
with the various compilers would be far less intrusive. Stas agreed it would
be useful to have those (or at least, two sets – VC6 and VC8), but he’d like
the PHP binary itself to be made available. I saw limiting ourselves to two
sets as shortsighted, particularly as we’d need the raw code for all those
third-party libraries in order to build them in the first place. Stas and I
got sidetracked into a pointless discussion about when would be the right
moment to assume majority native support for VC8 binaries (who can say?),
which kept us both entertained until Elizabeth picked up her mail.

I’d definitely confused her by combining my responses to two threads, and
more so because Elizabeth’s initial assumption was that anyone not 100% for
Microsoft must be 100% against them. She made the valid complaint that most
of the open source libraries linked by PHP have Windows support ‘as an
afterthought
‘, but ascribed this to a ‘negative attitude‘ on the
part of the open source movement. Elizabeth agreed that compiler-specific
library collections would be useful; in fact, she’d already been working on
this to some extent. All she needed was a test area… the snaps box perhaps,
or the gcov site? Another option might be for Microsoft to
distribute the builds on their own site and php.net to provide a link. Was
there a problem with that, or were Microsoft being held to a different
standard than other platforms? She ended her post with the observation that I
obviously had an issue with the Microsoft runtime changes; would anyone
other than myself or Stas care to weigh in?

Rob Richards did, to point out that the tried and tested VC6 builds aren’t
going anywhere in a hurry. However, he agreed that an upgrade would
eventually be needed, and that there would need to be serious testing
beforehand. It made sense to provide a download, even if it was only updated
now and again, and he really didn’t see what the problem was with that.
Richard Quadling wanted to see some actual performance statistics, but -
assuming VS 2005 really did offer major benefits – believed there’d be no
problem in bundling the runtime with the PHP distribution, given that Windows
users generally prefer MSI installers.

I explained to Elizabeth about the two threads thing, and asked if anyone had
actually suggested linking to Microsoft? The snaps box idea struck me as a bad
one, since anyone reporting a PHP bug is sent there to test the fix. The QA
site, on the other hand, was intended for testing stuff; if there must
be differently-abled binaries, why not distribute them from there? There was
no reason the QA site couldn’t be linked from either the php.net home page or
the download page, or both. As for building third-party OSS libraries from
scratch – I have plenty of experience with that, and offered to help
Elizabeth with her efforts when I get time.

The culture clash was more difficult. I suggested talking to the open source
teams involved without making assumptions about their attitude, and pointed
out that the only thing preventing Microsoft from rolling their own
distributions was the fact that they would then have to support them. Whereas
an open source team can guarantee support for as long as there is active
community interest in a project, companies have different sets of interests
and resources, and very different ideas about “long term”. Then I messed up
by announcing to all and sundry that Elizabeth was actually being paid by
Microsoft to get the new build onto the official PHP download page, which I
believed to be true at the time. It proved not so, and I ended up withdrawing
that statement and apologizing to both parties. Back on track, Elizabeth
amended her initial request for space on the official download page and
agreed that the QA site plus prominent links would be fine. Her
sticking point had been my recommendation that only third-party libraries
were provided. At this stage, I happily agreed that we’d reached a resolution
we could both live with.

Mario Brandt wrote to confirm that compiling Apache and PHP 5.2.4 with VS8
had boosted performance for him. However, he disputed Richard’s assertions
that PHP users would prefer an MSI and bundled runtime. Mario proved to be
one of the many Windows-based developers who dislike the way MSI installers
take control over the environment; to him, a zipped bundle was much easier to
install, test and delete. Marcus Börger asked if Mario had any figures to
back his performance claims, and Mario helpfully href="http://news.php.net/php.internals/33157">provided some. Richard didn’t
see how Mario could possibly deal with a new CRT for PHP that way, and gloomily
foresaw hordes of users failing to download the new runtime and complaining
that their copy of PHP didn’t work. I retorted that finding a way to avoid
that was precisely what this entire discussion had been about. Pierre-Alain
Joye pointed out that users will complain however php.net approaches the
matter, and added that nobody had said the VC6 builds would end. He also
believed that Microsoft would be likely to provide help with the transition.

Short version: PHP binaries and associated libs built with VS 2005
will be made available on
href="http://qa.php.net/">qa.php.net.


TLK: PDO performance

PHP user Andrew Mason was considering a switch from ext/mysqli to the
PDO_MYSQL driver. He liked the look of the PDO API better, but wondered if
there would be any performance or latency issues when using it with MySQL 5.
He didn’t trust his own benchmarking because PDO had been faster for some
items there, which went against everything he’d heard.

Alexey Zakhlestin wrote that if there is any difference, it’s very small.
Besides, the overhead was as nothing compared to typical query execution
time. He’d been using PDO for three years, and could confirm that it is ‘a
pleasure to work with
‘.

Brian Moon also responded. He hadn’t done any benchmarking in the past year,
but last year’s results were still href="http://dealnews.com/developers/php-mysql.html">available online.
Essentially, the performance hit depended on the way in which PDO_MYSQL was
being used.

Short version: The advent of mysqlnd is likely to tip the balance
in favour of mysqli until PDO is supported.


TLK: Optional scalar type hinting

A Sam Barrow had found an old patch written by Derick Rethans that allows
scalar type hinting. Sam had adapted the patch to work with the latest
PHP_5_3 snapshot, and added the ability to type hint for
resource and support for secondary keywords
(double, real, long) for all basic
types. Since the type hinting is 100% optional, the patch maintains back
compatibility in full. Sam didn’t actually supply the patch at this stage; he
wasn’t sure where it should be submitted. However, he asked if it could be
added to ‘the next PHP release‘.

Richard Quadling wanted to know whether the argument would be cast to the
hinted type in this patch, and pointed out that the idea of type hinting for
arrays and classes was to ensure that the incoming data was appropriate. This
was less applicable to basic types, where the same data could imply an empty
string, a zero integer or FALSE. Wouldn’t it mean that all the
arguments had to be explicitly cast? Jeremy Privett assumed not; it should
just bomb out‘ if the incoming data is of the wrong type. However, he
felt it would only be useful to the kind of developer who always uses
=== and tries to make PHP behave as if it were strongly typed.

Marcus wrote that the subject had been discussed ‘a million times
already
‘, and the conclusion had been that type hinting shouldn’t be
allowed for basic types in PHP. Cristian Rodriguez ignored this, and
mentioned that Hannes Magnusson had offered a good implementation that had
unfortunately‘ never been merged. David Coallier, though, shared the
feedback he’d received when asking for this feature: if he wanted Java, he
should just use Java.

Short version: Nope.


RFC: Accessible compiler info

Following on from the VS 2005 discussion, I came up with the idea of adding
compiler version information to the php -v output. I’d initially
been thinking of ways to make it easier to sort the bug reports once the
Windows test releases are available, but it seemed to me that this would be a
useful thing across all platforms.

Everyone agreed, for once, but with the caveat that compiler information
should be part of the phpinfo() output rather than the
-v output. That stymied me (I know how to add information to
-v but phpinfo() needs actual thought), but I
promised to look into it.

Short version: Another item for the TODO.


TLK: Question about superglobals

A Sam Barrow announced that he was developing href="http://www.sambarrow.com/">a patch for personal use to allow custom
superglobals, and could do with some advice. It appeared to work, but only
when he hard coded his superglobals into the source files; otherwise, despite
the fact that the variable appeared to register as expected, he was unable to
access it from his script. Was there some kind of restriction on setting
superglobals at runtime?

Hans-Peter Oeri and Johannes both immediately referred Sam to href="http://pecl.php.net/runkit">the runkit extension in PECL, but Sam
already was aware of it; he’d decided against it because of its beta status
and the fact that he only wanted support for superglobals. Besides, in
runkit there is a restriction; superglobals can only be specified
through php.ini, whereas Sam wanted to use a superglobal
keyword to define them. He wasn’t sure that the team would want this in the
core, but if they liked the idea he’d be happy to provide the implementation.

PHP user Michael McGlothlin thought it a great idea, but Stas was quick to
squash it. If everybody were to add variables into the global space and make
them superglobal just to save a few keystrokes, things would quickly get
messy. He advised Michael to declare a class and use statics or singletons
instead. Sam pointed out that it’s easy enough to create messy code with many
existing features in PHP; he didn’t see that as a good reason to deny serious
developers a useful tool. In his medium-sized application, Sam was now able
to have a single line:


superglobal $mod, $sec, $cfg;


in his root include file, rather than having to specify his three universal
variable as global in every single function and method.

Sean Coates promptly href="http://news.php.net/php.internals/33188">demonstrated why Sam
shouldn’t need to do that, and Stas pointed out that changing the behaviour
of unrelated code is almost always a bad idea. Michael, though, still felt
that PHP should have ‘more options for both tighter and looser control of
variables.
‘ He would like user-defined superglobals; he would also like a
way to make variables local to a chunk of code without needing to use a
function as a container. Besides, if superglobals were so pointless, why did
PHP have them at all? With regard to Sean’s demo code, Michael wanted to know
whether the idea was now to inappropriately force everything to be a class?
Sean argued that this was wholly appropriate; classes were designed to be
user-definable, whereas superglobals were not. Defining the configuration in
a class made it easy for the application maintainer to determine where the
data was defined; superglobals, on the other hand, might be defined anywhere
in the source. Sam queried Sean’s assumption that superglobals were not
designed to be user-definable and pointed to C and C++, where they are.
(Robert Cummings later wrote to point out that locally declared variables
take precedence over global variables in both languages, which is not the
case in PHP.) Rasmus Lerdorf pulled out href="http://news.php.net/php.internals/33201">a piece of history to
explain why the concept of having to declare your globals exists in
PHP; briefly, global variables can be hell to debug. A finite number of
clearly labelled global arrays ($_GET, $_POST), and
even the later addition of $GLOBALS, meant that the chance of
someone mistaking a superglobal for something else and ‘ending up with
strange side effects
‘ is remote. In case Sam wasn’t sure, Rasmus was very
against destroying something he considered ‘a rather good design
decision
‘ just to avoid a couple of keystrokes. However inconvenient it
may be to have to declare your globals, it was as nothing compared to the
trauma of trying to find a bug caused by a global side effect in someone
else’s code.

Sam conceded that Rasmus had a point, but disagreed anyway; he believed that
the benefits of superglobals outweigh the risks. Larry Garfield shared href="http://news.php.net/php.internals/33204">a piece of history of his
own that involved watching a colleague driven slowly mad by a predecessor
who had used global variables as a primary means of internal communication. He
backed Rasmus; ‘undeclared globals are a form of extreme sadism.’ Sam
double-checked; his superglobals do, after all, need to be declared
somewhere. Rasmus pointed out that that declaration isn’t necessarily going
to be transparent to a developer working on a different area of the project.
Sam suggested it might be helpful to have a php.ini directive,
allow_superglobals, defaulting to off. Robert
exploded:

Does your code live in a bubble? Allowance of arbitrary super global
definitions would open a can of local variable clobbering worms. A
php.ini directive won't make this reality any more palatable.

Sam retorted that functions and variables are perfectly capable of causing
problems too, not to mention user input. He saw flexibility as a goal in
programming languages, and it should be up to the programmer to use it well.
Rasmus explained that flexibility, in this case, had the potential to cause
more confusion than it was worth. Sam’s patch didn’t offer a way to do
something that can’t be done currently; it merely changed a minor syntax and
a concept that had been in PHP for the last 12 years. He concluded, ‘To be
completely blunt, this change has no chance of making it into PHP’
.

Short version: Not that good an idea.


REQ: Bring back
allow_call_time_pass_reference

PHP user Karoly Negyesi made a heartfelt plea for the return of
allow_call_time_pass_reference, which has been deprecated since
Adam was a lad. In fact, Karoly was surprised it hadn’t been de-deprecated in
PHP 5, since there are things you can’t do in PHP without it…

Brian Moon felt ‘froggy‘ enough to ask for details of those things.
All he could think of were the bad things that could happen when
allow_call_time_pass_reference is switched on, and in OOP
objects are always passed by reference anyway. Karoly gave the example of a
CMS where some functions needed to modify a single array and others needed to
modify two. If these weren’t wrapped into an “arguments” array,
func_get_args() would ‘butcher your references‘.

Stas wasn’t alone in failing to follow this explanation. He requested a short
code example. Karoly offered href="http://blog.phpdoc.info/archives/3-PHP-Fun-Variable-Arguments-Be-Reference.html">a
blog entry dating back a couple of years that explained the issue more
fully. In an attempt to be more constructive, he asked if there couldn’t be a
new parameter added to func_get_arg() to obtain the argument by
reference? Then he caught up with the universal confusion brought on by his
initial explanation, and apologized. What was needed was the ability to pass
a variable number of arguments, some of which may be references. He believed
this impossible without support for call-time by-ref calls. A simple flag
would suffice in func_get_arg(); he was less sure how to deal
with func_get_args(), but perhaps a parameter that would accept
all the by-ref arguments would be the answer. Stas, having read the blog
post, suggested that Karoly submit his idea as a feature request via href="http://bugs.php.net/">bugs.php.net, this time including the code
examples given in the blog.

Short version: Clarity is good.


TLK: Restore output buffer in case of
exceptions

Someone with a rather wonderful name, Mehmet Yavuz Selim Soyturk, wrote to
internals@. He admitted up front to being neither a Web programmer nor a PHP
developer; he just had come across something he thought might be useful. When
an exception occurs, PHP 5 unwinds the stack to restore the state of the
script, but neglects to restore the output. Wouldn’t it be a good idea if it
also did some sort of output buffer unwinding? To demonstrate:


exceptional_ob_start();

echo "Begin\n";
try { />    echo
"Exception\n"; />    throw new Exception();
} catch
(
Exception $e) {}
echo
"End\n";

style="color: #0000BB">exceptional_ob_end_flush();

// Begin
//
End


Tony Dovgal pointed out that if this approach were taken to output buffering,
the same would need to be applied to file descriptors, database transactions
and network connections et al. This didn’t make a lot of sense. Alexey
corrected him; it made perfect sense, it would just be ‘almost
impossible
‘ to implement. He actually liked the idea of having the output
buffer respond in the way Mehmet suggested, but was concerned that edge cases
would be less than obvious.

Evert|Rooftop wrote bluntly that in his code, the parts that start an
output buffer are also responsible for closing it. Something like:


href="/manual/function.ob-start.html">ob_start();
try {
    
style="color: #0000BB">do_something
(); />} catch (Exception $e style="color: #007700">) {
     style="color: #0000BB"> href="/manual/function.ob-end-clean.html">ob_end_clean style="color: #007700">();
    throw style="color: #0000BB">$e;
} />
$data = href="/manual/function.ob-get-clean.html">ob_get_clean style="color: #007700">();


would be typical. Edward Z. Yang agreed, explaining that Mehmet would need to
implement ‘rollback functionality‘ in the catch block. Mehmet hadn’t
been aware until now that output buffers in PHP can be nested; this made it
possible to manually translate a standard try-catch block to something like:


href="/manual/function.ob-start.html">ob_start();
try {
    
style="color: #FF8000">// ... code
    
style="color: #0000BB"> href="/manual/function.ob-end-flush.html">ob_end_flush style="color: #007700">();
} catch (Exception $e) { />     href="/manual/function.ob-end-clean.html">ob_end_clean style="color: #007700">();
     style="color: #FF8000">// ... code
}


Stas’ post explaining precisely this arrived after Mehmet’s post with the
code.

Short version (thanks Stas): Buffers are stackable in PHP.


CVS: Oracle 8 support dropped

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

  • Zend Engine bug #42937
    (__call() method not invoked when methods are called on parent
    from child class) was fixed in PHP_5_2, PHP_5_3 and CVS HEAD [Dmitry
    Stogov]
  • In ext/xmlrpc, bug
    #42736
    (xmlrpc_server_call_method() crashes) was fixed
    across all three branches [Tony]
  • Zend Engine bug #43183 (“use”
    of the same class in different scripts results in a fatal error) was fixed in
    the PHP_5_3 branch and CVS HEAD [Dmitry]
  • Core bug #43182
    (file_put_contents() LOCK_EX does not work properly
    on file) was fixed across all three branches [Ilia Alshanetsky]
  • In ext/simplexml, bug
    #43221
    (SimpleXML adding default namespace in
    addAttribute()) was fixed across all three branches [Rob
    Richards]
  • TSRM bug #43248 (backward
    compatibility break in realpath()) was fixed, again across all
    three branches [Dmitry]
  • Oracle 8 support was dropped from ext/oci8 in the PHP_5_3 branch
    and CVS HEAD [Tony]
  • In ext/soap, bug #42692
    (Procedure int1 not present with doc/lit
    SoapServer) was fixed across all three branches [Dmitry]
  • In ext/pgsql, bug #43279
    (pg_send_query_params() converts all elements in
    params to strings) was fixed across all three branches
    [Ilia]
  • Multiple segfaults in getopt() were fixed across all three
    branches, closing bug #43293, and
    support for numeric options was added in 5_3 and HEAD [Hannes Magnusson]
  • In the PDO_FIREBIRD driver, bug
    #43271
    (closeCursor() not implemented), feature request href="http://bugs.php.net/43296">#43296
    (ATTR_FETCH_TABLE_NAMES support) and href="http://bugs.php.net/43244">bug #43244 (closeCursor()
    w/o returned data kills process) were fixed in the PHP_5_3 branch [Lars
    Westermann]
  • Safe mode bug #43276
    (Incomplete fix for bug #42739,
    mkdir() under
    safe_mode) was fixed in the PHP_5_2 and PHP_5_3 branches
    [Ilia]
  • In ext/mbstring, bug
    #43301
    (mb_ereg*_replace() crashes when replacement string
    is invalid PHP expression and e option is used) was fixed across
    all three branches [Jani Taskinen]
  • In ext/curl, bug #43092
    (curl_copy_handle() crashes with > 32 chars long URL) was fixed
    across all three branches [Jani]

In other CVS news, the command used for building PHP under Windows using
CL changed from 5_3 up when Johannes Schlüter committed a
fix to make the buildconf batch file work properly. Instead of
typing:


cscript /nologo buildconf.js --whatever

you can now simply type:


buildconf --whatever

(The old way will still work too.) Elizabeth followed this with a commit that
does the same for the generated config.nice.bat across all three
branches.

Wearing his Release Master hat, Johannes entered into the discussion about
Ilia’s fix for PDO bug
#43130
(Bound parameters cannot have – in their name) href="http://devzone.zend.com/article/2780">a couple of weeks back.
He didn’t like the idea of having vendor specific rules in the PDO parser,
but a subset that works with most (all?) backends seemed a good compromise.
The regex suggested by Lukas Smith seemed the way to go. Lorenzo Alberton
promptly came up with a couple of safer regular expressions for bound
parameter checking. Ilia, however, remained immovable: ‘I don’t see why
PDO should follow Oracle’s rules for generic functionality.
‘ He was happy
with the current implementation, and saw no need to change it.

Short version: The Windows CL build system is now fully in line
with Linux syntax.


PAT: Etienne joins the clan; str_split patch

Two new Zend Engine patches from Etienne Kneuss were applied by Johannes and
Tony respectively; one to fix bug
#43126
(Unexpected T_STATIC in parser error) and one to
disallow multiple access modifiers and ‘abstract abstract’ methods. Derick,
seeing a common theme emerging, gave Etienne access to the php-src module.
Marcus went one better, and gave Johannes enough karma to allow him to
control other peoples’ CVS access.

Hans-Peter Oeri offered a fix for duplicated PDO_FIREBIRD bug href="http://bugs.php.net/43271">#43271/ href="http://bugs.php.net/43246">#43246 (closeCursor() not
implemented) and followed with a patch offering
ATTR_FETCH_TABLE_NAMES
support. Marcus looked through the patches,
offered some advice about coding standards and eagerly asked Hans-Peter if
he’d like CVS access to the module. Hans-Peter, who hadn’t expected this,
wrote ‘yes please‘, but wanted to know whether there wasn’t an active
maintainer for the driver already. Marcus didn’t know of one… he added that
the firebird installation on the gcov site
could do with some attention. Nuno Lopes quickly backed Marcus in this; he
had no idea how to get it to work. At this point Lars Westermann, the active
maintainer of the PDO_FIREBIRD driver, introduced himself to all concerned
and explained that he’d already fixed that particular bug in CVS earlier in
the week. Marcus pointed to Hans-Peter’s second patch and asked whether Lars
would like another person to have access to the module at this point. Lars
committed support for the attribute, but there was no word on the idea of a
second maintainer for the driver.

Meanwhile Marcus had been looking at Andrew Minerd’s patch from href="http://devzone.zend.com/article/2780#Heading9">last week
to allow __sleep() to return NULL. He wrote that
the patch looked fine, but asked Andrew to include the now outdated test
changes in both the 5_3 and HEAD versions of an updated patch.

And finally, a Claudio Cherubino posted a one-line patch against CVS HEAD to
fix bug #42866
(str_split() returns extra char when given string size is not
multiple of length). He explained that, for example, if the string size is
given as 22 and the split length as 5, the final element of the returned
array currently contains 5 or more characters rather than the expected 2.
This bug was unique to PHP 6 with unicode.semantics switched on.

Short version: You wait ages for a PDO_FIREBIRD maintainer and then
two come along at once.

One Response to “Zend Weekly Summaries Issue #367”

  1. somnium Says:

    Thanks a lot for the great overview. It really helps as I don’t have to read the complete php.internals then. Btw. maybe you forgot bug #43663 in the cvs summary.