Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » PHP
  • » [PHP-DEV] Upgrade notes for 5.1 [RSS Feed]

#1 Nov. 15, 2005 16:19:58

Steph F.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Upgrade notes for 5.1


Hi all,

I've already canvassed Ilia and Stas - can anyone else think of anything
I've missed/mis-explained here?

Thanks guys/guyess,

- StephUPGRADE NOTES - PHP 5.1

1. Changes in reference handling
a. Overview
b. Code that worked under PHP 4.3, but now fails
c. Code that was valid under PHP 4.3, but now throws an error
d. Code that failed under PHP 4.3, but now works
e. Code that 'should have worked' under PHP 5.0
f. Warnings that came and went
2. Reading
3. instanceof, is_a(), is_subclass_of(), catch
4. MySQL support
5. SQLite support
6. Further migration information

===============================================================================

1. Reference handling

Overview
========

>From the PHP script writer's point of view, the change most likely to impact
legacy code is in the way that references are handled in all PHP versions
post-dating the PHP 4.4.0 release.

Until and including PHP 4.3, it was possible to send, assign or return variables
by reference that should really be returned by value, such as a constant, a
temporary value (e.g. the result of an expression), or the result of a function
that had itself been returned by value, as here:

<?php

$foo = "123";

function return_value() {
global $foo;
return $foo;
}

$bar = &return_value();

?>

Although this code would usually work as expected under PHP 4.3, in the general
case the result is undefined. The Zend Engine could not act correctly on these
values as references. This bug could and did lead to various hard-to-reproduce
memory corruption problems, particularly where the code base was large.

In PHP 4.4.0, PHP 5.0.4 and all subsequent PHP releases, the Engine was fixed
to 'know' when the reference operation is being used on a value that should
not be referenced. The actual value is now used in such cases, and a warning
is emitted. The warning takes the form of an E_NOTICE in PHP 4.4.0 and up,
and E_STRICT in PHP 5.0.4 and up.

Code that could potentially produce memory corruption can no longer do so.
However, some legacy code might work differently as a result.

Code that worked under PHP 4.3, but now fails
=============================================

<?php

function func(&$arraykey) {
return $arraykey; // function returns by value!
}

$array = array('a', 'b', 'c');
foreach (array_keys($array) as $key) {
$y = &func($array);
$z =& $y;
}

var_dump($z);

?>
Running the above script under any version of PHP that pre-dates the reference
fix would produce this output:

array(3) {
=>
&string(1) "a"
=>
&string(1) "b"
=>
&string(1) "c"
}

Following the reference fix, the same code would result in:

array(3) {
=>
&string(1) "c"
=>
&string(1) "c"
=>
&string(1) "c"
}

This is because, following the changes, func() assigns by value. The value
of $y is re-assigned, and reference-binding is preserved from $z. Prior
to the fix, the value was assigned by reference, leading $y to be
re-bound on each assignment. The attempt to bind to a temporary value
by reference was the cause of the memory corruption.

Such code can be made to work identically in both the pre-fix and the
post-fix PHP versions. The signature of func() can be altered to return
by reference, or the reference assignment can be removed from the result
of func().

<?php

function func() {
return 'function return';
}

$x = 'original value';
$y =& $x;
$y = &func();
echo $x;

?>

In PHP 4.3 $x would be 'original value', whereas after the changes it would
be 'function return' - remember that where the function does not return by
reference, the reference assignment is converted to a regular assignment.
Again, this can be brought to a common base, either by forcing func() to
return by reference or by eliminating the by-reference assignment.

Code that was valid under PHP 4.3, but now throws an error
==========================================================

<?php

class Foo {

function getThis() {
return $this;
}

function destroyThis() {
$baz =& $this->getThis();
}
}

$bar = new Foo();
$bar->destroyThis();
var_dump($bar);

?>

In PHP 5.0.3, $bar evaluated to NULL instead of returning an object.
That happened because getThis() returns by value, but the value here
is assigned by reference. Although it now works in the expected way,
this is actually invalid code which will throw an E_NOTICE under
PHP 4.4 or an E_STRICT under PHP 5.0.4 and up.

Code that failed under PHP 4.3, but now works
=============================================

<?php

function &f() {
$x = "foo";
var_dump($x);
print "$x\n";
return($a);
}

for ($i = 0; $i < 3; $i++) {
$h = &f();
}

?>

In PHP 4.3 the third call to var_dump produces NULL, due to the memory
corruption caused by returning an uninitialized value by reference.
This is valid code in PHP 5.0.4 and up, but threw errors in earlier
releases of PHP.

<?php

$arr = array('a1' => array('alfa' => 'ok'));
$arr =& $arr;
echo '-'.$arr."-\n";

?>

Until PHP 5.0.5, it wasn't possible to assign an array element by
reference in this way. It now is.

Code that 'should have worked' under PHP 5.0
============================================

There are a couple of instances of bugs reported under PHP 5.0 prior
to the reference fixes which now 'work'. However, in both cases errors
are thrown by PHP 5.1, because the code was invalid in the first place.
Returning values by reference using self:: now works in the general
case but throws an E_STRICT warning, and although your mileage may
vary when assigning by reference to an overloaded object, you will
still see an E_ERROR when you try it, even where the assignment
itself appears to work.

Warnings that came and went
===========================

<?php

function & foo() {
$var = 'ok';
return $var;
}

function & bar() {
return foo();
}

$a =& bar();
echo "$a\n";

?>

Nested calls to functions returning by reference are valid code under both
PHP 4.3 and PHP 5.1, but threw an unwarranted E_NOTICE or E_STRICT under
the intervening PHP releases.

2. Reading
=============

<?php

class XmlTest {

function test_ref(&$test) {
$test = "ok";
}

function test($test) { }

function run() {
$ar = array();
$this->test_ref($ar);
var_dump($ar);
$this->test($ar);
}
}

$o = new XmlTest();
$o->run();

?>

This should always have thrown a fatal E_ERROR, because cannot be
used for reading. It is invalid code in PHP 4.4.2 and PHP 5.0.5 upward.

3. instanceof, is_a(), is_subclass_of(), catch
==============================================

In PHP 5.0, is_a() was deprecated and replaced by the "instanceof" operator.
There were some issues with the initial implementation of "instanceof", which
relied on __autoload() to search for missing classes. If the class was not
present, "instanceof" would throw a fatal E_ERROR due to the failure of
__autoload() to discover that class. The same behaviour occurred in the
"catch" operator and the is_subclass_of() function, for the same reason.

None of these functions or operators call __autoload() in PHP 5.1, and
the workarounds used in PHP 5.0 are no longer necessary.

4. MySQL support
================

In PHP 4, MySQL 3 support was built-in. With the release of PHP 5.0 there
were two MySQL extensions, named 'mysql' and 'mysqli', which were designed
to support MySQL < 4.1 and MySQL 4.1 and up, respectively. PHP 5.1 introduces
PHP Data Objects, or PDO, which provides a very fast interface to all the
database APIs supported by PHP. It is strongly recommended that you use PDO and
the PDO_MYSQL database driver, which can support any of the current versions
(MySQL 3, 4 or 5) in new PHP code, depending on the MySQL library version used
during compilation. The older extensions remain in place for reasons of back
compatibility, but are not enabled by default.

5. SQLite support
=================

In PHP 5.0, SQLite 2 support was built-in. Due to the advent of SQLite 3
and PHP Data Objects, the SQLite engine is no longer statically built into
PHP by default. The PDO_SQLITE driver communicates with the SQLite 3 engine,
and the sqlite extension remains in place only for reasons of back
compatibility.
Note that the sqlite extension is now reliant on PDO under win32. The intention
is to allow support for legacy SQLite 2 code alongside newly written SQLite 3
code; the PDO, sqlite and PDO_SQLITE extensions should all be enabled.
PDO_SQLITE
also supports SQLite 2, and can be used to communicate with either SQLite 2
and SQLite 3 via the DSN (Data Source Name) specified in PDO::__construct().

6. Further migration information
================================

For general information about migrating from PHP 4 to PHP 5, please refer to
the relevant section in the PHP manual athttp://www.php.net/manual/migration5.php.--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#2 Nov. 15, 2005 16:52:49

Wez F.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Upgrade notes for 5.1


I wouldn't "strongly" recommend the use of PDO when upgrading; that's
sending the wrong message. I'd "warmly" recommend that the use of PDO
be considered for new projects.

The sqlite information is wrong. This is the way it is:

ext/sqlite bundles sqlite version 2. The extension provides the "good
old" ext/sqlite API and also implements the 'sqlite2' driver for PDO.
If you need to access SQLite version 2 databases, you need this
extension. Use of sqlite version 2 should be avoided in new projects,
as sqlite version 3 is vastly superior.

ext/pdo_sqlite bundles sqlite version 3. It provides the 'sqlite' PDO
driver. It's use is recommended for all new projects that want to use
SQLite.

--Wez.

On 11/15/05, Steph Fox <> wrote:
> Hi all,
>
> I've already canvassed Ilia and Stas - can anyone else think of anything
> I've missed/mis-explained here?
>
> Thanks guys/guyess,
>
> - Steph
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit:http://www.php.net/unsub.php>
>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#3 Nov. 15, 2005 17:07:56

Steph F.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Upgrade notes for 5.1


Draft 1:

In PHP 5.0, SQLite 2 support was built-in. Due to the advent of SQLite 3
and PHP Data Objects, the SQLite engine is no longer statically built into
PHP by default. The PDO_SQLITE driver communicates with the SQLite 3 engine,
and the sqlite extension remains in place only for reasons of back
compatibility.
Note that the sqlite extension is now reliant on PDO under win32. The
intention
is to allow support for legacy SQLite 2 code alongside newly written SQLite
3
code; the PDO, sqlite and PDO_SQLITE extensions should all be enabled.

Somewhere between Draft 1 and Draft 2, I picked up the info that you can
write SQLite 2 code for PDO via DSN = sqlite2. I've no idea why anyone
would want to do that, but it's there...


----- Original Message -----
From: "Wez Furlong" <>
To: "Steph Fox" <>
Cc: "internals" <intern***@*ists.php.net>
Sent: Tuesday, November 15, 2005 4:52 PM
Subject: Re: Upgrade notes for 5.1


I wouldn't "strongly" recommend the use of PDO when upgrading; that's
sending the wrong message. I'd "warmly" recommend that the use of PDO
be considered for new projects.

The sqlite information is wrong. This is the way it is:

ext/sqlite bundles sqlite version 2. The extension provides the "good
old" ext/sqlite API and also implements the 'sqlite2' driver for PDO.
If you need to access SQLite version 2 databases, you need this
extension. Use of sqlite version 2 should be avoided in new projects,
as sqlite version 3 is vastly superior.

ext/pdo_sqlite bundles sqlite version 3. It provides the 'sqlite' PDO
driver. It's use is recommended for all new projects that want to use
SQLite.

--Wez.

On 11/15/05, Steph Fox <> wrote:
> Hi all,
>
> I've already canvassed Ilia and Stas - can anyone else think of anything
> I've missed/mis-explained here?
>
> Thanks guys/guyess,
>
> - Steph
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit:http://www.php.net/unsub.php>
>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#4 Nov. 15, 2005 17:21:18

Matthias P.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Upgrade notes for 5.1


I think all of us who were upset making the transition to 4.4.0 would greatly
appreciate if (in the future) there will not only be short "there's a new
release" notices, but if these notices would directly point to a list like this
one.

E. g. MySQL does a pretty good job with their upgrade notes, so you know before
the upgrade what problems to expect; they also explicitly list all the
"incompatible changes" (and there are quite some with MySQL5).

Maybe for some folks on this list the changes are well-known or obvious and
compiling a list like this one seems to be unnecessary. But most of the sysops
and developers out there don't have the time to keep up with all the changes
and don't like the fear of shooting themselves in the foot with every new
update/-grade/release. And they are especially afraid after what happened with
4.4.0, so this is a good step to reestablish some trust.

Put simply, this is the professionalism expected in "business/enterprise"
environments :).

Matthias

> -----Urspr√ľngliche Nachricht-----
> Von: Steph Fox
> Gesendet: Dienstag, 15. November 2005 17:18
> An: internals
> Betreff: Upgrade notes for 5.1
>
>
> Hi all,
>
> I've already canvassed Ilia and Stas - can anyone else think
> of anything I've missed/mis-explained here?
>
> Thanks guys/guyess,
>
> - Steph
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#5 Nov. 15, 2005 17:21:50

Wez F.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Upgrade notes for 5.1


I would say something like this:

In PHP 5.0, SQLite 2 support was provided by the sqlite extension.
With the introduction of PDO, the sqlite extension now also provides a
'sqlite2' driver for PDO; this means that the sqlite extension depends
upon the PDO extension.

PHP 5.1 ships with a number of alternative interfaces to sqlite:
ext/sqlite provides the "classic" sqlite procedural and OO API that
you've used in prior versions of PHP. It also provides the 'sqlite2'
PDO driver to allow you to access sqlite databases created with
earlier versions of PHP.
ext/pdo_sqlite provides the 'sqlite' version 3 driver. SQLite version
3 is vastly superior to SQLite version 2, but the file formats of the
two versions are not compatible.

Which should you use?
If your project is already written and working against PHP 5.0, then
you can continue to use ext/sqlite without problems.
New projects should use PDO and the 'sqlite' (version 3) driver, as
this is faster than SQLite 2 and supports prepared statements and
binary columns natively.
The 'sqlite2' driver for PDO is provided as a convenience for
accessing legacy SQLite 2 databases, created either by older versions
of PHP, or by external processes that can only generate SQLite 2
databases.

I'd also suggest that all the PDO extensions be built shared to
facilitate easier upgrades via PECL as new features are developed
there, but that's just me.

--Wez.

On 11/15/05, Steph Fox <> wrote:
> Draft 1:
>
> In PHP 5.0, SQLite 2 support was built-in. Due to the advent of SQLite 3
> and PHP Data Objects, the SQLite engine is no longer statically built into
> PHP by default. The PDO_SQLITE driver communicates with the SQLite 3 engine,
> and the sqlite extension remains in place only for reasons of back
> compatibility.
> Note that the sqlite extension is now reliant on PDO under win32. The
> intention
> is to allow support for legacy SQLite 2 code alongside newly written SQLite
> 3
> code; the PDO, sqlite and PDO_SQLITE extensions should all be enabled.
>
> Somewhere between Draft 1 and Draft 2, I picked up the info that you can
> write SQLite 2 code for PDO via DSN = sqlite2. I've no idea why anyone
> would want to do that, but it's there...
>
>
> ----- Original Message -----
> From: "Wez Furlong" <>
> To: "Steph Fox" <>
> Cc: "internals" <intern***@*ists.php.net>
> Sent: Tuesday, November 15, 2005 4:52 PM
> Subject: Re: Upgrade notes for 5.1
>
>
> I wouldn't "strongly" recommend the use of PDO when upgrading; that's
> sending the wrong message. I'd "warmly" recommend that the use of PDO
> be considered for new projects.
>
> The sqlite information is wrong. This is the way it is:
>
> ext/sqlite bundles sqlite version 2. The extension provides the "good
> old" ext/sqlite API and also implements the 'sqlite2' driver for PDO.
> If you need to access SQLite version 2 databases, you need this
> extension. Use of sqlite version 2 should be avoided in new projects,
> as sqlite version 3 is vastly superior.
>
> ext/pdo_sqlite bundles sqlite version 3. It provides the 'sqlite' PDO
> driver. It's use is recommended for all new projects that want to use
> SQLite.
>
> --Wez.
>
> On 11/15/05, Steph Fox <> wrote:
> > Hi all,
> >
> > I've already canvassed Ilia and Stas - can anyone else think of anything
> > I've missed/mis-explained here?
> >
> > Thanks guys/guyess,
> >
> > - Steph
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit:http://www.php.net/unsub.php> >
> >
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit:http://www.php.net/unsub.php>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#6 Nov. 15, 2005 17:24:51

Steph F.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Upgrade notes for 5.1


>I'd also suggest that all the PDO extensions be built shared to
>facilitate easier upgrades via PECL as new features are developed
>there, but that's just me.

:) no it isn't, PDO's cool.

Thanks for all your help over this.

- Steph

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

  • Root
  • » PHP
  • » [PHP-DEV] Upgrade notes for 5.1 [RSS Feed]

Board footer

Moderator control

Enjoy the 18th of November
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support