Re: [PHP-DEV] Upgrading php
Im aware of that, but my thinking was to add the things in for
that Maybe Davey will be willing, or I could give it a shot and see.
--
Eric Coleman
http://aplosmedia.com
home: 412 399 1024
cell: 412 779 5176
On Nov 19, 2005, at 10:28 PM, Steph Fox wrote:
Current release: 1.0.0 (stable) was released on 2005-03-15
That means it's not up to date enough to help with 5.0 -> 5.1
upgrades...
- Original Message -
From: "Eric Coleman" <[EMAIL PROTECTED]>
To: "Andi Gutmans" <[EMAIL PROTECTED]>
Cc: "Jani Taskinen" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
Sent: Sunday, November 20, 2005 3:24 AM
Subject: Re: [PHP-DEV] Upgrading php
What about using http://pear.php.net/package/PHP_CompatInfo as a
basis? It seemed to do a pretty good job last time I ran it...
- Eric
--
Eric Coleman
http://aplosmedia.com
home: 412 399 1024
cell: 412 779 5176
On Nov 18, 2005, at 2:33 PM, Andi Gutmans wrote:
Yep that's definitely a good start. The two things we might want to
improve on are:
a) Not require PHP 5 in order to detect these issues when PHP 6
comes a long.
b) Have a script that automatically makes the changes that can be
done without human intervention.
We had something similar to (a) and (b) when we moved people from
PHP/FI 2 to PHP 3 as there were some significant differences. That
said, it's not always simple because you might need to have to
reuse the scanner/parser and a simple PHP script might not be
enough.
Hopefully, as we get closer to PHP 6 there will be people who have
time to invest in this.
Most important thing at this point, is to keep the upgrading docs
(which will be first released with 5.1) in sync with the changes,
so that when the time comes with PHP 6, it'll be easy to translate
the docs to such a script, without forgetting half the stuff that
was changed.
Andi
At 12:06 AM 11/18/2005, Jani Taskinen wrote:
On Thu, 17 Nov 2005, Andi Gutmans wrote:
I'm hoping that in future we can provide better tools for
upgrading in between versions. Both from an auto-conversion
perspective and just scanning the code statically and printing
out warnings on what code to check. Coupled with better upgrading
docs I think we'd improve the current situation significantly.
We already have the scanner:
# php -derror_reporting=4095 -l script_to_check.php
Strict Standards: Usage of {} to access string offsets is
deprecated and
will be removed in PHP 6 in t.php on line 6
No syntax errors detected in t.php
With a simple shell script you can create a list of files
having
any errors/warnings/notices/strict.. :)
At work we use a syntax checker script run whenever we commit
files
to our CVS repository to catch any errors early..this reminded
me to
fix that script to catch notices and such too. :)
--Jani
--
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
Re: [PHP-DEV] Upgrade notes for PHP 5.1 - final draft
OK, thanks for that Wez, I'll tone it down another notch. But http://pecl.php.net/package/PHPScript works, and http://pecl.php.net/package/activescript definitively does not, so I think I'd better stay with what the PECL db knows rather than with what CVS knows no? (Or just put an extra note by it?) - Steph - Original Message - From: "Wez Furlong" <[EMAIL PROTECTED]> To: "Steph Fox" <[EMAIL PROTECTED]> Cc: "internals" Sent: Saturday, November 19, 2005 5:14 PM Subject: Re: [PHP-DEV] Upgrade notes for PHP 5.1 - final draft There is no pecl/phpscript, it's pecl/activescript. I'm still wary of sending too strong a message about adopting PDO in this release; there are almost certainly some features missing from PDO that are present in the traditional drivers. This feature gap will get smaller after the 5.1 release is made and we can start up development again. If you can find a way of putting that in your notes, I'd feel happier. --Wez. On 11/19/05, Steph Fox <[EMAIL PROTECTED]> wrote: > Guys and guyess, > > Hopefully this is the final version of the upgrade notes. Please could you > scroll through it (particularly if you've been involved in developing any of > the affected areas) and get back to me ASAP if you find any misconceptions, > missing information about changes that will affect legacy code, or downright > errors. > > These notes need to be 100% complete and agreed by 18:00 hours UTC Sunday - > no inet access for me after this until post-release. > > Thanks all, especially Jani for the helpful multi-file script. > > - 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
Re: [PHP-DEV] Upgrading php
Current release: 1.0.0 (stable) was released on 2005-03-15
That means it's not up to date enough to help with 5.0 -> 5.1 upgrades...
- Original Message -
From: "Eric Coleman" <[EMAIL PROTECTED]>
To: "Andi Gutmans" <[EMAIL PROTECTED]>
Cc: "Jani Taskinen" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
Sent: Sunday, November 20, 2005 3:24 AM
Subject: Re: [PHP-DEV] Upgrading php
> What about using http://pear.php.net/package/PHP_CompatInfo as a
> basis? It seemed to do a pretty good job last time I ran it...
>
> - Eric
> --
> Eric Coleman
>
> http://aplosmedia.com
> home: 412 399 1024
> cell: 412 779 5176
>
>
> On Nov 18, 2005, at 2:33 PM, Andi Gutmans wrote:
>
> > Yep that's definitely a good start. The two things we might want to
> > improve on are:
> > a) Not require PHP 5 in order to detect these issues when PHP 6
> > comes a long.
> > b) Have a script that automatically makes the changes that can be
> > done without human intervention.
> >
> > We had something similar to (a) and (b) when we moved people from
> > PHP/FI 2 to PHP 3 as there were some significant differences. That
> > said, it's not always simple because you might need to have to
> > reuse the scanner/parser and a simple PHP script might not be enough.
> >
> > Hopefully, as we get closer to PHP 6 there will be people who have
> > time to invest in this.
> > Most important thing at this point, is to keep the upgrading docs
> > (which will be first released with 5.1) in sync with the changes,
> > so that when the time comes with PHP 6, it'll be easy to translate
> > the docs to such a script, without forgetting half the stuff that
> > was changed.
> >
> > Andi
> >
> > At 12:06 AM 11/18/2005, Jani Taskinen wrote:
> >> On Thu, 17 Nov 2005, Andi Gutmans wrote:
> >>
> >>> I'm hoping that in future we can provide better tools for
> >>> upgrading in between versions. Both from an auto-conversion
> >>> perspective and just scanning the code statically and printing
> >>> out warnings on what code to check. Coupled with better upgrading
> >>> docs I think we'd improve the current situation significantly.
> >>
> >> We already have the scanner:
> >>
> >> # php -derror_reporting=4095 -l script_to_check.php
> >>
> >> Strict Standards: Usage of {} to access string offsets is
> >> deprecated and
> >> will be removed in PHP 6 in t.php on line 6
> >> No syntax errors detected in t.php
> >>
> >> With a simple shell script you can create a list of files having
> >> any errors/warnings/notices/strict.. :)
> >>
> >> At work we use a syntax checker script run whenever we commit
> >> files
> >> to our CVS repository to catch any errors early..this reminded
> >> me to
> >> fix that script to catch notices and such too. :)
> >>
> >> --Jani
> >
> > --
> > 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
Re: [PHP-DEV] Upgrading php
What about using http://pear.php.net/package/PHP_CompatInfo as a
basis? It seemed to do a pretty good job last time I ran it...
- Eric
--
Eric Coleman
http://aplosmedia.com
home: 412 399 1024
cell: 412 779 5176
On Nov 18, 2005, at 2:33 PM, Andi Gutmans wrote:
Yep that's definitely a good start. The two things we might want to
improve on are:
a) Not require PHP 5 in order to detect these issues when PHP 6
comes a long.
b) Have a script that automatically makes the changes that can be
done without human intervention.
We had something similar to (a) and (b) when we moved people from
PHP/FI 2 to PHP 3 as there were some significant differences. That
said, it's not always simple because you might need to have to
reuse the scanner/parser and a simple PHP script might not be enough.
Hopefully, as we get closer to PHP 6 there will be people who have
time to invest in this.
Most important thing at this point, is to keep the upgrading docs
(which will be first released with 5.1) in sync with the changes,
so that when the time comes with PHP 6, it'll be easy to translate
the docs to such a script, without forgetting half the stuff that
was changed.
Andi
At 12:06 AM 11/18/2005, Jani Taskinen wrote:
On Thu, 17 Nov 2005, Andi Gutmans wrote:
I'm hoping that in future we can provide better tools for
upgrading in between versions. Both from an auto-conversion
perspective and just scanning the code statically and printing
out warnings on what code to check. Coupled with better upgrading
docs I think we'd improve the current situation significantly.
We already have the scanner:
# php -derror_reporting=4095 -l script_to_check.php
Strict Standards: Usage of {} to access string offsets is
deprecated and
will be removed in PHP 6 in t.php on line 6
No syntax errors detected in t.php
With a simple shell script you can create a list of files having
any errors/warnings/notices/strict.. :)
At work we use a syntax checker script run whenever we commit
files
to our CVS repository to catch any errors early..this reminded
me to
fix that script to catch notices and such too. :)
--Jani
--
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
Re: [PHP-DEV] sha256(), sha256_file(), and other hashing algos
I'm missing the functionality to get a list of registered hash functions so one can probe whether a certain hash function is available or not. There is now :) array hash_algos(void) Returns numerically indexed array of hashing engine names. And just incase anyone missed it. The proto for hash_init() has been extended: resource hash_init(string algo[, int options, string key]) Options currently has one possible value: HASH_HMAC When specified, key must be specified as well (to be used for the HMAC key). HMAC can be used with any of the hashing algos included in ext/hash. Examples of using HMAC with official test vectors can be found in tests/hmac-md5.phpt I'd rather not complicate the proto for the core hash() function with HMAC and other options, but maybe a separate hash_hmac() and/or hash_hmac_file() might be in order? -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Upgrade notes for PHP 5.1 - final draft
There is no pecl/phpscript, it's pecl/activescript. I'm still wary of sending too strong a message about adopting PDO in this release; there are almost certainly some features missing from PDO that are present in the traditional drivers. This feature gap will get smaller after the 5.1 release is made and we can start up development again. If you can find a way of putting that in your notes, I'd feel happier. --Wez. On 11/19/05, Steph Fox <[EMAIL PROTECTED]> wrote: > Guys and guyess, > > Hopefully this is the final version of the upgrade notes. Please could you > scroll through it (particularly if you've been involved in developing any of > the affected areas) and get back to me ASAP if you find any misconceptions, > missing information about changes that will affect legacy code, or downright > errors. > > These notes need to be 100% complete and agreed by 18:00 hours UTC Sunday - > no inet access for me after this until post-release. > > Thanks all, especially Jani for the helpful multi-file script. > > - 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
Re: [PHP-DEV] dropping curly braces
Christian Schneider wrote: Please think twice before breaking BC light-heartedly. Please brake BC completely, and rename everything, and reorder arguments, and replace array() with a(), and replace $this-> with something consise, and replace '->' with '.', and replace '.' with '~'. *smiley* -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sha256(), sha256_file(), and other hashing algos
Hi, I'm missing the functionality to get a list of registered hash functions so one can probe whether a certain hash function is available or not. - Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Upgrade notes for PHP 5.1 - final draft
Hello Steph,
you forgot to mention the change in inheritance rules that affected
the way interface ArrayAccess can be used. Due to a missing check in our
inheritance rules 5.0.* series allowed to introduce return by reference
in derived classes. Thus it was possible to implement offsetGet($offset)
as function &offsetGet($offset).
right now []++ with overloaded objects is not possible due to a wrong
limitation in the engine. This should be a bug and assigned to andi or
dmitry.
marcus
Saturday, November 19, 2005, 3:20:42 PM, you wrote:
> UPGRADE 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. String offset access
> 3. Reading []
> 4. instanceof, is_a(), is_subclass_of(), catch
> 5. Integer values in function parameters
> 6. Abstract private methods
> 7. Access modifiers in interfaces
> 8. Extensions
> a. Extensions that are gone from the PHP core
> b. Class constants in new PHP 5.1 extensions
> 9. Date/time support
> 10. Changes in database support
> a. PDO overview
> b. Changes in MySQL support
> c. Changes in SQLite support
> 11. Further migration information
> 12. Checking for E_STRICT errors
> ===
> 1. Changes in reference handling
>
> 1a. 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:
> $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.
> 1b. Code that worked under PHP 4.3, but now fails
> =
> function func(&$arraykey) {
> return $arraykey; // function returns by value!
> }
> $array = array('a', 'b', 'c');
> foreach (array_keys($array) as $key) {
> $y = &func($array[$key]);
> $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) {
> [0]=>
> &string(1) "a"
> [1]=>
> &string(1) "b"
> [2]=>
> &string(1) "c"
> }
> Following the reference fix, the same code would result in:
> array(3) {
> [0]=>
> &string(1) "c"
> [1]=>
> &string(1) "c"
> [2]=>
> &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().
> 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.
> 1c. Code that was valid under PHP 4.3, but now throws an error
> ==
[PHP-DEV] Upgrade notes for PHP 5.1 - final draft
Guys and guyess,
Hopefully this is the final version of the upgrade notes. Please could you
scroll through it (particularly if you've been involved in developing any of
the affected areas) and get back to me ASAP if you find any misconceptions,
missing information about changes that will affect legacy code, or downright
errors.
These notes need to be 100% complete and agreed by 18:00 hours UTC Sunday -
no inet access for me after this until post-release.
Thanks all, especially Jani for the helpful multi-file script.
- Steph
UPGRADE 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. String offset access
3. Reading []
4. instanceof, is_a(), is_subclass_of(), catch
5. Integer values in function parameters
6. Abstract private methods
7. Access modifiers in interfaces
8. Extensions
a. Extensions that are gone from the PHP core
b. Class constants in new PHP 5.1 extensions
9. Date/time support
10. Changes in database support
a. PDO overview
b. Changes in MySQL support
c. Changes in SQLite support
11. Further migration information
12. Checking for E_STRICT errors
===
1. Changes in reference handling
1a. 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:
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.
1b. Code that worked under PHP 4.3, but now fails
=
Running the above script under any version of PHP that pre-dates the reference
fix would produce this output:
array(3) {
[0]=>
&string(1) "a"
[1]=>
&string(1) "b"
[2]=>
&string(1) "c"
}
Following the reference fix, the same code would result in:
array(3) {
[0]=>
&string(1) "c"
[1]=>
&string(1) "c"
[2]=>
&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().
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.
1c. Code that was valid under PHP 4.3, but now throws an error
==
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.
1d. Code that failed under PHP 4.3, but now works
=
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
