[PHP-DEV] Bug #11085: preg_replace_callback and class methods
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.0.5
PHP Bug Type: PCRE related
Bug description: preg_replace_callback and class methods
I was using preg_replace with the '/F' parameter, and it
was working perfectly till v4.0.4pl1. Now it has been
substituted by preg_replace_callback.
Does preg_replace_callback work with class method as a callback function, too? If it
does, how should it be
written?
I'm asking this because in each of these cases:
preg_replace_callback(/{([A-Z_][A-Z0-9_]*)}/i', $this-callmeback, $text);
preg_replace_callback(/{([A-Z_][A-Z0-9_]*)}/i', \$this-callmeback, $text);
preg_replace_callback(/{([A-Z_][A-Z0-9_]*)}/i', '$this-callmeback', $text);
I get a warning:
preg_replace_callback() requires argument 2, [...],
to be a valid callback
More: there is another drawback. With preg_replace + '/F' parameter I could also
specify additional parameters in the command line. Now I can't.
--
Edit Bug report at: http://bugs.php.net/?id=11085edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11847: Out-of-Memory
From: [EMAIL PROTECTED] Operating system: RedHat Linux 6.1 Kernel 2.2.18 PHP version: 4.0.6 PHP Bug Type: *General Issues Bug description: Out-of-Memory Some (quite heavy) scripts running fine with v4.0.5 are randomly causing Out of Memory errors. I've switched back to 4.0.5. I cannot reproduce the problem but I've seen them occurring mostly when dealing with mysql select queries. Let me know if I can help you somehow. -- Edit Bug report at: http://bugs.php.net/?id=11847edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14540: sessions and register_globals
From: [EMAIL PROTECTED]
Operating system: linux 2.2.18 - glibc 2.1.3
PHP version: 4.1.0
PHP Bug Type: Session related
Bug description: sessions and register_globals
There is something I don't understand.
I've updated to v4.1.0 and noticed that the recommended
configuration defaults register_globals to *Off*. I
understand the security reasons behind this choice. I've
tried to run one of my projects with the new interpreter
and the recommended settings (register_globals=Off). After
resolving a plenty of warnings, I noticed that things were
not working as I expected.
This is a sample code:
?
session_register('PIPPO');
if (empty($PIPPO)) {
$PIPPO = ONE;
} else {
$PIPPO = TWO;
}
$sidfile = /tmp/sess_ . $_COOKIE['PHPSESSID'];
echo Session file $sidfile contains: pre;
readfile($sidfile);
echo /pre;
echo The value is: $PIPPObr;
?
When I run and reload the script I get:
Session file /tmp/sess_87...blahblah...3e contains:
PIPPO|s:3:ONE;maxrating|N;
The value is: ONE
Why the first run sets the session variable to ONE and
the second run can't get it's value? In the latter case I
guess the answer is: because you have to access it through
$HTTP_SESSION_VARS, but ... shouldn't it had to be the
same in the former case?
--
Edit bug report at: http://bugs.php.net/?id=14540edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14540 Updated: sessions and register_globals
ID: 14540
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Session related
Operating System: linux 2.2.18 - glibc 2.1.3
PHP Version: 4.1.0
New Comment:
As usual, thanks a lot for the quick and complete answer, and expecially for all your
great work!
Coming to my question: yes, that's actually the behaviour I described. What I mean is
just that's a little tricky and maybe a little incoherent. I think that a variable
should be accessed the same either when I set it and when I get it.
If it is not global it shouldn't be possible to set it as such.
Maybe it should be somehow documented, since it's not so obvious!
Previous Comments:
[2001-12-16 05:32:13] [EMAIL PROTECTED]
Oops,
here is the explanation:
the function 'session_register()' 'registers' a variabele to a session. In other
words, when the script ends, the value of this variabele is stored with the session.
On the first run $PIPPO is empty (of course), and it is set to 'ONE'.
At the end of the script, the value is stored in the session file.
At the second run, (PIPPO is still registered to the session, so session_register has
no effect), empty($PIPPO) evalutes to TRUE again, because the value is in
$_SESSION['PIPPO'], and thus PIPPO is set to 'ONE' again.
At the end of the script, the value of $PIPPO ('ONE') is saved to the session again.
You can see more of this behavior, if you set error_reporting(E_ALL) to on in the
script.
Hope this explained it,
regards,
Derick
[2001-12-16 05:15:53] [EMAIL PROTECTED]
Hello,
let me explain this,
[2001-12-15 22:32:36] [EMAIL PROTECTED]
There is something I don't understand.
I've updated to v4.1.0 and noticed that the recommended
configuration defaults register_globals to *Off*. I
understand the security reasons behind this choice. I've
tried to run one of my projects with the new interpreter
and the recommended settings (register_globals=Off). After
resolving a plenty of warnings, I noticed that things were
not working as I expected.
This is a sample code:
?
session_register('PIPPO');
if (empty($PIPPO)) {
$PIPPO = ONE;
} else {
$PIPPO = TWO;
}
$sidfile = /tmp/sess_ . $_COOKIE['PHPSESSID'];
echo Session file $sidfile contains: pre;
readfile($sidfile);
echo /pre;
echo The value is: $PIPPObr;
?
When I run and reload the script I get:
Session file /tmp/sess_87...blahblah...3e contains:
PIPPO|s:3:ONE;maxrating|N;
The value is: ONE
Why the first run sets the session variable to ONE and
the second run can't get it's value? In the latter case I
guess the answer is: because you have to access it through
$HTTP_SESSION_VARS, but ... shouldn't it had to be the
same in the former case?
Edit this bug report at http://bugs.php.net/?id=14540edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
