Hi,
while trying Stewart Morgan's patch, I found this situation and would like your advice before opening a PHP bug.
Look at this sample code: <?php $the_query = "INSERT INTO `aaa` (`f1`, `f2`) VALUES ('1', 'aaa')"; preg_match('@INSERT\sINTO\s\`([^\`]+)\`@iu', $the_query, $error_table = array() ); print_r($error_table); ?>
On PHP 5.1.0-RC4 I get Array ( [0] => INSERT INTO `aaa` [1] => aaa )
On PHP 5.1.2 I get Array ( )
If I change to
preg_match('@INSERT\sINTO\s`([^`]+)`@iu', $the_query, $error_table);
it works.
Is it supposed to be wrong now to use the $error_table = array() syntax?
Marc
Hi Marc!
Look at this sample code:
<?php $the_query = "INSERT INTO `aaa` (`f1`, `f2`) VALUES ('1', 'aaa')"; preg_match('@INSERT\sINTO\s\`([^\`]+)\`@iu', $the_query, $error_table = array() ); print_r($error_table); ?>
It surprises me that this has ever worked :)
I guess that PHP 5.1.2 has a different way of evaluating/processing the order of the array assignment. But the way of specifieing an assignment within a function call is something I've never seen before, and also looks a bit misleading-codewise, IMHO.
So you might want to ask how this problem came, but I'm pretty sure the answer will be "It was never meant to work, so you shouldn't have relied on it. We fixed this because of memory corruption issues" ;-)
Best regards, Garvin
Garvin Hicking a écrit :
Hi Marc!
Look at this sample code:
<?php $the_query = "INSERT INTO `aaa` (`f1`, `f2`) VALUES ('1', 'aaa')"; preg_match('@INSERT\sINTO\s\`([^\`]+)\`@iu', $the_query, $error_table = array() ); print_r($error_table); ?>
It surprises me that this has ever worked :)
I guess that PHP 5.1.2 has a different way of evaluating/processing the order of the array assignment. But the way of specifieing an assignment within a function call is something I've never seen before, and also looks a bit misleading-codewise, IMHO.
So you might want to ask how this problem came, but I'm pretty sure the answer will be "It was never meant to work, so you shouldn't have relied on it. We fixed this because of memory corruption issues" ;-)
Best regards, Garvin
Thanks Garvin, I'll change this borderline syntax in common.lib.php :)
Marc
Garvin Hicking schrieb:
Hi Marc!
Look at this sample code:
<?php $the_query = "INSERT INTO `aaa` (`f1`, `f2`) VALUES ('1', 'aaa')"; preg_match('@INSERT\sINTO\s\`([^\`]+)\`@iu', $the_query, $error_table = array() ); print_r($error_table); ?>
It surprises me that this has ever worked :)
me not!
it is more than logical that this should work, as = is always evaluated first!
I guess that PHP 5.1.2 has a different way of evaluating/processing the order of the array assignment. But the way of specifieing an assignment within a function call is something I've never seen before, and also looks a bit misleading-codewise, IMHO.
So you might want to ask how this problem came, but I'm pretty sure the answer will be "It was never meant to work, so you shouldn't have relied on it. We fixed this because of memory corruption issues" ;-)
i don't think so.
why?
whats the difference between
function( anotherFunction() ); function( $var = 'value' );
???
why should this not work?
for example in C i often see this to clarify parameters
function(true, false, true); or function($use_utf8 = true, $return = false, $escape = true);
what do you think is easier to read? and why should this not work in PHP?
Sebastian Mendel a écrit :
Garvin Hicking schrieb:
Hi Marc!
Look at this sample code:
<?php $the_query = "INSERT INTO `aaa` (`f1`, `f2`) VALUES ('1', 'aaa')"; preg_match('@INSERT\sINTO\s\`([^\`]+)\`@iu', $the_query, $error_table = array() ); print_r($error_table); ?>
It surprises me that this has ever worked :)
me not!
it is more than logical that this should work, as = is always evaluated first!
I guess that PHP 5.1.2 has a different way of evaluating/processing the order of the array assignment. But the way of specifieing an assignment within a function call is something I've never seen before, and also looks a bit misleading-codewise, IMHO.
So you might want to ask how this problem came, but I'm pretty sure the answer will be "It was never meant to work, so you shouldn't have relied on it. We fixed this because of memory corruption issues" ;-)
i don't think so.
why?
whats the difference between
function( anotherFunction() ); function( $var = 'value' );
???
why should this not work?
for example in C i often see this to clarify parameters
function(true, false, true); or function($use_utf8 = true, $return = false, $escape = true);
what do you think is easier to read? and why should this not work in PHP?
Hi Sebastian,
Please do not draw too general conclusions about what I wrote. This example works in PHP 5.1.2:
$error_table = array();
preg_match('@INSERT\sINTO\s`([^`]+)`@iu', $the_query = "INSERT INTO `aaa` (`f1`, `f2`) VALUES ('1', 'aaa')", $error_table );
print_r($error_table); ?>
I was just talking about using $error_table = array() as a function argument.
Anyway, I could not find this syntax in the doc. If you can't find it in the doc either, then this would be a PHP feature request :)
Marc
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Garvin Hicking schrieb:
Hi Marc!
Look at this sample code:
<?php $the_query = "INSERT INTO `aaa` (`f1`, `f2`) VALUES ('1', 'aaa')"; preg_match('@INSERT\sINTO\s\`([^\`]+)\`@iu', $the_query, $error_table = array() ); print_r($error_table); ?>
It surprises me that this has ever worked :)
me not!
it is more than logical that this should work, as = is always evaluated first!
I guess that PHP 5.1.2 has a different way of evaluating/processing the order of the array assignment. But the way of specifieing an assignment within a function call is something I've never seen before, and also looks a bit misleading-codewise, IMHO.
So you might want to ask how this problem came, but I'm pretty sure the answer will be "It was never meant to work, so you shouldn't have relied on it. We fixed this because of memory corruption issues" ;-)
i don't think so.
why?
whats the difference between
function( anotherFunction() ); function( $var = 'value' );
???
why should this not work?
for example in C i often see this to clarify parameters
function(true, false, true); or function($use_utf8 = true, $return = false, $escape = true);
what do you think is easier to read? and why should this not work in PHP?
Hi Sebastian,
Please do not draw too general conclusions about what I wrote. This example works in PHP 5.1.2:
$error_table = array();
preg_match('@INSERT\sINTO\s`([^`]+)`@iu', $the_query = "INSERT INTO `aaa` (`f1`, `f2`) VALUES ('1', 'aaa')", $error_table );
print_r($error_table); ?>
of course not!
I was just talking about using $error_table = array() as a function argument.
Anyway, I could not find this syntax in the doc. If you can't find it in the doc either, then this would be a PHP feature request :)
the problem is not that this variable is not assigned in the function call, but it is assigned AFTER the function is executed:
<?php function myFunc(&$var) { $var = 'set in function'; }
$var = 'set before function'; myFunc($var = 'set in function call');
var_dump($var); ?>
expected, and how it was before 5.1.2: set in function
now with 5.1.2 it prints: set in function call
Hi!
the problem is not that this variable is not assigned in the function call, but it is assigned AFTER the function is executed:
[...]
This is a very good reduced example. I urgently suggest to post this on the PHP Bugtracker, no matter what you think of them - I agree that it is a BC-break which should at least be documented in the ChangeLog of PHP5.
Best regards, Garvin
Garvin Hicking schrieb:
Hi!
the problem is not that this variable is not assigned in the function call, but it is assigned AFTER the function is executed:
[...]
This is a very good reduced example. I urgently suggest to post this on the PHP Bugtracker, no matter what you think of them - I agree that it is a BC-break which should at least be documented in the ChangeLog of PHP5.
much more confusing:
<?php function myFuncR(&$var) { echo 'before inside function overwrite:'; var_dump($var); echo "\n"; $var = 9999; echo 'after inside function overwrite:'; var_dump($var); echo "\n"; }
$var = 0; echo 'before function call:'; var_dump($var); echo "\n"; myFuncR($var = 20); echo 'after function call:'; var_dump($var); echo "\n"; ?>
before function call:int(0)
before inside function overwrite:int(20)
after inside function overwrite:int(9999)
after function call:int(20)
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Garvin Hicking schrieb:
Hi Marc!
Look at this sample code:
<?php $the_query = "INSERT INTO `aaa` (`f1`, `f2`) VALUES ('1', 'aaa')"; preg_match('@INSERT\sINTO\s\`([^\`]+)\`@iu', $the_query, $error_table = array() ); print_r($error_table); ?>
It surprises me that this has ever worked :)
me not!
it is more than logical that this should work, as = is always evaluated first!
I guess that PHP 5.1.2 has a different way of evaluating/processing the order of the array assignment. But the way of specifieing an assignment within a function call is something I've never seen before, and also looks a bit misleading-codewise, IMHO.
So you might want to ask how this problem came, but I'm pretty sure the answer will be "It was never meant to work, so you shouldn't have relied on it. We fixed this because of memory corruption issues" ;-)
i don't think so.
why?
whats the difference between
function( anotherFunction() ); function( $var = 'value' );
???
why should this not work?
for example in C i often see this to clarify parameters
function(true, false, true); or function($use_utf8 = true, $return = false, $escape = true);
what do you think is easier to read? and why should this not work in PHP?
Hi Sebastian,
Please do not draw too general conclusions about what I wrote. This example works in PHP 5.1.2:
$error_table = array();
preg_match('@INSERT\sINTO\s`([^`]+)`@iu', $the_query = "INSERT INTO `aaa` (`f1`, `f2`) VALUES ('1', 'aaa')", $error_table );
print_r($error_table); ?>
of course not!
What do you mean "of course not"? That this script does not work? It works in PHP 5.1.2.
I was just talking about using $error_table = array() as a function argument.
Anyway, I could not find this syntax in the doc. If you can't find it in the doc either, then this would be a PHP feature request :)
the problem is not that this variable is not assigned in the function call, but it is assigned AFTER the function is executed:
<?php function myFunc(&$var) { $var = 'set in function'; } $var = 'set before function'; myFunc($var = 'set in function call'); var_dump($var); ?>
expected, and how it was before 5.1.2: set in function
now with 5.1.2 it prints: set in function call
Again, where do you see in the doc that we are allowed to do this?
Marc
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Marc Delisle schrieb:
Sebastian Mendel a écrit :
Garvin Hicking schrieb:
Hi Marc!
Look at this sample code:
<?php $the_query = "INSERT INTO `aaa` (`f1`, `f2`) VALUES ('1', 'aaa')"; preg_match('@INSERT\sINTO\s\`([^\`]+)\`@iu', $the_query, $error_table = array() ); print_r($error_table); ?>
It surprises me that this has ever worked :)
me not!
it is more than logical that this should work, as = is always evaluated first!
I guess that PHP 5.1.2 has a different way of evaluating/processing the order of the array assignment. But the way of specifieing an assignment within a function call is something I've never seen before, and also looks a bit misleading-codewise, IMHO.
So you might want to ask how this problem came, but I'm pretty sure the answer will be "It was never meant to work, so you shouldn't have relied on it. We fixed this because of memory corruption issues" ;-)
i don't think so.
why?
whats the difference between
function( anotherFunction() ); function( $var = 'value' );
???
why should this not work?
for example in C i often see this to clarify parameters
function(true, false, true); or function($use_utf8 = true, $return = false, $escape = true);
what do you think is easier to read? and why should this not work in PHP?
Hi Sebastian,
Please do not draw too general conclusions about what I wrote. This example works in PHP 5.1.2:
$error_table = array();
preg_match('@INSERT\sINTO\s`([^`]+)`@iu', $the_query = "INSERT INTO `aaa` (`f1`, `f2`) VALUES ('1', 'aaa')", $error_table );
print_r($error_table); ?>
of course not!
What do you mean "of course not"? That this script does not work?
no
It works in PHP 5.1.2.
yes,
of course not, i don't take too general conclusions about what you wrote!
I was just talking about using $error_table = array() as a function argument.
yes, me too!
Anyway, I could not find this syntax in the doc. If you can't find it in the doc either, then this would be a PHP feature request :)
the problem is not that this variable is not assigned in the function call, but it is assigned AFTER the function is executed:
<?php function myFunc(&$var) { $var = 'set in function'; } $var = 'set before function'; myFunc($var = 'set in function call'); var_dump($var); ?>
expected, and how it was before 5.1.2: set in function
now with 5.1.2 it prints: set in function call
Again, where do you see in the doc that we are allowed to do this?
the documentation writes with examples what can be done, but not ALL what can be done!
it seems just logical that expressions evaluated first before passed to the function - and as you can see in my other mail it is still be done, but after the call again!
printLocalDate(time() + 60*60*24 * 12); // current time plus 12 days
why should this not work? there is no need to assign this value first to a variable and than pass this variable to the function
and
myFunc($var = 'value');
is not much different, or?
Hi Sebastian!
printLocalDate(time() + 60*60*24 * 12); // current time plus 12 days and myFunc($var = 'value'); is not much different, or?
Actually, this is much different. The first call doesn't need to to any variable assignment. The second call does, and needs to store it somewhere in memory.
Exactly this "store it in memory" has in the past time led to memory corruption, and was the reason why the PHP notice "Fatal error/Warning: Only variables can be passed by reference..." [1] was introduced, resulting in one really big BC break.
I think your method is a follow-up to that same problem, but it should also not have become changed without any notice in the ChangeLog. But it seems not many people use that mechanism, so it has/may not yet been reported. Which is all the more reason to post this report on bugs.php.net.
[1] http://cow.neondragon.net/index.php/375-Annoying-Things-About-Php http://phplens.com/phpeverywhere/?q=node/view/214
Regards, Garvin
Garvin Hicking schrieb:
Hi Sebastian!
printLocalDate(time() + 60*60*24 * 12); // current time plus 12 days and myFunc($var = 'value'); is not much different, or?
Actually, this is much different. The first call doesn't need to to any variable assignment. The second call does, and needs to store it somewhere in memory.
yes, and store it in the memory on the address of $var! there is really no logical reason for me why this should not work.
Exactly this "store it in memory" has in the past time led to memory corruption, and was the reason why the PHP notice "Fatal error/Warning: Only variables can be passed by reference..." [1] was introduced, resulting in one really big BC break.
I think your method is a follow-up to that same problem, but it should also not have become changed without any notice in the ChangeLog. But it seems not many people use that mechanism, so it has/may not yet been reported. Which is all the more reason to post this report on bugs.php.net.
[1] http://cow.neondragon.net/index.php/375-Annoying-Things-About-Php http://phplens.com/phpeverywhere/?q=node/view/214
this 'old' reference problem is known to me
i also have in mind that this new change with 5.1.2 has still something to do with this, but not on the technical side but on the developer side (as some developer changes this behavior or something what leads to this new behavior with 'old' reference problem in mind), but i don't agree that the old behavior was not correctly working or lead to any memory corruption, the 'old' reference problem is a little bit different!
i give the function a valid variable, as required by call-by-reference, i just assign a value just before passing it to the function!
p.s.: bist du auch auf der deutschen php mailingliste: php@phpbar.de?
Hi All!
Just to sum this all up:
I've entered Sebastians short code of reproduction in the PHP bugtracker and then was notified that this had already been tracked:
http://bugs.php.net/bug.php?id=35995
This bureport confirms what I stated first: The way of specifying preg_match($string, $pattern, $matches = array()) is invalid, and the bug was that it worked in earlier versions - not that it stopped working now. Still a BC-break, but it seems that the PHP people don't mind about that. :-/
Best regards, Garvin
Garvin Hicking schrieb:
Hi All!
Just to sum this all up:
I've entered Sebastians short code of reproduction in the PHP bugtracker and then was notified that this had already been tracked:
http://bugs.php.net/bug.php?id=35995
This bureport confirms what I stated first: The way of specifying preg_match($string, $pattern, $matches = array()) is invalid, and the bug was that it worked in earlier versions - not that it stopped working now. Still a BC-break, but it seems that the PHP people don't mind about that. :-/
anymore to say ... about 'this' php people? ...
i have never been in contact with one 'this' people and said aftwerward, hey great!
Garvin Hicking a écrit :
Hi All!
Just to sum this all up:
I've entered Sebastians short code of reproduction in the PHP bugtracker and then was notified that this had already been tracked:
http://bugs.php.net/bug.php?id=35995
This bureport confirms what I stated first: The way of specifying preg_match($string, $pattern, $matches = array()) is invalid, and the bug was that it worked in earlier versions - not that it stopped working now. Still a BC-break, but it seems that the PHP people don't mind about that. :-/
The last post in the tracker says: --------- [15 Jan 10:16pm CET] derick@php.net
Jani, I discussed this with Ilia earlier today and it *is* a BC breaking change in PHP 5.1.2 - all other versions do not do this (including PHP 4.4.x or 5.1.1). Therefore it is a bug and it should be addressed. Dmitry, if you feel otherwise, please close it then. ---------
So it's not yet clear what will happen with back compatibility.
Marc
-
Garvin Hicking -
Marc Delisle -
Sebastian Mendel