Bug #64046 [Com]: Segmentation fault in pcre library
Edit report at https://bugs.php.net/bug.php?id=64046edit=1
ID: 64046
Comment by: php at richardneill dot org
Reported by:public at miholeus dot com
Summary:Segmentation fault in pcre library
Status: Not a bug
Type: Bug
Package:PCRE related
Operating System: Ubuntu 12.04.1 LTS
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I've just been bitten by this bug too.
It manifests as Connection Reset error on the website, and this in the apache
logs: [Sun Jun 30 20:58:07 2013] [notice] child pid 32544 exit signal
Segmentation fault (11)
I do understand that the segfault isn't a PHP bug, but it would be really
helpful if the error message could be more specific: something like segfault
in PCRE at line X in file Y.
Aside: another test-case.
Here, it can be triggered by a value over about 5400:
$input='span'.str_repeat('X', 5500).'/span';
$output = preg_replace(/span(((?!(\/span)).)*)\/span/, BEGIN \\1 END
,$input);
If I reduce pcre.recursion_limit converts the segfault into a PCRE failure...
but there is nothing that will make the RE actually work as intended. (in the
contrived example, we can of course just use str_replace).
Previous Comments:
[2013-01-24 15:28:45] public at miholeus dot com
I understand. Thanks for reply.
[2013-01-24 08:35:09] paj...@php.net
Not a PHP bug but pcre recursion classic stack crash, see the numerous other
reports for more info.
[2013-01-23 18:12:19] krak...@php.net
This does cause a stack overflow, for some reason the default limits for
recursion are very high, maybe someone has an explanation of that.
You have:
/'([^'])*'/
Shouldn't that be:
/'([^']*)'/
?
[2013-01-22 13:47:19] public at miholeus dot com
Description:
The following code causes segmentation fault. You can see the code by link I've
provided.
Test script:
---
Code http://pastebin.com/UzBjDaZU
Expected result:
no segfault
Actual result:
--
With gdb:
(gdb) run /var/www/work/crm/trunk/pcre.php
Starting program: /usr/bin/php /var/www/work/crm/trunk/pcre.php
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
[New Thread 0x7fffe42e4700 (LWP 4329)]
[Thread 0x7fffe42e4700 (LWP 4329) exited]
Program received signal SIGSEGV, Segmentation fault.
0x76d99a62 in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
--
Edit this bug report at https://bugs.php.net/bug.php?id=64046edit=1
Bug #64518 [Com]: optimisation for for ($i=0; $icount($array);$i++) when $array is global
Edit report at https://bugs.php.net/bug.php?id=64518edit=1
ID: 64518
Comment by: php at richardneill dot org
Reported by:php at richardneill dot org
Summary:optimisation for for ($i=0; $icount($array);$i++)
when $array is global
Status: Open
Type: Bug
Package:Performance problem
PHP Version:5.4.13
Block user comment: N
Private report: N
New Comment:
Here's a simpler test case. The problem is actually that accessing global
variables from functions is much slower than local variables (and I was seeing
this exacerbated by looping over them with count).
Note that passing the data directly as a function argument is much faster than
passing it as a global variable - this seems to me to be the root of the
problem. i.e.
function ($a,$b,$c,$large_array){
//do stuff - this is fast.
}
function ($a,$b,$c){
global $large_array
//do stuff - this is SLOW.
}
#!/usr/bin/php -ddisplay_errors=E_ALL
?
$NUMBER = 10; //adjust for your computer.
for ($i = 0; $i $NUMBER; $i++){
$data[$i] = $i;
}
echo Copy in main()...\n;
$t1 = microtime(true);
$copy = $data;
$t2 = microtime(true);
$time = ($t2 - $t1) * 1E6;
echo Finished in $time microseconds.\n\n; #5.0 us
function f1(){
global $NUMBER;
echo Copy local variable in function...\n;
for ($i = 0; $i $NUMBER; $i++){
$data_loc[$i] = $i;
}
$t1 = microtime(true);
$copy = $data_loc;
$t2 = microtime(true);
$time = ($t2 - $t1) *1E6;
echo Finished in $time microseconds.\n\n; #1.9 us
}
function f2(){
global $data;
echo Copy global variable into function...\n;
$t1 = microtime(true);
$n = $data;
$t2 = microtime(true);
$time = ($t2 - $t1) *1E6;
echo Finished in $time microseconds.\n\n; #9557 us
}
function f3($data){
echo Pass variable into function...\n;
$t1 = microtime(true);
$n = $data;
$t2 = microtime(true);
$time = ($t2 - $t1) *1E6;
echo Finished in $time microseconds.\n\n; #0.95 us
}
f1();
f2();
f3($data);
echo Note that as \$NUMBER is changed by factors of 10, the first two times
don't change much, but the latter scales as O(\$NUMBER).\n;
?
Previous Comments:
[2013-03-26 05:17:44] php at richardneill dot org
Description:
If an array is counted inside a for-loop, this is normally slightly inefficient.
$n = count ($array); //[1] optimised and a bit faster.
for ($i=0; $i $n;$i++){
//do stuff
}
for ($i=0; $icount($array);$i++){//[2] perfectly respectable speed.
//do stuff //very nearly as fast as [1].
}
BUT, if our for-loop is inside a function AND our $array is a global variable,
then method [2] becomes really really slow (though method [1] remains
unaffected).
Below, the problematic function is add_slow(); the script does the same thing 4
ways to demonstrate that 3 of them work well and one works slowly.
Test script:
---
#!/usr/bin/php -ddisplay_errors=E_ALL
?
echo This demonstrates the problem with counting global arrays inside loops
inside functions.\n;
$NUMBER = 1; //adjust for your computer.
for ($i = 0; $i $NUMBER; $i++){
$data[$i] = $i;
}
function add_slow(){//This is the problematic function. $data is global,
and the count() is inside the for().
global $data; //It is REALLY slow: 4000 times slower than the others!
$sum=0;
for ($i = 0; $i count($data); $i++){
$sum += $data[$i];
}
echo Total (slow) is $sum.\n;
}
function add_fast(){//This one is fine. The count() is optimised by taking
it out of the for().
global $data; //... but we're still using a global array, so that's
not the problem.
$sum=0;
$n = count($data);
for ($i = 0; $i $n; $i++){
$sum += $data[$i];
}
echo Total (fast) is $sum.\n;
}
function add_local(){ //This one is also fine. The count() is NOT optimised,
but it still runs almost as quickly.
global $NUMBER;
for ($i = 0; $i $NUMBER; $i++){
$data[$i] = $i;
}
$sum=0;
for ($i = 0; $i count($data); $i++){
$sum += $data[$i];
}
echo Total (local) is $sum.\n;
}
echo Calling add_slow()...\n;
$t1 = microtime(true);
add_slow();
$t2 = microtime(true);
$time = round($t2 - $t1, 3);
echo Finished in $time seconds.\n\n;
echo Calling add_fast()...\n;
$t1 = microtime(true);
add_fast();
$t2 = microtime(true);
$time = round($t2 - $t1, 3);
echo Finished in $time seconds.\n\n;
echo Calling add_local()...\n;
$t1 = microtime(true
Bug #64518 [Com]: optimisation for for ($i=0; $icount($array);$i++) when $array is global
Edit report at https://bugs.php.net/bug.php?id=64518edit=1
ID: 64518
Comment by: php at richardneill dot org
Reported by:php at richardneill dot org
Summary:optimisation for for ($i=0; $icount($array);$i++)
when $array is global
Status: Open
Type: Bug
Package:Performance problem
PHP Version:5.4.13
Block user comment: N
Private report: N
New Comment:
... and getting closer to the source of the problem...
function a(){ //about 1400 us
global $data;
$n = $data;
}
function b(){ //much much quicker: about 18us
$n = $GLOBALS['data'];
}
Something is definitely wrong here, that makes global so much slower than
$GLOBALS.
Also, this isn't a read-only optimisation which makes b() much quicker than
a();
it still applies even when we want to copy back into the global scope.
Consider:
function x(){
$n = $GLOBALS['data'];
$GLOBALS['data'] = count($n);
}
and x() is always about as fast as b().
A secondary problem: if x() is rewritten as:
function y(){
$GLOBALS['data'] = count($GLOBALS['data']);
}
then it can be either fast or slow depending on whether other function calls
contain global $data or not.
Previous Comments:
[2013-03-26 06:09:30] php at richardneill dot org
Here's a simpler test case. The problem is actually that accessing global
variables from functions is much slower than local variables (and I was seeing
this exacerbated by looping over them with count).
Note that passing the data directly as a function argument is much faster than
passing it as a global variable - this seems to me to be the root of the
problem. i.e.
function ($a,$b,$c,$large_array){
//do stuff - this is fast.
}
function ($a,$b,$c){
global $large_array
//do stuff - this is SLOW.
}
#!/usr/bin/php -ddisplay_errors=E_ALL
?
$NUMBER = 10; //adjust for your computer.
for ($i = 0; $i $NUMBER; $i++){
$data[$i] = $i;
}
echo Copy in main()...\n;
$t1 = microtime(true);
$copy = $data;
$t2 = microtime(true);
$time = ($t2 - $t1) * 1E6;
echo Finished in $time microseconds.\n\n; #5.0 us
function f1(){
global $NUMBER;
echo Copy local variable in function...\n;
for ($i = 0; $i $NUMBER; $i++){
$data_loc[$i] = $i;
}
$t1 = microtime(true);
$copy = $data_loc;
$t2 = microtime(true);
$time = ($t2 - $t1) *1E6;
echo Finished in $time microseconds.\n\n; #1.9 us
}
function f2(){
global $data;
echo Copy global variable into function...\n;
$t1 = microtime(true);
$n = $data;
$t2 = microtime(true);
$time = ($t2 - $t1) *1E6;
echo Finished in $time microseconds.\n\n; #9557 us
}
function f3($data){
echo Pass variable into function...\n;
$t1 = microtime(true);
$n = $data;
$t2 = microtime(true);
$time = ($t2 - $t1) *1E6;
echo Finished in $time microseconds.\n\n; #0.95 us
}
f1();
f2();
f3($data);
echo Note that as \$NUMBER is changed by factors of 10, the first two times
don't change much, but the latter scales as O(\$NUMBER).\n;
?
[2013-03-26 05:17:44] php at richardneill dot org
Description:
If an array is counted inside a for-loop, this is normally slightly inefficient.
$n = count ($array); //[1] optimised and a bit faster.
for ($i=0; $i $n;$i++){
//do stuff
}
for ($i=0; $icount($array);$i++){//[2] perfectly respectable speed.
//do stuff //very nearly as fast as [1].
}
BUT, if our for-loop is inside a function AND our $array is a global variable,
then method [2] becomes really really slow (though method [1] remains
unaffected).
Below, the problematic function is add_slow(); the script does the same thing 4
ways to demonstrate that 3 of them work well and one works slowly.
Test script:
---
#!/usr/bin/php -ddisplay_errors=E_ALL
?
echo This demonstrates the problem with counting global arrays inside loops
inside functions.\n;
$NUMBER = 1; //adjust for your computer.
for ($i = 0; $i $NUMBER; $i++){
$data[$i] = $i;
}
function add_slow(){//This is the problematic function. $data is global,
and the count() is inside the for().
global $data; //It is REALLY slow: 4000 times slower than the others!
$sum=0;
for ($i = 0; $i count($data); $i++){
$sum += $data[$i];
}
echo Total (slow) is $sum.\n;
}
function add_fast(){//This one is fine. The count() is optimised by taking
it out of the for().
global $data; //... but we're still using a global array, so that's
not the problem
Bug #64518 [Nab]: optimisation for for ($i=0; $icount($array);$i++) when $array is global
Edit report at https://bugs.php.net/bug.php?id=64518edit=1
ID: 64518
User updated by:php at richardneill dot org
Reported by:php at richardneill dot org
Summary:optimisation for for ($i=0; $icount($array);$i++)
when $array is global
Status: Not a bug
Type: Bug
Package:Performance problem
PHP Version:5.4.13
Block user comment: N
Private report: N
New Comment:
The issue you are seeing is that `global $data` is a by-reference fetch
(unlike `$data = $GLOBALS['data']`, which is by-value). The by-ref pass
prevents us from doing a copy-on-write optimization when passing the array to
the by-value count() function, so the array has to be copied every single
time.
Thanks for the explanation. That makes some sense as an explanation. However,
it also implies that use of $GLOBALS['var'] is always faster, sometimes much
faster, than global $var. If this is true, might I suggest that this is a
documentation issue that should be addressed?
Previous Comments:
[2013-03-26 13:34:40] ni...@php.net
The issue you are seeing is that `global $data` is a by-reference fetch (unlike
`$data = $GLOBALS['data']`, which is by-value). The by-ref pass prevents us
from doing a copy-on-write optimization when passing the array to the by-value
count() function, so the array has to be copied every single time.
The specific count() case is something we could optimize by adding a read-only
passing mode for function arguments (that never separates zvals). As that is
something that's also useful for a few other things, it might well be worth
doing.
[2013-03-26 06:34:44] php at richardneill dot org
... and getting closer to the source of the problem...
function a(){ //about 1400 us
global $data;
$n = $data;
}
function b(){ //much much quicker: about 18us
$n = $GLOBALS['data'];
}
Something is definitely wrong here, that makes global so much slower than
$GLOBALS.
Also, this isn't a read-only optimisation which makes b() much quicker than
a();
it still applies even when we want to copy back into the global scope.
Consider:
function x(){
$n = $GLOBALS['data'];
$GLOBALS['data'] = count($n);
}
and x() is always about as fast as b().
A secondary problem: if x() is rewritten as:
function y(){
$GLOBALS['data'] = count($GLOBALS['data']);
}
then it can be either fast or slow depending on whether other function calls
contain global $data or not.
[2013-03-26 06:09:30] php at richardneill dot org
Here's a simpler test case. The problem is actually that accessing global
variables from functions is much slower than local variables (and I was seeing
this exacerbated by looping over them with count).
Note that passing the data directly as a function argument is much faster than
passing it as a global variable - this seems to me to be the root of the
problem. i.e.
function ($a,$b,$c,$large_array){
//do stuff - this is fast.
}
function ($a,$b,$c){
global $large_array
//do stuff - this is SLOW.
}
#!/usr/bin/php -ddisplay_errors=E_ALL
?
$NUMBER = 10; //adjust for your computer.
for ($i = 0; $i $NUMBER; $i++){
$data[$i] = $i;
}
echo Copy in main()...\n;
$t1 = microtime(true);
$copy = $data;
$t2 = microtime(true);
$time = ($t2 - $t1) * 1E6;
echo Finished in $time microseconds.\n\n; #5.0 us
function f1(){
global $NUMBER;
echo Copy local variable in function...\n;
for ($i = 0; $i $NUMBER; $i++){
$data_loc[$i] = $i;
}
$t1 = microtime(true);
$copy = $data_loc;
$t2 = microtime(true);
$time = ($t2 - $t1) *1E6;
echo Finished in $time microseconds.\n\n; #1.9 us
}
function f2(){
global $data;
echo Copy global variable into function...\n;
$t1 = microtime(true);
$n = $data;
$t2 = microtime(true);
$time = ($t2 - $t1) *1E6;
echo Finished in $time microseconds.\n\n; #9557 us
}
function f3($data){
echo Pass variable into function...\n;
$t1 = microtime(true);
$n = $data;
$t2 = microtime(true);
$time = ($t2 - $t1) *1E6;
echo Finished in $time microseconds.\n\n; #0.95 us
}
f1();
f2();
f3($data);
echo Note that as \$NUMBER is changed by factors of 10, the first two times
don't change much, but the latter scales as O(\$NUMBER).\n;
?
[2013-03-26 05:17:44] php at richardneill dot org
Description:
If an array is counted inside a for-loop, this is normally slightly inefficient.
$n = count
Bug #64518 [Nab]: optimisation for for ($i=0; $icount($array);$i++) when $array is global
Edit report at https://bugs.php.net/bug.php?id=64518edit=1
ID: 64518
User updated by:php at richardneill dot org
Reported by:php at richardneill dot org
Summary:optimisation for for ($i=0; $icount($array);$i++)
when $array is global
Status: Not a bug
Type: Bug
Package:Performance problem
PHP Version:5.4.13
Block user comment: N
Private report: N
New Comment:
I see your point about optimisations being too low-level, but some of these
things are hugely different in performance. Try running the following script:
http://www.richardneill.org/tmp/php-perf.txt
I notice 3 things.
1) Updating a variable in-place is 1000x slower than creating a new one.
Fast: $n = count($data);
Slow:$data = count($data);
2) Using $GLOBALS['var'] inside a function is very similar to using the same
variable in the main scope. Using global $var is always at least a bit slower.
3) Using global for just reading a variable is 100x slower than reading it from
$GLOBALS inside a function.
Fast: $n = count($GLOBALS['data'])
Slow: global $data; $n = count ($data)
I think that (3) might be a bug.
I also think that these differences are far from negligible, and so PHP's
documentation *should* mention them.
Previous Comments:
[2013-03-26 15:57:08] ni...@php.net
It's not always faster. Which one is faster is not very predictable without
good knowledge of the engine. We don't address such low-level details in the
manual.
[2013-03-26 15:15:38] php at richardneill dot org
The issue you are seeing is that `global $data` is a by-reference fetch
(unlike `$data = $GLOBALS['data']`, which is by-value). The by-ref pass
prevents us from doing a copy-on-write optimization when passing the array to
the by-value count() function, so the array has to be copied every single
time.
Thanks for the explanation. That makes some sense as an explanation. However,
it also implies that use of $GLOBALS['var'] is always faster, sometimes much
faster, than global $var. If this is true, might I suggest that this is a
documentation issue that should be addressed?
[2013-03-26 13:34:40] ni...@php.net
The issue you are seeing is that `global $data` is a by-reference fetch (unlike
`$data = $GLOBALS['data']`, which is by-value). The by-ref pass prevents us
from doing a copy-on-write optimization when passing the array to the by-value
count() function, so the array has to be copied every single time.
The specific count() case is something we could optimize by adding a read-only
passing mode for function arguments (that never separates zvals). As that is
something that's also useful for a few other things, it might well be worth
doing.
[2013-03-26 06:34:44] php at richardneill dot org
... and getting closer to the source of the problem...
function a(){ //about 1400 us
global $data;
$n = $data;
}
function b(){ //much much quicker: about 18us
$n = $GLOBALS['data'];
}
Something is definitely wrong here, that makes global so much slower than
$GLOBALS.
Also, this isn't a read-only optimisation which makes b() much quicker than
a();
it still applies even when we want to copy back into the global scope.
Consider:
function x(){
$n = $GLOBALS['data'];
$GLOBALS['data'] = count($n);
}
and x() is always about as fast as b().
A secondary problem: if x() is rewritten as:
function y(){
$GLOBALS['data'] = count($GLOBALS['data']);
}
then it can be either fast or slow depending on whether other function calls
contain global $data or not.
[2013-03-26 06:09:30] php at richardneill dot org
Here's a simpler test case. The problem is actually that accessing global
variables from functions is much slower than local variables (and I was seeing
this exacerbated by looping over them with count).
Note that passing the data directly as a function argument is much faster than
passing it as a global variable - this seems to me to be the root of the
problem. i.e.
function ($a,$b,$c,$large_array){
//do stuff - this is fast.
}
function ($a,$b,$c){
global $large_array
//do stuff - this is SLOW.
}
#!/usr/bin/php -ddisplay_errors=E_ALL
?
$NUMBER = 10; //adjust for your computer.
for ($i = 0; $i $NUMBER; $i++){
$data[$i] = $i;
}
echo Copy in main()...\n;
$t1 = microtime(true);
$copy = $data;
$t2 = microtime(true);
$time = ($t2 - $t1) * 1E6;
echo Finished in $time microseconds.\n\n; #5.0 us
function f1(){
global
[PHP-BUG] Req #64516 [NEW]: wish: add flag to preg_quote to escape the replacement
From: php at richardneill dot org Operating system: all PHP version: 5.4.13 Package: PCRE related Bug Type: Feature/Change Request Bug description:wish: add flag to preg_quote to escape the replacement Description: preg_quote() is great for escaping a user-supplied search string. There is no matching function to escape a user-supplied replacement string. My wish is for preg_quote() to have an extra flag IS_REPLACEMENT or to have a function preg_quote_replacement(), which would escape only backslash and dollar signs. Example below. Might I also suggest this is a documentation bug, in that there is no explanation of the correct way to work around this? Test script: --- $text = 'Invoice: You owe me *#5* !'; $user_search = *#5*; $user_replace = *$5*; $search = preg_quote($user_search, /); $replace_bad1 = $user_replace; $replace_bad2 = preg_quote($user_replace); $new_text1 = preg_replace(/$search/, $replace_bad1, $text); $new_text2 = preg_replace(/$search/, $replace_bad2, $text); echo Input: $text\nNew1: $new_text1\nNew2: $new_text2\n; Expected result: I want to return the string: Invoice: You owe me *$5* ! Actual result: -- Input: Invoice: You owe me *#5* ! New1: Invoice: You owe me ** ! New2: Invoice: You owe me \*$5\* ! 1. the '*' in the search string is not magic, thanks to the normal use of preg_quote(). This is what I expect. 2. If I replace with a literal, then '$5' becomes the 5th backreference, which is empty. 3. If I preg_quote the replacement, then we get spurious backslashes before the '*'s. -- Edit bug report at https://bugs.php.net/bug.php?id=64516edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64516r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64516r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64516r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64516r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64516r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64516r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64516r=needscript Try newer version: https://bugs.php.net/fix.php?id=64516r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64516r=support Expected behavior: https://bugs.php.net/fix.php?id=64516r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64516r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64516r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64516r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64516r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64516r=dst IIS Stability: https://bugs.php.net/fix.php?id=64516r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64516r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64516r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64516r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64516r=mysqlcfg
[PHP-BUG] Bug #64518 [NEW]: optimisation for for ($i=0; $icount($array);$i++) when $array is global
From: php at richardneill dot org
Operating system:
PHP version: 5.4.13
Package: Performance problem
Bug Type: Bug
Bug description:optimisation for for ($i=0; $icount($array);$i++) when
$array is global
Description:
If an array is counted inside a for-loop, this is normally slightly
inefficient.
$n = count ($array); //[1] optimised and a bit faster.
for ($i=0; $i $n;$i++){
//do stuff
}
for ($i=0; $icount($array);$i++){//[2] perfectly respectable speed.
//do stuff //very nearly as fast as [1].
}
BUT, if our for-loop is inside a function AND our $array is a global
variable,
then method [2] becomes really really slow (though method [1] remains
unaffected).
Below, the problematic function is add_slow(); the script does the same
thing 4
ways to demonstrate that 3 of them work well and one works slowly.
Test script:
---
#!/usr/bin/php -ddisplay_errors=E_ALL
?
echo This demonstrates the problem with counting global arrays inside
loops inside functions.\n;
$NUMBER = 1; //adjust for your computer.
for ($i = 0; $i $NUMBER; $i++){
$data[$i] = $i;
}
function add_slow(){//This is the problematic function. $data is global,
and the count() is inside the for().
global $data; //It is REALLY slow: 4000 times slower than the others!
$sum=0;
for ($i = 0; $i count($data); $i++){
$sum += $data[$i];
}
echo Total (slow) is $sum.\n;
}
function add_fast(){//This one is fine. The count() is optimised by taking
it out of the for().
global $data; //... but we're still using a global array, so that's
not
the problem.
$sum=0;
$n = count($data);
for ($i = 0; $i $n; $i++){
$sum += $data[$i];
}
echo Total (fast) is $sum.\n;
}
function add_local(){ //This one is also fine. The count() is NOT
optimised, but it still runs almost as quickly.
global $NUMBER;
for ($i = 0; $i $NUMBER; $i++){
$data[$i] = $i;
}
$sum=0;
for ($i = 0; $i count($data); $i++){
$sum += $data[$i];
}
echo Total (local) is $sum.\n;
}
echo Calling add_slow()...\n;
$t1 = microtime(true);
add_slow();
$t2 = microtime(true);
$time = round($t2 - $t1, 3);
echo Finished in $time seconds.\n\n;
echo Calling add_fast()...\n;
$t1 = microtime(true);
add_fast();
$t2 = microtime(true);
$time = round($t2 - $t1, 3);
echo Finished in $time seconds.\n\n;
echo Calling add_local()...\n;
$t1 = microtime(true);
add_local();
$t2 = microtime(true);
$time = round($t2 - $t1, 3);
echo Finished in $time seconds.\n\n;
echo Not using a function...\n;
$t1 = microtime(true);
$sum=0;
for ($i = 0; $i count($data); $i++){ //This one is in the main() scope,
it's also fast.
$sum += $data[$i];
}
echo Total (main loop) is $sum.\n;
$t2 = microtime(true);
$time = round($t2 - $t1, 3);
echo Finished in $time seconds.\n\n;
?
Expected result:
All 4 ways of summing this array should run in similar amounts of time (a
few
milliseconds).
But actually add_slow() is 3900 times slower.
Actual result:
--
This demonstrates the problem with counting global arrays inside loops
inside
functions.
Calling add_slow()...
Total (slow) is 49995000.
Finished in 7.86 seconds.
Calling add_fast()...
Total (fast) is 49995000.
Finished in 0.002 seconds.
Calling add_local()...
Total (local) is 49995000.
Finished in 0.006 seconds.
Not using a function...
Total (main loop) is 49995000.
Finished in 0.002 seconds.
--
Edit bug report at https://bugs.php.net/bug.php?id=64518edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64518r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64518r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64518r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64518r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64518r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64518r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64518r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64518r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64518r=support
Expected behavior: https://bugs.php.net/fix.php?id=64518r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64518r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64518r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64518r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64518r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64518r=dst
IIS Stability: https://bugs.php.net
[PHP-BUG] Req #64488 [NEW]: Allow open tag to discard the previous shebang
From: php at richardneill dot org
Operating system:
PHP version: 5.4.13
Package: CGI/CLI related
Bug Type: Feature/Change Request
Bug description:Allow open tag to discard the previous shebang
Description:
It would be really useful to be able to write single files that would run
cleanly
as *either* CGI or CLI scripts.
At the moment, the closing '?' tag will eat the trailing newline.
So, similarly, I'd like to request a way for the opening '?' tag to eat
the
previous literal shebang line.
Test script:
---
#!/usr/bin/php
?
if (php_sapi_name()== cgi){
erase_previous_line() -- hypothetical function.
echo I am CGIbr;
}else{
echo I am CLI\n;
}
?
Expected result:
Exactly one line should be printed:
I am CLI|CGI
Actual result:
--
In CLI mode, this script cleanly prints:
I am CLI
but in Apache mode, the script prints the first line literally:
#!/usr/bin/php
I am CGIbr
It's relatively easy to work around this with a wrapper script, but I'd
appreciate the elegance of having a single file that can operate in both
modes.
Thank you for your time.
--
Edit bug report at https://bugs.php.net/bug.php?id=64488edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64488r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64488r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64488r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64488r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64488r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64488r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64488r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64488r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64488r=support
Expected behavior: https://bugs.php.net/fix.php?id=64488r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64488r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64488r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64488r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64488r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64488r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64488r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64488r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64488r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64488r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64488r=mysqlcfg
[PHP-BUG] Req #64320 [NEW]: Proposal: deprecate the leading 0 means octal behaviour
From: php at richardneill dot org Operating system: All PHP version: 5.4.12 Package: Math related Bug Type: Feature/Change Request Bug description:Proposal: deprecate the leading 0 means octal behaviour Description: PHP assumes that a string with a leading zero should be interpreted as octal. In my experience, this is almost never useful, desirable, or intentional, however, it is a frequent trap for the beginner (or more experienced programmer), especially when parsing user-submitted data. The only reason for this behaviour seems to be historical, and compatibility with strtol(). When non-programmer humans write numbers with leading zeros, they don't usually mean base 8. My proposal is: 1. Introduce a new string format, 0o (letter o), to explicitly mean this is an octal number. This is similar to the recent introduction of 0b for binary numbers. [This part should be simple to do, and would also make the intentional use of octal notation explicit, increasing code-readability] 2. Add an option to raise E_NOTICE any time a number is implicitly interpreted as octal (for example $x = 0100). 3. In a few years time, (PHP 7?), it may finally be possible to change the default behaviour. Test script: --- Here's an illustration of a naive program that has data-dependent bugs that are really hard to track down. $mass_kg = 0.314 //user-submitted data, known to begin 0. $mass_g = substr ($mass_kg, 2); Yes, this is a silly thing to write. But it's a nasty trap for the unwary. The above example does what is expected, and might pass many tests. But if the user subsequently enters $mass_kg = 0.031, this will turn into 25 grams, not 31 grams. As a result, we have created a very subtle and hard to find bug. -- Edit bug report at https://bugs.php.net/bug.php?id=64320edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64320r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64320r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64320r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64320r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64320r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64320r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64320r=needscript Try newer version: https://bugs.php.net/fix.php?id=64320r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64320r=support Expected behavior: https://bugs.php.net/fix.php?id=64320r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64320r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64320r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64320r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64320r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64320r=dst IIS Stability: https://bugs.php.net/fix.php?id=64320r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64320r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64320r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64320r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64320r=mysqlcfg
Req #64320 [Fbk-Csd]: Proposal: deprecate the leading 0 means octal behaviour
Edit report at https://bugs.php.net/bug.php?id=64320edit=1 ID: 64320 User updated by:php at richardneill dot org Reported by:php at richardneill dot org Summary:Proposal: deprecate the leading 0 means octal behaviour -Status: Feedback +Status: Closed Type: Feature/Change Request Package:Math related Operating System: All PHP Version:5.4.12 Block user comment: N Private report: N New Comment: You know, that bug has annoyed me for ages, since I got badly bitten by it about 7 years ago. In the meantime, I think it's been fixed! At any rate, I now agree with you that the current behaviour is correct, and that: PHP now treats strings with leading zeros (eg 0123) as decimal (123), rather than octal, even when automatically casting them. The documentation (in the sections: integers, casting) could perhaps be more explicit, given that: $a = 0x123; $b = 0x123 + 0; // $a and $b are equal $c = 0123; $d = 0123 + 0; // $c and $d are not equal. Sorry for the confusion - my bad. Previous Comments: [2013-02-28 17:14:36] ni...@php.net Could you maybe provide a testcase for the behavior you are referring to? I tried out the following and 010 wasn't interpreted as octal in any case: var_dump((int) 010, intval(010), 010 == 8); // Outputs: int(10) int(10) bool(false) 010 is only treated as an octal if you write it out plainly (in the source code), like $foo = 010; [2013-02-28 13:41:48] php at richardneill dot org Description: PHP assumes that a string with a leading zero should be interpreted as octal. In my experience, this is almost never useful, desirable, or intentional, however, it is a frequent trap for the beginner (or more experienced programmer), especially when parsing user-submitted data. The only reason for this behaviour seems to be historical, and compatibility with strtol(). When non-programmer humans write numbers with leading zeros, they don't usually mean base 8. My proposal is: 1. Introduce a new string format, 0o (letter o), to explicitly mean this is an octal number. This is similar to the recent introduction of 0b for binary numbers. [This part should be simple to do, and would also make the intentional use of octal notation explicit, increasing code-readability] 2. Add an option to raise E_NOTICE any time a number is implicitly interpreted as octal (for example $x = 0100). 3. In a few years time, (PHP 7?), it may finally be possible to change the default behaviour. Test script: --- Here's an illustration of a naive program that has data-dependent bugs that are really hard to track down. $mass_kg = 0.314 //user-submitted data, known to begin 0. $mass_g = substr ($mass_kg, 2); Yes, this is a silly thing to write. But it's a nasty trap for the unwary. The above example does what is expected, and might pass many tests. But if the user subsequently enters $mass_kg = 0.031, this will turn into 25 grams, not 31 grams. As a result, we have created a very subtle and hard to find bug. -- Edit this bug report at https://bugs.php.net/bug.php?id=64320edit=1
[PHP-BUG] Bug #62998 [NEW]: pg_query_params() doesn't handle NULL
From: php at richardneill dot org Operating system: Linux PHP version: 5.3.16 Package: PostgreSQL related Bug Type: Bug Bug description:pg_query_params() doesn't handle NULL Description: pg_query_params($conn,$sql,$params) is supposed to correctly handle NULL-SQL_NULL. It doesn't do this (despite the documentation); instead it breaks the query. Documentation If parameters are used, they are referred to in the query string as $1, $2, etc. params specifies the actual values of the parameters. A NULL value in this array means the corresponding parameter is SQL NULL. Test script: --- Here's a simple example: $result = pg_query_params ($conn, select CASE WHEN NULL is $1 then 'it is null' ELSE 'it is not null' END, array(NULL) ); echo pg_last_error($conn); print_r (pg_fetch_assoc($result)); This query fails, because the parameter $1 is not actually passed as NULL, instead it seems to be the empty string. My SQL is definitely right: pg_query_params ($conn, select CASE WHEN NULL is NULL then 'it is null' ELSE 'it is not null' END, array() ); works fine, to return the string it is null. Expected result: It should be possible to pass SQL_NULL to the database in a parameter. -- Edit bug report at https://bugs.php.net/bug.php?id=62998edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62998r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62998r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62998r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62998r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62998r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62998r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62998r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62998r=needscript Try newer version: https://bugs.php.net/fix.php?id=62998r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62998r=support Expected behavior: https://bugs.php.net/fix.php?id=62998r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62998r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62998r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62998r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62998r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62998r=dst IIS Stability: https://bugs.php.net/fix.php?id=62998r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62998r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62998r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62998r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62998r=mysqlcfg
Bug #43627 [Com]: fopen blocks on fifo
Edit report at https://bugs.php.net/bug.php?id=43627edit=1
ID: 43627
Comment by: php at richardneill dot org
Reported by:user at example dot com
Summary:fopen blocks on fifo
Status: Bogus
Type: Bug
Package:Filesystem function related
Operating System: Debian Etch and RHEL 5
PHP Version:5.2.5
Block user comment: N
Private report: N
New Comment:
Similarly, fopen blocks if the fifo is opened for writing, and the other side
isn't being read yet: $fp = fopen('myfifo', 'w');
I'd expect the fwrite() to block, but not the fopen().
Linux's man fifo says that this is the default behaviour, but that it is
possible to make it non-blocking. This would be useful, because we can't call
stream_select() to find out whether writes would block until we have fopen()'d
the pipe, but fopen() blocks. There is no way to test in advance whether
fopen() would block, because most cases don't expect it to.
Previous Comments:
[2008-01-29 00:15:50] tony2...@php.net
man open
man 7 fifo
Normally, opening the FIFO blocks until the other end is opened also.
[2007-12-18 16:59:10] user at example dot com
Description:
fopen() blocks waiting for read on named pipes (FIFOs) opened for reading.
Reproduce code:
---
At Unix prompt:
% mkfifo myfifo
PHP:
$fp = fopen('myfifo', 'r');
Expected result:
PHP execution should continue until attempting to read from the FIFO, e.g.:
fread($fp, 1);
Actual result:
--
PHP execution suspends (blocks) on the fopen() command until another process
writes data to the FIFO.
--
Edit this bug report at https://bugs.php.net/bug.php?id=43627edit=1
[PHP-BUG] Bug #54614 [NEW]: Trivial RE failure: /([^b]*a*)*$/
From:
Operating system: Linux
PHP version: 5.3.6
Package: *Regular Expressions
Bug Type: Bug
Bug description:Trivial RE failure: /([^b]*a*)*$/
Description:
If I search in the string : 'b'
with the RE: '/([^b]*a*)*$/'
then preg_replace fails with a backtrack-limit error. (error 2)
I have backtrack.limit configured to 32MB, so something is very wrong.
The example fails on several different PHP versions, CPU architectures and
Linux
Distros. However, using Perl for the same RE works fine.
Test script:
---
$contents = b;
$search = '/([^b]*a*)*$/';
$result = preg_replace($search,x,$contents);
if ($result === NULL){
echo preg failed, error is .preg_last_error().\n;
}else{
echo success\n;
}
Expected result:
preg_replace shouldn't fail.
Actual result:
--
preg_replace returns NULL, and preg_last_error returns 2.
--
Edit bug report at http://bugs.php.net/bug.php?id=54614edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54614r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54614r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54614r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54614r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54614r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54614r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54614r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54614r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54614r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54614r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54614r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54614r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54614r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54614r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54614r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54614r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54614r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54614r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54614r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54614r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54614r=mysqlcfg
Bug #54614 [Opn]: Trivial RE failure: /([^b]*a*)*$/
Edit report at http://bugs.php.net/bug.php?id=54614edit=1
ID: 54614
User updated by:php at richardneill dot org
Reported by:php at richardneill dot org
Summary:Trivial RE failure: /([^b]*a*)*$/
Status: Open
Type: Bug
Package:*Regular Expressions
Operating System: Linux
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
A slightly simpler test case is:
$contents = b;
$search = '/(a*a*)*$/';
Previous Comments:
[2011-04-27 18:43:02] php at richardneill dot org
Description:
If I search in the string : 'b'
with the RE: '/([^b]*a*)*$/'
then preg_replace fails with a backtrack-limit error. (error 2)
I have backtrack.limit configured to 32MB, so something is very wrong.
The example fails on several different PHP versions, CPU architectures
and Linux
Distros. However, using Perl for the same RE works fine.
Test script:
---
$contents = b;
$search = '/([^b]*a*)*$/';
$result = preg_replace($search,x,$contents);
if ($result === NULL){
echo preg failed, error is .preg_last_error().\n;
}else{
echo success\n;
}
Expected result:
preg_replace shouldn't fail.
Actual result:
--
preg_replace returns NULL, and preg_last_error returns 2.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54614edit=1
Bug #54614 [Fbk-Opn]: Trivial RE failure: /([^b]*a*)*$/
Edit report at http://bugs.php.net/bug.php?id=54614edit=1
ID: 54614
User updated by:php at richardneill dot org
Reported by:php at richardneill dot org
Summary:Trivial RE failure: /([^b]*a*)*$/
-Status: Feedback
+Status: Open
Type: Bug
Package:*Regular Expressions
Operating System: Linux
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Sorry, my bad (sort of).
There is a genuine bug that affected longer regexps even with
backtrack.limit set
to 32M, which I saw on 5.3.2, but is now solved on 5.3.6.
Unfortunately, the test-case which I simplified for the bug-report
didn't
remember to set backtrack.limit (I thought I'd done it in php.ini, but
had
actually done it explicitly with ini.set in my original script). So the
test
case:
- works for backtrack.limit = 1M (on both 5.3.2 and 5.3.6)
- fails for the default 100k on both.
Either way, it's still something that, imho, should work on a default
install.
May I make a few suggestions:
* backtrack.limit should be raised by default, to at least 10M.
* backtrack.limit should default to 100M for the CLI version of PHP.
* validating bug reports is painful, partly because I had to spend some
extra
time tracking down the latest version of PHP and building it. This is
error-
prone. How about providing a sandboxed VM on bugs.php.net where we can
paste our
own code to check it? This would make it far easier to file correct bug
reports.
(it would take the reporter 3 minutes, rather than an hour).
Previous Comments:
[2011-04-27 21:54:07] ras...@php.net
With pcre.backtrack_limit = 100 this works fine for me on 5.3.6. Are
you sure
you increased the limit in the right place?
[2011-04-27 21:15:34] php at richardneill dot org
A slightly simpler test case is:
$contents = b;
$search = '/(a*a*)*$/';
[2011-04-27 18:43:02] php at richardneill dot org
Description:
If I search in the string : 'b'
with the RE: '/([^b]*a*)*$/'
then preg_replace fails with a backtrack-limit error. (error 2)
I have backtrack.limit configured to 32MB, so something is very wrong.
The example fails on several different PHP versions, CPU architectures
and Linux
Distros. However, using Perl for the same RE works fine.
Test script:
---
$contents = b;
$search = '/([^b]*a*)*$/';
$result = preg_replace($search,x,$contents);
if ($result === NULL){
echo preg failed, error is .preg_last_error().\n;
}else{
echo success\n;
}
Expected result:
preg_replace shouldn't fail.
Actual result:
--
preg_replace returns NULL, and preg_last_error returns 2.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54614edit=1
Bug #42424 [Com]: PHP5/PCRE fails to match long strings when ungreedy
Edit report at http://bugs.php.net/bug.php?id=42424edit=1 ID: 42424 Comment by: php at richardneill dot org Reported by:adam-phpbugs at adam dot gs Summary:PHP5/PCRE fails to match long strings when ungreedy Status: Bogus Type: Bug Package:PCRE related Operating System: Any PHP Version:5.2.3 Block user comment: N Private report: N New Comment: This isn't bogus; it should at the very least raise an error E_NOTICE. I've just spent 7 hours tracking down a problem caused by this bug. and generating you a helpful report: http://www.richardneill.org/tmp/preg-error2.txt I do understand the rationale for the limits (though personally, I think they are 3 orders of magnitude too small, and I'd much rather my script segfaulted rather than silently introducing subtle processing errors to my data). Could we at least make sure that with display_errors (E_ALL) we get some kind of notification? At minimum, a notice would do, though ideally, this should be a fatal error. Previous Comments: [2007-08-27 11:17:15] j...@php.net In PHP 5.2.0 two new PCRE ini options were added to prevent possible stack overflows and crashes. One of them is pcre.backtrack_limit. When you set it high enough your script works as it did earlier (where no such limits existed!) $ php -dpcre.backtrack_limit=11 t.php int(1) int(1) int(1) int(1) [2007-08-25 13:16:29] adam-phpbugs at adam dot gs Description: PHP5/PCRE will fail to match on long strings when UNGREEDY, the boundary is around 100k of data. FWIW, same results if you change x* to x+ down there. Reproduce code: --- ?php $data=sprintf(span%s/span,str_repeat(x,6)); var_dump(preg_match(#span(x*?)/span#,$data)); $data=sprintf(span%s/span,str_repeat(x,7)); var_dump(preg_match(#span(x*?)/span#,$data)); $data=sprintf(span%s/span,str_repeat(x,7)); var_dump(preg_match(#span(x*)/span#U,$data)); $data=sprintf(span%s/span,str_repeat(x,7)); var_dump(preg_match(#span(x*)/span#,$data)); ? Expected result: all 4 expressions should match, this is what occurs with PHP 4.4.7. Actual result: -- under PHP 5.2.3: only the first and 4th expression match under PHP 4.4.7: all 4 match. -- Edit this bug report at http://bugs.php.net/bug.php?id=42424edit=1
Req #25334 [Wfx]: edit_ini_file() function would be nice
Edit report at http://bugs.php.net/bug.php?id=25334edit=1 ID: 25334 User updated by:php at richardneill dot org Reported by:php at richardneill dot org Summary:edit_ini_file() function would be nice Status: Wont fix Type: Feature/Change Request Package:PHP options/info functions Operating System: Linux (Mandrake 9.1) PHP Version:4.3.1 Block user comment: N Private report: N New Comment: Yes...but why re-write this so many times? Since this original report, I think I've implemented such a system at least 4 times in different ways, and it seems to be a really obvious candidate for a core library. It's also quite hard to handle the awkward cases, notably preserving comments. Previous Comments: [2011-01-01 21:05:47] j...@php.net For something like this you have plenty of functions in PHP to implement it yourself in PHP code. [2003-08-31 19:25:30] php at richardneill dot org Description: Here's an idea that I think would be useful for a new function. I'd like a way to have an editable equivalent of parse_ini_file(). Many Unix programs have config files that can be edited *both* by hand, or automatically by the program. It would be nice to be able to do this in php. Eg if the file myfile.dat contains something like this: //This is a custom config or data file $foo=bar; #comment2 $wibble=bibble; /*comment 3*/ $aaa=3; Then, I might call the following in my script: edit_ini_file (myfile.dat, SET $foo=baz, UNSET $wibble, SET $bbb=4) And as a result, the file would be appropriately changed, without modifying the comments. In this case it would become: //This is a custom config/data file $foo=baz; #comment2 $wibble=false; /*comment 3*/ $aaa=3 $bbb=4; I'd suggest the function should be able to: 1)SET a variable (i.e. change it if it exists, otherwise, set it) 2)UNSET a variable 3)Add a comment (after a particular variable) 4)Change a comment. If I can be of any assistance, please let me know. I hope you like the idea. Thanks for PHP - I love it :-) -- Edit this bug report at http://bugs.php.net/bug.php?id=25334edit=1
[PHP-BUG] Req #52166 [NEW]: REF: support ionice
From: Operating system: Linux PHP version: Irrelevant Package: Program Execution Bug Type: Feature/Change Request Bug description:REF: support ionice Description: PHP has proc_nice(), but no corresponding proc_ionice(). This would be a very nice addition to have. On most current computers, the CPU bandwidth is not the limiting factor, but I/O is. So a process that has been invoked with nice -n 19 can still bring the system to a crawl if it does a lot of disk activity. The solution is ionice -c3. Typically: nice -n 19 ionice -c3 $program -- Edit bug report at http://bugs.php.net/bug.php?id=52166edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52166r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52166r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52166r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52166r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52166r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52166r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52166r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52166r=needscript Try newer version: http://bugs.php.net/fix.php?id=52166r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52166r=support Expected behavior: http://bugs.php.net/fix.php?id=52166r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52166r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52166r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52166r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52166r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52166r=dst IIS Stability: http://bugs.php.net/fix.php?id=52166r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52166r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52166r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52166r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52166r=mysqlcfg
[PHP-BUG] Req #52071 [NEW]: RFE: ping
From: Operating system: Linux PHP version: Irrelevant Package: Network related Bug Type: Feature/Change Request Bug description:RFE: ping Description: Surprisingly, PHP is missing the ability to ping another host (and check it's alive). So I'd like to make a request to add it. I'd suggest using something like fping rather than standard ping, as this is more script-friendly - for example, fping can be made to return immediately as soon as it discovers that a given host is alive. For example: fping -q -B1 www.php.net I know that there is Net_Ping available via PEAR, but often PEAR extensions aren't available on many hosting environments; likewise it's awkward to package a PHP web-application when the PEAR extension isn't already packaged for the distro. Is ping suficiently fundamental to be considered core? Test script: --- This command should either exist in 2 forms, or have several options. Typical use cases are: 1. Is machine X alive (and responding to Pings) 2. Can I do a DNS lookup + route to that machine 3. What is the packet loss fraction. This is easy enough to do by using exec(), but it would be nice to have a native function. Thanks. -- Edit bug report at http://bugs.php.net/bug.php?id=52071edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52071r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52071r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52071r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52071r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52071r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52071r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52071r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52071r=needscript Try newer version: http://bugs.php.net/fix.php?id=52071r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52071r=support Expected behavior: http://bugs.php.net/fix.php?id=52071r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52071r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52071r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52071r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52071r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52071r=dst IIS Stability: http://bugs.php.net/fix.php?id=52071r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52071r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52071r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52071r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52071r=mysqlcfg
[PHP-BUG] Req #52072 [NEW]: RFE: can we have `which`
From: Operating system: Linux PHP version: Irrelevant Package: Filesystem function related Bug Type: Feature/Change Request Bug description:RFE: can we have `which` Description: It would be nice if PHP had a builtin which command. For example, which(ffmpeg) would allow the user to check whether ffmpeg was installed, prior to calling it with exec(). Test script: --- which(ffmpeg) should return eg: /usr/bin/ffmpeg if the command exists, and is in the £PATH for exec(), or false if it doesn't exist. -- Edit bug report at http://bugs.php.net/bug.php?id=52072edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52072r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52072r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52072r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52072r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52072r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52072r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52072r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52072r=needscript Try newer version: http://bugs.php.net/fix.php?id=52072r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52072r=support Expected behavior: http://bugs.php.net/fix.php?id=52072r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52072r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52072r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52072r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52072r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52072r=dst IIS Stability: http://bugs.php.net/fix.php?id=52072r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52072r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52072r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52072r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52072r=mysqlcfg
[PHP-BUG] Req #52073 [NEW]: RFE: a few more options to exec()
From: Operating system: PHP version: Irrelevant Package: Program Execution Bug Type: Feature/Change Request Bug description:RFE: a few more options to exec() Description: Exec() is missing a few key features: 1. The ability to return STDERR separately from STDOUT. At the moment, we can get STDOUT back in $output, but STDERR is either logged (for php-cgi) or sent to the main script STDERR (for php-cli). The user has the choice to append 21, but it would be really helpful to have stderr and stdout both returned in separate arrays. 2. The ability to choose the shell. At the moment, exec() uses apache's shell, which is usually /bin/sh (either as bash or ash depending on distro). If bash-isms are required, we can work around this with bash -c '.. ', but it would be a nice feature. 3. If a process is forked, then we'd like to get the PID, $!. Currently this can only be achieved thus: exec (foo echo $!, $output) but we must sacrifice stdout for the purpose. 4. Optionally, some way to do execv(arg1, arg2, arg3) Test script: --- I'd suggest having a function: exec( string $command [, array $stdout [,int $retval [,array $stderr [,int $pid [,int options = BASH|SH|CSH ] ] ] ] ] ) -- Edit bug report at http://bugs.php.net/bug.php?id=52073edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52073r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52073r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52073r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52073r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52073r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52073r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52073r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52073r=needscript Try newer version: http://bugs.php.net/fix.php?id=52073r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52073r=support Expected behavior: http://bugs.php.net/fix.php?id=52073r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52073r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52073r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52073r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52073r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52073r=dst IIS Stability: http://bugs.php.net/fix.php?id=52073r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52073r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52073r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52073r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52073r=mysqlcfg
[PHP-BUG] Req #52074 [NEW]: RFE: tempdir() countrpart to tempnam()
From: Operating system: PHP version: Irrelevant Package: Directory function related Bug Type: Feature/Change Request Bug description:RFE: tempdir() countrpart to tempnam() Description: It would be really useful to have the ability to create a tempdir, with a unique name, which we know we can write to, and will be automatically cleaned up. For example, if I want to run an external command (with exec() ) which will write to a file, where: - it must be known that file-creation can succeed - the file does not exist at the moment Test script: --- Some applications will refuse to overwrite an existing file (that we created with tempnam()), because they don't want to clobber it. What we effectively need is a race-free way to assign a temp-filename without actually creating the file. Using tmpfile() doesn't help, because we can't pass a file-handle to php's exec(). -- Edit bug report at http://bugs.php.net/bug.php?id=52074edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52074r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52074r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52074r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52074r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52074r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52074r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52074r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52074r=needscript Try newer version: http://bugs.php.net/fix.php?id=52074r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52074r=support Expected behavior: http://bugs.php.net/fix.php?id=52074r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52074r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52074r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52074r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52074r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52074r=dst IIS Stability: http://bugs.php.net/fix.php?id=52074r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52074r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52074r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52074r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52074r=mysqlcfg
Req #52072 [Wfx]: RFE: can we have `which`
Edit report at http://bugs.php.net/bug.php?id=52072edit=1
ID: 52072
User updated by: php at richardneill dot org
Reported by: php at richardneill dot org
Summary: RFE: can we have `which`
Status: Wont fix
Type: Feature/Change Request
Package: Filesystem function related
Operating System: Linux
PHP Version: Irrelevant
New Comment:
Thanks for your quick reply. I agree - it's trivial to do in userspace.
The simplest way is just to
$lastline = exec (which $ffmpeg, $output, $retval)
if (retval){
return ($lastline)
}else{
return ($false)
}
Indeed many of the PHP functions are trivial in that sense - one could
build file_get_contents() out of fopen(),file(),fclose(), or could avoid
using unlink by a call to system(rm filename).
However the attraction of PHP is that so many of the required functions
already exist and I don't have to write them. So I think that which()
would be a useful addition.
I'm particularly thinking of the cases where php-cli is an improvement
on shell-scripting.
Previous Comments:
[2010-06-13 02:47:08] ras...@php.net
This seems trivial to do in userspace to me:
function which($cmd) {
$paths = explode(':',$_ENV['PATH']);
foreach($paths as $path) {
$p = $path.'/'.$cmd;
if(file_exists($p)) return $p;
}
return false;
}
[2010-06-13 02:34:12] php at richardneill dot org
Description:
It would be nice if PHP had a builtin which command.
For example, which(ffmpeg) would allow the user to check whether
ffmpeg
was installed, prior to calling it with exec().
Test script:
---
which(ffmpeg) should return eg:
/usr/bin/ffmpeg
if the command exists, and is in the £PATH for exec(), or
false
if it doesn't exist.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52072edit=1
Req #52071 [Wfx]: RFE: ping
Edit report at http://bugs.php.net/bug.php?id=52071edit=1
ID: 52071
User updated by: php at richardneill dot org
Reported by: php at richardneill dot org
Summary: RFE: ping
Status: Wont fix
Type: Feature/Change Request
Package: Network related
Operating System: Linux
PHP Version: Irrelevant
New Comment:
I do see your point. On the other hand, I can (as a normal user) quite
easily use ping by relying on that Setuid binary, via exec(). Wouldn't
this approach work?
(the key win here is to eliminate needing exec(), which tends to upset
nervous managers during code-review)
Previous Comments:
[2010-06-13 02:38:27] ras...@php.net
This is not going to work in most PHP environments because doing
raw-socket ICMP
requests, like ping does requires root access. You will notice that
your ping
binary is setuid-root on your machine, so unless you are running PHP as
root,
doing it from within PHP simply won't work.
If you do have root access, it isn't that hard to do with a
socket_create(AF_INET, SOCK_RAW, getprotobyname('icmp')) call, but
since it
wouldn't work for most people, I don't see the point in adding it to
PHP.
[2010-06-13 02:28:38] php at richardneill dot org
Description:
Surprisingly, PHP is missing the ability to ping another host (and check
it's
alive). So I'd like to make a request to add it. I'd suggest using
something
like fping rather than standard ping, as this is more script-friendly -
for
example, fping can be made to return immediately as soon as it discovers
that
a given host is alive. For example:
fping -q -B1 www.php.net
I know that there is Net_Ping available via PEAR, but often PEAR
extensions
aren't available on many hosting environments; likewise it's awkward to
package a PHP web-application when the PEAR extension isn't already
packaged
for the distro. Is ping suficiently fundamental to be considered core?
Test script:
---
This command should either exist in 2 forms, or have several options.
Typical use cases are:
1. Is machine X alive (and responding to Pings)
2. Can I do a DNS lookup + route to that machine
3. What is the packet loss fraction.
This is easy enough to do by using exec(), but it would be nice to have
a native function. Thanks.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52071edit=1
Bug #22890 [Com]: CLI setuid scripts don't run setuid
Edit report at http://bugs.php.net/bug.php?id=22890edit=1 ID: 22890 Comment by: php at richardneill dot org Reported by: gavin at itmerge dot com Summary: CLI setuid scripts don't run setuid Status: Bogus Type: Bug Package: CGI related Operating System: Linux 2.4.18 PHP Version: 4.3.1 New Comment: In 2003, the response was: There are no plans to implement any perl-like workaround in PHP at the present time. Might I request that, 7 years later, and with much increased use of php as a general-purpose scripting language, it might be worth re-visiting this? Previous Comments: [2003-03-26 09:38:21] il...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Uid of the binary, which is PHP is what matters, the script's uid does not matter since it is a parameter. [2003-03-26 09:36:02] ed...@php.net Modern kernels on Unix and Unix-like operating systems simply ignore set uid bit on shebang scripts (those that begin with #!). Some interpreters (like perl) choose to implement workaraounds, but if you really need to make a script suid, it is very easy to achieve so with a simple C wrapper program. There are no plans to implement any perl-like workaround in PHP at the present time. [2003-03-26 04:05:29] gavin at itmerge dot com whoops spelt posix_geteuid(); wrong :P [2003-03-26 03:27:23] gavin at itmerge dot com /* my sample script is */ #!/usr/local/bin/php ?php echo posix_getmyeuid().\n; ? /* root#chown root.vhost /scripts/myscript root#chmod 4710 /scripts/myscript root#useradd -u 1001 gavin root#usermod gavin -G vhost root#logout gavin$/scripts/myscript 1001 gavin$ i had to create /usr/local/bin/setuid_php and chmod 4710 it to be able to make my php scripts run setuid root (i'm not a perl person i don't know if perl supports setuid but I know scripts that i pass thru /bin/zsh support setuid) I don't really like having that script there :0 because A, I'm learning but i'm learing quickly that the more permissions you have the more you're likely to get a stuck up the rear end and essentially that lets anyone become god on my system who might find it, I think i'm going to go move it outside of /usr/local/bin right now */ -- Edit this bug report at http://bugs.php.net/bug.php?id=22890edit=1
Req #52071 [Wfx]: RFE: ping
Edit report at http://bugs.php.net/bug.php?id=52071edit=1
ID: 52071
User updated by: php at richardneill dot org
Reported by: php at richardneill dot org
Summary: RFE: ping
Status: Wont fix
Type: Feature/Change Request
Package: Network related
Operating System: Linux
PHP Version: Irrelevant
New Comment:
Agreed: php would have to internally exec('ping'). That's not especially
pretty, but it's no uglier than having to explicitly do it. The
advantage is that the code (and all error cases) have to be handled only
once within PHP, rather than by ten thousand different end-users :-)
Previous Comments:
[2010-06-13 03:15:15] ras...@php.net
But the reason the exec() works is because you are starting a new
setuid-root
process to do it. There is no way to do it from a non-root process,
which means
you can't eliminate the exec(), which means a PHP implementation would
internally
have to do exec('ping') which makes no sense.
[2010-06-13 03:13:07] php at richardneill dot org
I do see your point. On the other hand, I can (as a normal user) quite
easily use ping by relying on that Setuid binary, via exec(). Wouldn't
this approach work?
(the key win here is to eliminate needing exec(), which tends to upset
nervous managers during code-review)
[2010-06-13 02:38:27] ras...@php.net
This is not going to work in most PHP environments because doing
raw-socket ICMP
requests, like ping does requires root access. You will notice that
your ping
binary is setuid-root on your machine, so unless you are running PHP as
root,
doing it from within PHP simply won't work.
If you do have root access, it isn't that hard to do with a
socket_create(AF_INET, SOCK_RAW, getprotobyname('icmp')) call, but
since it
wouldn't work for most people, I don't see the point in adding it to
PHP.
[2010-06-13 02:28:38] php at richardneill dot org
Description:
Surprisingly, PHP is missing the ability to ping another host (and check
it's
alive). So I'd like to make a request to add it. I'd suggest using
something
like fping rather than standard ping, as this is more script-friendly -
for
example, fping can be made to return immediately as soon as it discovers
that
a given host is alive. For example:
fping -q -B1 www.php.net
I know that there is Net_Ping available via PEAR, but often PEAR
extensions
aren't available on many hosting environments; likewise it's awkward to
package a PHP web-application when the PEAR extension isn't already
packaged
for the distro. Is ping suficiently fundamental to be considered core?
Test script:
---
This command should either exist in 2 forms, or have several options.
Typical use cases are:
1. Is machine X alive (and responding to Pings)
2. Can I do a DNS lookup + route to that machine
3. What is the packet loss fraction.
This is easy enough to do by using exec(), but it would be nice to have
a native function. Thanks.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52071edit=1
Req #52073 [Bgs]: RFE: a few more options to exec()
Edit report at http://bugs.php.net/bug.php?id=52073edit=1 ID: 52073 User updated by: php at richardneill dot org Reported by: php at richardneill dot org Summary: RFE: a few more options to exec() Status: Bogus Type:Feature/Change Request Package: Program Execution PHP Version: Irrelevant New Comment: Yesbut proc_open() is often very much long-winded overkill. If I just want to get stdout and stderr as simple strings, what would be most useful would be this: exec (echo hello 2 ; echo world, $stdout, $stderr, $retval); // $stdout = hello\n // $stderr = world\n; // $retval = 0 the purpose here is to do everything in a minimum number of lines of code. I agree that for the entire set of suggestions, proc_open() is a better solution, but for the common case of getting stdout and stderr back separately, I'd like to see an extra parameter in exec(). Also, the documentation for exec() doesn't explain where stderr goes. Previous Comments: [2010-06-13 03:20:58] ras...@php.net This is what proc_open() is for. [2010-06-13 02:48:15] php at richardneill dot org Description: Exec() is missing a few key features: 1. The ability to return STDERR separately from STDOUT. At the moment, we can get STDOUT back in $output, but STDERR is either logged (for php-cgi) or sent to the main script STDERR (for php-cli). The user has the choice to append 21, but it would be really helpful to have stderr and stdout both returned in separate arrays. 2. The ability to choose the shell. At the moment, exec() uses apache's shell, which is usually /bin/sh (either as bash or ash depending on distro). If bash-isms are required, we can work around this with bash -c '.. ', but it would be a nice feature. 3. If a process is forked, then we'd like to get the PID, $!. Currently this can only be achieved thus: exec (foo echo $!, $output) but we must sacrifice stdout for the purpose. 4. Optionally, some way to do execv(arg1, arg2, arg3) Test script: --- I'd suggest having a function: exec( string $command [, array $stdout [,int $retval [,array $stderr [,int $pid [,int options = BASH|SH|CSH ] ] ] ] ] ) -- Edit this bug report at http://bugs.php.net/bug.php?id=52073edit=1
#48826 [NEW]: wish: mail() to support attachments
From: php at richardneill dot org Operating system: Linux PHP version: 6CVS-2009-07-07 (CVS) PHP Bug Type: Feature/Change Request Bug description: wish: mail() to support attachments Description: It would be a really nice if mail() supported an extra parameter for attachments. Perhaps an array containing the filenames (and whose keys, if present, would be the name of the attachments). (I know there are ways of doing this by installing pear classes, but that isn't always an option. And it's awkward to do it by hand). Given that mail() is already rather overloaded, it might be worth adding another function, say mail_attach() to do it. Reproduce code: --- Current alternative: $cmd = echo '$BODY_TEXT' | mutt -s '$SUBJECT' -a '$filename_1' -a '$filename_2' '$email'; exec ($cmd); which is ugly, has external dependencies, only works on Linux, and will break in interesting ways if shell-quoting isn't corrected. -- Edit bug report at http://bugs.php.net/?id=48826edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48826r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48826r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48826r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48826r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48826r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48826r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48826r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48826r=needscript Try newer version: http://bugs.php.net/fix.php?id=48826r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48826r=support Expected behavior: http://bugs.php.net/fix.php?id=48826r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48826r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48826r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48826r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48826r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48826r=dst IIS Stability: http://bugs.php.net/fix.php?id=48826r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48826r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48826r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48826r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48826r=mysqlcfg
#48828 [NEW]: strtotime() seems surprisingly slow (3x worse than preg_match).
From: php at richardneill dot org
Operating system: Linux
PHP version: 6CVS-2009-07-07 (CVS)
PHP Bug Type: Performance problem
Bug description: strtotime() seems surprisingly slow (3x worse than
preg_match).
Description:
I've just been troubleshooting a script whose job is to fix
logfiles. Each line of the logfile has a timestamp, but only
HH:MM:SS and it's missing the date. My script has to fix this.
For a 500,000 line file, this takes about 2 minutes, so I
investigated further. I found that strtotime() was really quite a
lot slower than I expected, and that using preg_match() instead
doubled the script execution speed.
Is this really to be expected, or could strtotime() be optimised?
Reproduce code:
---
#!/usr/bin/php
?
//This demonstrates that strtotime() is really rather slow. The
//example is quite contrived, but surely it should be possible to
//make strtotime() much faster than an entire regular-expression
//match, rather than 3 times slower?
$time1=microtime(1);
$timestamp1=05:03:02;
$timestamp2=03:05:07;
for ($i=0;$i1E6;$i++){
$seconds = strtotime($timestamp1) - strtotime($timestamp2);
#echo $seconds\n; //Do something with $seconds
}
$time2=microtime(1);
for ($i=0;$i1E6;$i++){
//preg_match lets us both check that this IS a valid
//timestamp and split it into parts.
preg_match('/^(\d\d):(\d\d):(\d\d)(\.\d+)?$/', $timestamp1, $matches1);
preg_match('/^(\d\d):(\d\d):(\d\d)(\.\d+)?$/', $timestamp2, $matches2);
$seconds = ( 3600 * intval($matches1[1]) + 60 *
intval($matches1[2]) + intval($matches1[3]) ) -
( 3600 * intval($matches2[1]) + 60 *
intval($matches2[2]) + intval($matches2[3]) );
#echo $seconds\n; //Do something with $seconds
}
$time3=microtime(1);
# 42.8 on 2.4GHz CPU
echo Each pair of calls to strtotime() took:.($time2 - $time1 ).
microseconds \n;
# 16.6.
echo Each pair of calls to preg_match() etc took:.($time3 - $time2 ).
microseconds \n;
?
Expected result:
I expect strtotime(), which is designed specifically for the
purpose, to be faster than preg_match, which is more
general-purpose.
Actual result:
--
strtotime() takes about 3 x longer than the brute-force approach
using a regular-expression + array maths. Is that really expected?
date() isn't very fast either.
42us means 100,000 CPU cycles!
--
Edit bug report at http://bugs.php.net/?id=48828edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48828r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48828r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48828r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48828r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48828r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48828r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48828r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48828r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48828r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48828r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48828r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48828r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48828r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48828r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48828r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48828r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48828r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48828r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48828r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48828r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48828r=mysqlcfg
#48683 [Com]: stream_select returns 1 even when no streams have changed
ID: 48683
Comment by: php at richardneill dot org
Reported By: php at richardneill dot org
Status: Open
Bug Type: Streams related
Operating System: Linux
PHP Version: 5.2CVS-2009-06-25 (snap)
New Comment:
Thank you for your explanation. I agree - I had misunderstood the
docs, and PHP is behaving correctly.
Previous Comments:
[2009-06-25 08:37:28] sjoerd-php at linuxonly dot nl
Thank you for your bug report.
In your code example, you use /dev/null as blocking file. However, this
is not entirely correct. As you say, /dev/null gives EOF immediately,
which means stream_select sees it as ready:
The streams listed in the read array will be watched to see if
characters become available for reading (more precisely, to see if a
read will not block - in particular, a stream resource is also ready on
end-of-file, in which case an fread() will return a zero length
string).
In your loop, fread() constantly read a empty string and the file
resource is constantly ready.
Maybe this information already solves your problem. If it does not,
please provide a better code example.
[2009-06-25 04:15:01] php at richardneill dot org
Description:
It seems that stream_select is failing to return 0 even if all of the
streams would block.
I've tested the code below on multiple versions of PHP from 5.2.4
upward, and get the same result on them all.
(It's possible I've misunderstood the requirements for sockets, but
I've quintuple-checked this code.)
Reproduce code:
---
#!/usr/bin/php
?
echo This should never print 'did fread'.\n;
echo It should just print 'stream_select returned 0' every second\n;
echo \n;
$fp=fopen(/dev/null,r); #open /dev/null for reading.
#Should immediately result in EOF.
while (true) {
$r = array($fp);
$n = stream_select($r, $w = null, $e = null, 1);
#stream select on read array, timeout 1 sec
echo stream_select returned $n\n;
if ($n) {
#Try to read up to 1024 bytes
echo fread($fp,1024);
echo did fread.\n;
}
usleep (10);//slow down (0.1s)
}
?
Expected result:
I expect to see the line
stream_select returned 0
repeated every 1 second.
Actual result:
--
I get repeated instances of:
stream_select returned 1
did fread.
fread is returning nothing, but still the stream_select insists that
there is data available to be read!
--
Edit this bug report at http://bugs.php.net/?id=48683edit=1
#48683 [NEW]: stream_select returns 1 even when no streams have changed
From: php at richardneill dot org
Operating system: Linux
PHP version: 5.2CVS-2009-06-25 (snap)
PHP Bug Type: Streams related
Bug description: stream_select returns 1 even when no streams have changed
Description:
It seems that stream_select is failing to return 0 even if all of the
streams would block.
I've tested the code below on multiple versions of PHP from 5.2.4 upward,
and get the same result on them all.
(It's possible I've misunderstood the requirements for sockets, but I've
quintuple-checked this code.)
Reproduce code:
---
#!/usr/bin/php
?
echo This should never print 'did fread'.\n;
echo It should just print 'stream_select returned 0' every second\n;
echo \n;
$fp=fopen(/dev/null,r); #open /dev/null for reading.
#Should immediately result in EOF.
while (true) {
$r = array($fp);
$n = stream_select($r, $w = null, $e = null, 1);
#stream select on read array, timeout 1 sec
echo stream_select returned $n\n;
if ($n) {
#Try to read up to 1024 bytes
echo fread($fp,1024);
echo did fread.\n;
}
usleep (10);//slow down (0.1s)
}
?
Expected result:
I expect to see the line
stream_select returned 0
repeated every 1 second.
Actual result:
--
I get repeated instances of:
stream_select returned 1
did fread.
fread is returning nothing, but still the stream_select insists that there
is data available to be read!
--
Edit bug report at http://bugs.php.net/?id=48683edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48683r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48683r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48683r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48683r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48683r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48683r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48683r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48683r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48683r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48683r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48683r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48683r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48683r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48683r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48683r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48683r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48683r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48683r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48683r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48683r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48683r=mysqlcfg
#48072 [NEW]: wish: extra strtr features similar to GNU strtr
From: php at richardneill dot org
Operating system: all
PHP version: 6CVS-2009-04-24 (CVS)
PHP Bug Type: Feature/Change Request
Bug description: wish: extra strtr features similar to GNU strtr
Description:
Can we have the extra features added to strtr() that are in the GNU strtr?
They'd be really useful.
In particular, the ability to delete certain characters from the string
[currently we must resort to str_replace, which gets ugly], and to squeeze
repeated characters to a single one [requires preg_replace() at the moment]
This could be done by adding some predefined constants such as
STRTR_DELETE, STRTR_SQUEEZE_REPEATS
Reproduce code:
---
In GNU tr, we can do things like
echo hello world | tr -s l
#results in helo world (duplicate 'l' removed)
echo hello world | tr -d 'od' ('o' and 'd' removed)
#results in hell wrl
echo hello world | tr -s wl zl (translate AND squeeze)
#results in helo zorld
(Support for character classes might be nice too)
Thank you.
--
Edit bug report at http://bugs.php.net/?id=48072edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48072r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48072r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48072r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48072r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48072r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48072r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48072r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48072r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48072r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48072r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48072r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48072r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48072r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48072r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48072r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48072r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48072r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48072r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48072r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48072r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48072r=mysqlcfg
#47883 [NEW]: wish: syntax error, unexpected $end should show start point
From: php at richardneill dot org
Operating system: Linux
PHP version: 5.2.9
PHP Bug Type: Feature/Change Request
Bug description: wish: syntax error, unexpected $end should show start point
Description:
If I have a script with a syntax error, such as a missing '}' somewhere,
PHP will helpfully tell me that there's a problem, but direct me to look in
the wrong place.
The error message is as follows:
Parse error: syntax error, unexpected $end in [FILENAME] at
[NUMBER_OF_LAST_LINE]
This is unhelpful for 2 reasons.
* It isn't clear what type of syntax error would cause this - there's no
way to know what character PHP was expecting to see.
* I have no easy way of finding the offending line where the bug really
lies, apart from commenting out parts of the source and doing a
binary-search within it. Essentially, PHP is saying You have an error, but
I won't tell you where.
Expected result:
The following would be clearer and *far* more helpful.
Syntax error: unexpected $end in [FILENAME] at LINENUM: missing
an expected '}' character. (The corresponding, unmatched '{' is
probably at line xxx.)
Of course, it's not always possible for PHP to know which open-brace is
the unmatched one - however, it could usually take a reasonable best guess
by iterating *backwards* through the source, and doing:
1 $nest_depth=0
2 If a '}' is encountered, $nest_depth++
3 If a '{' is encountered, $nest_depth--
4 If $nest_depth == -1, we have located the open-brace that isn't
closed. Print LINENUM.
--
Edit bug report at http://bugs.php.net/?id=47883edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47883r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47883r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47883r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47883r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47883r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47883r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47883r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47883r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47883r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47883r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47883r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47883r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47883r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47883r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47883r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47883r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47883r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47883r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47883r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47883r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47883r=mysqlcfg
#46239 [NEW]: wish: compound logical operators (nand, xor, etc)
From: php at richardneill dot org
Operating system:
PHP version: 6CVS-2008-10-06 (CVS)
PHP Bug Type: Feature/Change Request
Bug description: wish: compound logical operators (nand, xor, etc)
Description:
This is a request for a new set of functions, namely the more complex
logical operations, NAND, NOR, XOR, XNOR etc. I suggest implementing them
as functions, rather than as operators, because they can take a variable
number of arguments. These would also be distinct from the bitwise
operators.
Of course these are pretty trivial to implement oneself as and when
needed, but it would make a small increment of improvement to PHP ;-)
The other advantage is in code-readability. I think that example1 is more
readable than example2:
$example1 = nand ($condition_1, $condition_2, $condition_3, $condition_4)
$example2 = (! ($condition_1 and $condition_2 and $condition3 and
$condition_4)
Thanks for your time and consideration - Richard
Reproduce code:
---
A possible implementation:
function nand($a,$b,$c,){
#cast everything to boolean
return !($a and $b and $c ...);
}
function nor($a,$b,$c,...){
#cast to boolean
return !($a or $b or $c or ...);
}
function new_and($a,$b,$c,...){
#note: this makes the syntax much clearer and shorter if
#there are very many inputs.
return ($a and $b and $c...);
}
#similarly, new_or()
function xor($a,$b,$c,...){
$count=0;
if ($a){ $count++ ;}
if ($b){ $count++ ;}
if ($c){ $count++ ;}
...
return ($count == 1);
}
function xnor($a,$b,$c,...){
$count=0;
if ($a){ $count++ ;}
if ($b){ $count++ ;}
if ($c){ $count++ ;}
...
return ($count != 1);
}
function majority($a,$b,$c,...){
$count=0;
if ($a){ $count++ ;}
if ($b){ $count++ ;}
if ($c){ $count++ ;}
..
return ($count $number_of_args/2);
}
#and any others I've missed out.
--
Edit bug report at http://bugs.php.net/?id=46239edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46239r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46239r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46239r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=46239r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=46239r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=46239r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=46239r=needscript
Try newer version:http://bugs.php.net/fix.php?id=46239r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=46239r=support
Expected behavior:http://bugs.php.net/fix.php?id=46239r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46239r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46239r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=46239r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46239r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=46239r=dst
IIS Stability:http://bugs.php.net/fix.php?id=46239r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=46239r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=46239r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=46239r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=46239r=mysqlcfg
#45864 [NEW]: wish: fwrite to support direct output of bytes (not cast to string)
From: php at richardneill dot org Operating system: PHP version: 5.2.6 PHP Bug Type: Feature/Change Request Bug description: wish: fwrite to support direct output of bytes (not cast to string) Description: fwrite() outputs to file as a string. While this is usually a sensible default, it can be rather annoying when I actually want to output raw data. I know about using chr(), but that's ugly at least. My request: add an option to fwrite that lets you output a char, rather than a string. [The chr() workaround is also not very visibly documented]. -- Edit bug report at http://bugs.php.net/?id=45864edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45864r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45864r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45864r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45864r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45864r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45864r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45864r=needscript Try newer version:http://bugs.php.net/fix.php?id=45864r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45864r=support Expected behavior:http://bugs.php.net/fix.php?id=45864r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45864r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45864r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45864r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45864r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45864r=dst IIS Stability:http://bugs.php.net/fix.php?id=45864r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45864r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45864r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45864r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45864r=mysqlcfg
#38610 [NEW]: wish: gmp_printf
From: php at richardneill dot org Operating system: PHP version: 5.1.5 PHP Bug Type: Feature/Change Request Bug description: wish: gmp_printf Description: According to the gmp homepage, there is a gmp_printf function. However, PHP doesn't have one. While it isn't that hard to implement by hand, it would be nice to have... (gmp_log would be nice, too!) Thanks, Richard -- Edit bug report at http://bugs.php.net/?id=38610edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38610r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38610r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38610r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38610r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38610r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38610r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38610r=needscript Try newer version:http://bugs.php.net/fix.php?id=38610r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38610r=support Expected behavior:http://bugs.php.net/fix.php?id=38610r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38610r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38610r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38610r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38610r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38610r=dst IIS Stability:http://bugs.php.net/fix.php?id=38610r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38610r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38610r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38610r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38610r=mysqlcfg
#28141 [Bgs]: socket_read return type: false vs , when PHP_NORMAL_READ
ID: 28141
User updated by: php at richardneill dot org
Reported By: php at richardneill dot org
Status: Bogus
Bug Type: Sockets related
Operating System: Linux
PHP Version: 4CVS, 5CVS (2005-02-14)
Assigned To: andrey
New Comment:
Thanks. That makes sense. However, it still leaves a few problems,
essentially with wrong documentation.
---
1)The documentation for socket_read
http://uk.php.net/manual/en/function.socket-read.php
claims:
Note: socket_read() may return a zero length string () indicating
the end of communication (i.e. the remote end point has closed the
connection).
which is obviously not true.
-
2)Example 1 on the sockets page
http://uk.php.net/manual/en/ref.sockets.php
also supports the interpretation that
False = error; null = connection closed
if (false === ($buf = socket_read($msgsock, 2048,
PHP_NORMAL_READ))) {
echo socket_read() failed: reason: .
socket_strerror($ret) . \n;
break 2;
}
if (!$buf = trim($buf)) {
continue;
}
--
3)How is one to determine the difference between
i)the other side closing the connection normally
and
ii)something going very wrong with the function?
According to the documentation,
= (i)
false = (ii)
In fact, it seems that
false = (i) or (ii), with no way to tell
= never actually happens
Thanks for your help,
Richard
Previous Comments:
[2005-02-14 09:10:12] [EMAIL PROTECTED]
There is no bug to fix here. You're actually getting Connection reset
by peer (ECONNRESET) and that makes recv() to return -1 - PHP
socket_read() returns an error and FALSE.
Here's simplified WORKING script:
#!/usr/local/bin/php
?php
error_reporting(E_ALL);
/* Allow the script to hang around waiting for connections. */
set_time_limit(0);
/* Turn on implicit output flushing so we see what we're getting as it
comes in. */
ob_implicit_flush();
$address = '127.0.0.1';
$port = ;
$sock = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
socket_bind($sock, $address, $port);
socket_listen($sock, 5);
do {
$msgsock = socket_accept($sock);
do {
$buf = socket_read($msgsock, 2048, PHP_NORMAL_READ);
var_dump($buf);
} while ($buf !== FALSE $buf !== '');
echo socket_strerror(socket_last_error($msgsock));
socket_close($msgsock);
echo Closed msgsocket; waiting for another connection\n;
} while (true);
socket_close($sock);
echo Closed main socket, exiting\n;
?
[2004-07-28 21:04:13] [EMAIL PROTECTED]
Assigning to myself (to get notification if i forget), changing the
version.
[2004-07-26 10:37:34] php at hristov dot com
I will take a look later today or these days. But for now, the code in
the function is :
if (type == PHP_NORMAL_READ) {
retval = php_read(php_sock-bsd_socket, tmpbuf, length, 0);
} else {
retval = recv(php_sock-bsd_socket, tmpbuf, length, 0);
}
if (retval == -1) {
PHP_SOCKET_ERROR(php_sock, unable to read from socket, errno);
efree(tmpbuf);
RETURN_FALSE;
}
[2004-07-18 17:13:56] php2 at richardneill dot org
I've still got the same thing happening in PHP5.0.0(final)
I'm having some trouble with your example, so I'm using the attached
instead. It's basically copied from the php-sockets manual, but
slightly modified.
The key point: according to the documentation, when
(socket_read()===false), it means something has gone very wrong, i.e.
a fatal error. However, in practice, all this means is that the other
side has closed the connection.
I'm running this code as ./testsock.php
and the client is simply: netcat localhost
The problem is that, if netcat is killed with Ctrl-C, then the server
suffers a fatal error. I don't think that it should.
I've tried it under both version php-cli-4.3.7-4mdk (the current devel
version from Mandrake cooker) and php-5.0.0-cli which I just compiled.
In both cases, the same thing happens.
Regards
Richard
-
#!/usr/local/bin/php
?php
error_reporting(E_ALL);
/* Allow the script to hang around waiting for connections. */
set_time_limit(0);
/* Turn on implicit output flushing so we see what we're getting as it
comes in. */
ob_implicit_flush();
$address = '127.0.0.1';
$port = ;
if (($sock = socket_create(AF_INET, SOCK_STREAM, SOL_TCP)) 0) {
echo socket_create() failed: reason: . socket_strerror($sock) .
\n;
}else{
echo Created socket $sock\n;
}
if (($ret = socket_bind($sock, $address, $port)) 0) {
echo socket_bind() failed: reason: . socket_strerror($ret) .
\n;
}else{
echo Bound socket $sock to port $port on address $address\n
#31453 [Com]: array_rand() is not returning random values
ID: 31453
Comment by: php at richardneill dot org
Reported By: cdturri at hotmail dot com
Status: Open
Bug Type: Arrays related
Operating System: Windows 2000 Advanced Server SP4
PHP Version: 5.0.3
New Comment:
This is a rather nasty security bug, with which someone successfully
attacked my website. The default passwords were generated by
concatenating 2 random words from the dictionary, yet the function
(which has worked fine for 3 years) suddenly started to produce exactly
the same result every time!
The bug occurs in this version of PHP (Mandrake's most recent stable
package): PHP 4.3.4 (cli) (built: Dec 16 2004 18:39:58); but not in the
cooker package (PHP 4.3.10 (cli) (built: Dec 16 2004 15:44:17). The bug
occues in both php-cli and running under apache2-2.0.48-6.8.100mdk.
Here's my code, which illustrates this bug under Mandrake 10.1:
?
$letters=array(alpha,beta, gamma, delta, epsilon, zeta,
eta, theta, iota, kappa, lambda, mu, nu, xi);
$rand_keys = array_rand ($letters, 2);
$word1= $letters[$rand_keys[0]];
$word2= $letters[$rand_keys[1]];
echo The following line SHOULD be different every time! In
php-cli-4.3.4-4.3.100mdk, this is NOT true! 'zetanu' occurs every
time.\n;
echo $word1$word2\n;
?
Adding in an srand() will fix it, but mt_srand() will not. However,
neither of these were necessary for the last 3 years, and so I imagine
this bug will cause security problems for other people.
Previous Comments:
[2005-01-09 15:04:01] cdturri at hotmail dot com
Description:
Hi guys,
array_rand() is not returning random values in my scripts. I am using a
multidimension array that is being loaded from an INI file with
@parse_ini_file(). Tested under Apache v2.0.52/PHP v5.0.3 on Windows
2000 Advanced Server and a CVS build (php5-win32-200501071130.zip)
under Windows as well. Bug appears on both. I don't have a Unix system
to test it under PHP 5 (shame on me!) but the problem does NOT occur
under Unix/Apache v 1.3.33/PHP v4.3.9.
Calling srand() to seed the random number generator seems to fix the
problem but the PHP manual clearly says that:
Note: As of PHP 4.2.0, there is no need to seed the random number
generator with srand() or mt_srand() as this is now done
automatically.
(http://ie2.php.net/manual/en/function.array-rand.php)
mt_rand(), rand() and mt_srand() also contain notes saying that seeding
is not required before calling them.
Found several related bugs, but this one mentions the same issue:
http://bugs.php.net/bug.php?id=26290
[17 Nov 2003 2:12pm CET] [EMAIL PROTECTED]
You forgot to call srand() to generate random key. Hence the lack of
random data.
[17 Nov 2003 2:25pm CET] [EMAIL PROTECTED]
Incorrect documentaion I'm afraid.
So, it is one or the other. Either the documentation is wrong or the
function is not properly calling seeding the random number generator.
Could anyone please have a look?
Thanks for looking at this bug.
Regards,
Christian
Reproduce code:
---
I am using this code to verify the bug:
?php
$multiarray = @parse_ini_file('cache.ini',true);
for($i=0;$i100;$i++){
$rand_key = array_rand($multiarray);
print $rand_key . 'br';
if ($i == 1) {
$first_item = $rand_key;
}
if ($first_item == $rand_key) {
echo 'br';
}
}
?
You can see the bug at:
http://www.turribeach.com.ar/downloads/test.php
You can download the INI file I am using and the test.php from:
http://www.turribeach.com.ar/downloads/PHP_Test.zip
Expected result:
A random key from the INI file.
Actual result:
--
A key but that it is not random, it is a subset of the original key
array.
--
Edit this bug report at http://bugs.php.net/?id=31453edit=1
#31453 [Com]: array_rand() is not returning random values
ID: 31453
Comment by: php at richardneill dot org
Reported By: cdturri at hotmail dot com
Status: Open
Bug Type: Arrays related
Operating System: Windows 2000 Advanced Server SP4
PHP Version: 5.0.3
New Comment:
Arratum: the bug occurs on Mandrake 10.0, not 10.1. Nevertheless, this
is 10.0 with all updates applied, so I think a security warning about
that release of php would be a good idea.
Previous Comments:
[2005-01-09 16:00:02] php at richardneill dot org
This is a rather nasty security bug, with which someone successfully
attacked my website. The default passwords were generated by
concatenating 2 random words from the dictionary, yet the function
(which has worked fine for 3 years) suddenly started to produce exactly
the same result every time!
The bug occurs in this version of PHP (Mandrake's most recent stable
package): PHP 4.3.4 (cli) (built: Dec 16 2004 18:39:58); but not in the
cooker package (PHP 4.3.10 (cli) (built: Dec 16 2004 15:44:17). The bug
occues in both php-cli and running under apache2-2.0.48-6.8.100mdk.
Here's my code, which illustrates this bug under Mandrake 10.1:
?
$letters=array(alpha,beta, gamma, delta, epsilon, zeta,
eta, theta, iota, kappa, lambda, mu, nu, xi);
$rand_keys = array_rand ($letters, 2);
$word1= $letters[$rand_keys[0]];
$word2= $letters[$rand_keys[1]];
echo The following line SHOULD be different every time! In
php-cli-4.3.4-4.3.100mdk, this is NOT true! 'zetanu' occurs every
time.\n;
echo $word1$word2\n;
?
Adding in an srand() will fix it, but mt_srand() will not. However,
neither of these were necessary for the last 3 years, and so I imagine
this bug will cause security problems for other people.
[2005-01-09 15:04:01] cdturri at hotmail dot com
Description:
Hi guys,
array_rand() is not returning random values in my scripts. I am using a
multidimension array that is being loaded from an INI file with
@parse_ini_file(). Tested under Apache v2.0.52/PHP v5.0.3 on Windows
2000 Advanced Server and a CVS build (php5-win32-200501071130.zip)
under Windows as well. Bug appears on both. I don't have a Unix system
to test it under PHP 5 (shame on me!) but the problem does NOT occur
under Unix/Apache v 1.3.33/PHP v4.3.9.
Calling srand() to seed the random number generator seems to fix the
problem but the PHP manual clearly says that:
Note: As of PHP 4.2.0, there is no need to seed the random number
generator with srand() or mt_srand() as this is now done
automatically.
(http://ie2.php.net/manual/en/function.array-rand.php)
mt_rand(), rand() and mt_srand() also contain notes saying that seeding
is not required before calling them.
Found several related bugs, but this one mentions the same issue:
http://bugs.php.net/bug.php?id=26290
[17 Nov 2003 2:12pm CET] [EMAIL PROTECTED]
You forgot to call srand() to generate random key. Hence the lack of
random data.
[17 Nov 2003 2:25pm CET] [EMAIL PROTECTED]
Incorrect documentaion I'm afraid.
So, it is one or the other. Either the documentation is wrong or the
function is not properly calling seeding the random number generator.
Could anyone please have a look?
Thanks for looking at this bug.
Regards,
Christian
Reproduce code:
---
I am using this code to verify the bug:
?php
$multiarray = @parse_ini_file('cache.ini',true);
for($i=0;$i100;$i++){
$rand_key = array_rand($multiarray);
print $rand_key . 'br';
if ($i == 1) {
$first_item = $rand_key;
}
if ($first_item == $rand_key) {
echo 'br';
}
}
?
You can see the bug at:
http://www.turribeach.com.ar/downloads/test.php
You can download the INI file I am using and the test.php from:
http://www.turribeach.com.ar/downloads/PHP_Test.zip
Expected result:
A random key from the INI file.
Actual result:
--
A key but that it is not random, it is a subset of the original key
array.
--
Edit this bug report at http://bugs.php.net/?id=31453edit=1
#31453 [Com]: array_rand() is not returning random values
ID: 31453
Comment by: php at richardneill dot org
Reported By: cdturri at hotmail dot com
Status: Open
Bug Type: Arrays related
Operating System: Windows 2000 Advanced Server SP4
PHP Version: 5.0.3
New Comment:
The affected version of mod php is this:
apache2-mod_php-2.0.48_4.3.4-1mdk
Previous Comments:
[2005-01-09 16:07:32] php at richardneill dot org
Arratum: the bug occurs on Mandrake 10.0, not 10.1. Nevertheless, this
is 10.0 with all updates applied, so I think a security warning about
that release of php would be a good idea.
[2005-01-09 16:00:02] php at richardneill dot org
This is a rather nasty security bug, with which someone successfully
attacked my website. The default passwords were generated by
concatenating 2 random words from the dictionary, yet the function
(which has worked fine for 3 years) suddenly started to produce exactly
the same result every time!
The bug occurs in this version of PHP (Mandrake's most recent stable
package): PHP 4.3.4 (cli) (built: Dec 16 2004 18:39:58); but not in the
cooker package (PHP 4.3.10 (cli) (built: Dec 16 2004 15:44:17). The bug
occues in both php-cli and running under apache2-2.0.48-6.8.100mdk.
Here's my code, which illustrates this bug under Mandrake 10.1:
?
$letters=array(alpha,beta, gamma, delta, epsilon, zeta,
eta, theta, iota, kappa, lambda, mu, nu, xi);
$rand_keys = array_rand ($letters, 2);
$word1= $letters[$rand_keys[0]];
$word2= $letters[$rand_keys[1]];
echo The following line SHOULD be different every time! In
php-cli-4.3.4-4.3.100mdk, this is NOT true! 'zetanu' occurs every
time.\n;
echo $word1$word2\n;
?
Adding in an srand() will fix it, but mt_srand() will not. However,
neither of these were necessary for the last 3 years, and so I imagine
this bug will cause security problems for other people.
[2005-01-09 15:04:01] cdturri at hotmail dot com
Description:
Hi guys,
array_rand() is not returning random values in my scripts. I am using a
multidimension array that is being loaded from an INI file with
@parse_ini_file(). Tested under Apache v2.0.52/PHP v5.0.3 on Windows
2000 Advanced Server and a CVS build (php5-win32-200501071130.zip)
under Windows as well. Bug appears on both. I don't have a Unix system
to test it under PHP 5 (shame on me!) but the problem does NOT occur
under Unix/Apache v 1.3.33/PHP v4.3.9.
Calling srand() to seed the random number generator seems to fix the
problem but the PHP manual clearly says that:
Note: As of PHP 4.2.0, there is no need to seed the random number
generator with srand() or mt_srand() as this is now done
automatically.
(http://ie2.php.net/manual/en/function.array-rand.php)
mt_rand(), rand() and mt_srand() also contain notes saying that seeding
is not required before calling them.
Found several related bugs, but this one mentions the same issue:
http://bugs.php.net/bug.php?id=26290
[17 Nov 2003 2:12pm CET] [EMAIL PROTECTED]
You forgot to call srand() to generate random key. Hence the lack of
random data.
[17 Nov 2003 2:25pm CET] [EMAIL PROTECTED]
Incorrect documentaion I'm afraid.
So, it is one or the other. Either the documentation is wrong or the
function is not properly calling seeding the random number generator.
Could anyone please have a look?
Thanks for looking at this bug.
Regards,
Christian
Reproduce code:
---
I am using this code to verify the bug:
?php
$multiarray = @parse_ini_file('cache.ini',true);
for($i=0;$i100;$i++){
$rand_key = array_rand($multiarray);
print $rand_key . 'br';
if ($i == 1) {
$first_item = $rand_key;
}
if ($first_item == $rand_key) {
echo 'br';
}
}
?
You can see the bug at:
http://www.turribeach.com.ar/downloads/test.php
You can download the INI file I am using and the test.php from:
http://www.turribeach.com.ar/downloads/PHP_Test.zip
Expected result:
A random key from the INI file.
Actual result:
--
A key but that it is not random, it is a subset of the original key
array.
--
Edit this bug report at http://bugs.php.net/?id=31453edit=1
#30698 [Fbk-Opn]: preg_replace with /e does not escape single quotes as per documentation
ID: 30698
User updated by: php at richardneill dot org
Reported By: php at richardneill dot org
-Status: Feedback
+Status: Open
Bug Type: PCRE related
Operating System: Linux
PHP Version: 4.3.9
New Comment:
I hope this test case is more useful.
?
$message=This string contains a single quote ', a double quote \, and
a backslash\ .;
function modify($string){
return START $string END;
}
$new_bad=preg_replace(/^(.*)$/e, 'BEGINNING '.modify('\\1').'
FINISH', $message);
$new_good=preg_replace(/^(.*)$/e, 'BEGINNING '.modify(\\\1\).'
FINISH', $message);
echo MESSAGE:\n$message\n\n;
echo NEW_BAD:\n$new_bad\n\n;
echo NEW_GOOD:\n$new_good\n\n;
echo NB: none of these are the same!\n
/*
The problem is that depending on precisely how the replacements in the
preg_replace are quoted,
the escaping is different. This is not documented. $new_bad and
$new_good should be the same!
Furthermore, in the case where $message is user-submitted, and has
arrived via magic_quotes, ready for
insertion into a database, modify() will want to include a
strip_slashes, to remove the redundant slashes (but leaving the
original ones). The above behaviour could leave a database vulnerable
to sql injection attacks
My personal favoured solution would be for the /e modifier not to add
the extra backslashes.
*/
?
Previous Comments:
[2004-11-10 18:24:12] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.
Btw, the example from docs works just fine for me.
[2004-11-06 08:19:13] php at richardneill dot org
Sorry - that should have been filed as PCRE related
Richard
[2004-11-06 08:17:25] php at richardneill dot org
Description:
The documentation for preg_replace states that /e
will cause it to add extra slashes to single and double
quotes.
This means that, if one has magic_quotes on, one must
filter out the spurious new backslashes, using something
like:
$block=str_replace(array('\'',''),array('\\\'','\\'),
$block);
However, in fact, it appears that preg_replace is adding
the backslashes to double quotes, but NOT to single
quotes.
There's also a useful comment here:
http://uk2.php.net/manual/en/function.preg-replace.php
steven -a-t- acko dot net 08-Feb-2004 05:45
Reproduce code:
---
FAILS:
$message=preg_replace(/((?=(\n))|(?=^))( *(.*))(\n\n|$)/seU,
'$quote_font_start BEGIN'.fixblock('\\3',$quote).' END
$quote_font_end\n\n', $message);
WORKS:
$message=preg_replace(/((?=(\n))|(?=^))(
*(.*))(\n\n|$)/seU,
'$quote_font_start BEGIN'.fixblock(\\\3\,$quote).' END
$quote_font_end\n\n', $message);
Expected result:
I'm not sure whether this is simply a documentation bug,
but it's very weird behaviour! It is also a nasty one,
because it can leave the database vulnerable. Thanks for
your help.
--
Edit this bug report at http://bugs.php.net/?id=30698edit=1
#30698 [NEW]: preg_replace with /e does not escape single quotes as per documentation
From: php at richardneill dot org
Operating system: Linux
PHP version: 4.3.9
PHP Bug Type: Feature/Change Request
Bug description: preg_replace with /e does not escape single quotes as per
documentation
Description:
The documentation for preg_replace states that /e
will cause it to add extra slashes to single and double
quotes.
This means that, if one has magic_quotes on, one must
filter out the spurious new backslashes, using something
like:
$block=str_replace(array('\'',''),array('\\\'','\\'),
$block);
However, in fact, it appears that preg_replace is adding
the backslashes to double quotes, but NOT to single
quotes.
There's also a useful comment here:
http://uk2.php.net/manual/en/function.preg-replace.php
steven -a-t- acko dot net 08-Feb-2004 05:45
Reproduce code:
---
FAILS:
$message=preg_replace(/((?=(\n))|(?=^))( *(.*))(\n\n|$)/seU,
'$quote_font_start BEGIN'.fixblock('\\3',$quote).' END
$quote_font_end\n\n', $message);
WORKS:
$message=preg_replace(/((?=(\n))|(?=^))(
*(.*))(\n\n|$)/seU,
'$quote_font_start BEGIN'.fixblock(\\\3\,$quote).' END
$quote_font_end\n\n', $message);
Expected result:
I'm not sure whether this is simply a documentation bug,
but it's very weird behaviour! It is also a nasty one,
because it can leave the database vulnerable. Thanks for
your help.
--
Edit bug report at http://bugs.php.net/?id=30698edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30698r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30698r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30698r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30698r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30698r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30698r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30698r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30698r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30698r=support
Expected behavior: http://bugs.php.net/fix.php?id=30698r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30698r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30698r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30698r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30698r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30698r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30698r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30698r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30698r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30698r=mysqlcfg
#30698 [Opn]: preg_replace with /e does not escape single quotes as per documentation
ID: 30698
User updated by: php at richardneill dot org
Reported By: php at richardneill dot org
Status: Open
-Bug Type: Feature/Change Request
+Bug Type: PCRE related
Operating System: Linux
PHP Version: 4.3.9
New Comment:
Sorry - that should have been filed as PCRE related
Richard
Previous Comments:
[2004-11-06 08:17:25] php at richardneill dot org
Description:
The documentation for preg_replace states that /e
will cause it to add extra slashes to single and double
quotes.
This means that, if one has magic_quotes on, one must
filter out the spurious new backslashes, using something
like:
$block=str_replace(array('\'',''),array('\\\'','\\'),
$block);
However, in fact, it appears that preg_replace is adding
the backslashes to double quotes, but NOT to single
quotes.
There's also a useful comment here:
http://uk2.php.net/manual/en/function.preg-replace.php
steven -a-t- acko dot net 08-Feb-2004 05:45
Reproduce code:
---
FAILS:
$message=preg_replace(/((?=(\n))|(?=^))( *(.*))(\n\n|$)/seU,
'$quote_font_start BEGIN'.fixblock('\\3',$quote).' END
$quote_font_end\n\n', $message);
WORKS:
$message=preg_replace(/((?=(\n))|(?=^))(
*(.*))(\n\n|$)/seU,
'$quote_font_start BEGIN'.fixblock(\\\3\,$quote).' END
$quote_font_end\n\n', $message);
Expected result:
I'm not sure whether this is simply a documentation bug,
but it's very weird behaviour! It is also a nasty one,
because it can leave the database vulnerable. Thanks for
your help.
--
Edit this bug report at http://bugs.php.net/?id=30698edit=1
#28141 [NoF-Opn]: socket_read return type: false vs
ID: 28141
User updated by: php at richardneill dot org
Reported By: php at richardneill dot org
-Status: No Feedback
+Status: Open
Bug Type: Sockets related
Operating System: Linux
PHP Version: 5.0.0RC1
New Comment:
re-setting to open as requested by automatic email.
Sorry - I think I confused your system by commenting as another user
rather than as the original submitter.
Previous Comments:
[2004-07-26 01:00:05] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2004-07-18 17:13:56] php2 at richardneill dot org
I've still got the same thing happening in PHP5.0.0(final)
I'm having some trouble with your example, so I'm using the attached
instead. It's basically copied from the php-sockets manual, but
slightly modified.
The key point: according to the documentation, when
(socket_read()===false), it means something has gone very wrong, i.e.
a fatal error. However, in practice, all this means is that the other
side has closed the connection.
I'm running this code as ./testsock.php
and the client is simply: netcat localhost
The problem is that, if netcat is killed with Ctrl-C, then the server
suffers a fatal error. I don't think that it should.
I've tried it under both version php-cli-4.3.7-4mdk (the current devel
version from Mandrake cooker) and php-5.0.0-cli which I just compiled.
In both cases, the same thing happens.
Regards
Richard
-
#!/usr/local/bin/php
?php
error_reporting(E_ALL);
/* Allow the script to hang around waiting for connections. */
set_time_limit(0);
/* Turn on implicit output flushing so we see what we're getting as it
comes in. */
ob_implicit_flush();
$address = '127.0.0.1';
$port = ;
if (($sock = socket_create(AF_INET, SOCK_STREAM, SOL_TCP)) 0) {
echo socket_create() failed: reason: . socket_strerror($sock) .
\n;
}else{
echo Created socket $sock\n;
}
if (($ret = socket_bind($sock, $address, $port)) 0) {
echo socket_bind() failed: reason: . socket_strerror($ret) .
\n;
}else{
echo Bound socket $sock to port $port on address $address\n;
}
if (($ret = socket_listen($sock, 5)) 0) {
echo socket_listen() failed: reason: . socket_strerror($ret) .
\n;
}else{
echo listening...\n;
}
do {
if (($msgsock = socket_accept($sock)) 0) {
echo socket_accept() failed: reason: .
socket_strerror($msgsock) . \n;
break;
}
/* Send instructions. */
$msg = Welcome to the PHP Test Server.\nTo quit, type 'quit'. To
shut down the server type 'shutdown'.\n.
To crash this server, quit netcat with Ctrl-C\n;
socket_write($msgsock, $msg, strlen($msg));
do {
$buf = socket_read($msgsock, 2048, PHP_NORMAL_READ);
if ($buf==''){
echo Socket received an empty string.\n;
}
if ($buf ===false){
echo socket_read() failed: reason: .
socket_strerror($ret) . . This shouldn't happen. Fatal exit.\n;
break 2;
}
/* According to the documentation, testing for socket_read being
false is a sign of a fatal error, whereas an empty string
is means the remote side has closed the connection. Actually both
and false indicate the remote side has closed the connection.
the socket_strerror isn't very helpful - it says operation not
permitted */
$buf=trim($buf); #Trim whitespace.
if ($buf == 'quit') {
echo Quit command received\n;
break;
}
if ($buf == 'shutdown') {
socket_close($msgsock);
echo Shutdown command received\n;
break 2;
}
$talkback = PHP: You said '$buf'.\n;
socket_write($msgsock, $talkback, strlen($talkback));
echo $buf\n;
} while (true);
socket_close($msgsock);
echo Closed msgsocket; waiting for another connection\n;
} while (true);
socket_close($sock);
echo Closed main socket, exiting\n;
?
[2004-07-18 14:29:51] [EMAIL PROTECTED]
I cannot reproduce the problem with latest PHP5. Can you provide a
*full* reproducing case.
My scripts are :
server:
?php
error_reporting(E_ALL);
set_time_limit(0);
ob_implicit_flush();
$address = '127.0.0.1';
$port = 4322;
if (($sock = socket_create(AF_INET, SOCK_STREAM, SOL_TCP)) 0) {
echo socket_create() failed: reason: . socket_strerror($sock) .
\n;
}
if (($ret = socket_bind($sock, $address, $port)) 0) {
echo socket_bind() failed: reason: . socket_strerror($ret) .
\n;
}
if (($ret = socket_listen($sock, 5)) 0) {
echo socket_listen() failed: reason
#28646 [NEW]: RFE: function to fix microsoft smart quotesand other wrong characters
From: php at richardneill dot org Operating system: PHP version: 4.3.6 PHP Bug Type: Feature/Change Request Bug description: RFE: function to fix microsoft smart quotesand other wrong characters Description: Feature request: str_demoronise() On my website, I often find users pasting content that was written in Microsoft Word, and which contains undisplayable ASCII characters where there should be single/double quotes. Anyone viewing the result on a non-MS platform gets to see rectangles instead of quotes. The problem has been solved in perl here: http://www.fourmilab.ch/webtools/demoroniser/ I quote: Microsoft use their own extension to Latin-1, in which a variety of characters which do not appear in Latin-1 are inserted in the range 0x82 through 0x95--this having the merit of being incompatible with both Latin-1 and Unicode, which reserve this region for additional control characters. = I'd like to suggest the addition of a str_demoronise() function which fixes these wrong characters, and replaces them by the correct ASCII. Reproduce code: --- From the source of demoroniser, here are the substitutions made. The MS column is what Microsoft use (in Hex); the FIX column is the replacement: MS FIX 0x82, 0x83emf/em 0x84,, 0x85... 0x88^ 0x89' °/°°'-- whitsepace; no '' quotes 0x8B 0x8COe 0x91` 0x92' 0x93 0x94 0x95* 0x96- 0x97-- 0x98sup~/sup 0x99supTM/sup 0x9B 0x9Coe -- Edit bug report at http://bugs.php.net/?id=28646edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28646r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28646r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28646r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28646r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28646r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28646r=needscript Try newer version: http://bugs.php.net/fix.php?id=28646r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28646r=support Expected behavior: http://bugs.php.net/fix.php?id=28646r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28646r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28646r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28646r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28646r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28646r=dst IIS Stability: http://bugs.php.net/fix.php?id=28646r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28646r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28646r=float
#28646 [Opn]: RFE: function to fix microsoft smart quotesand other wrong characters
ID: 28646 User updated by: php at richardneill dot org Reported By: php at richardneill dot org Status: Open Bug Type:Feature/Change Request PHP Version: 4.3.6 New Comment: For safety's sake, it's probably wiser to have lt; gt; \` \' \ as the replacements. Otherwise, we have a nice big security hole, since magic_quotes gets bypassed. Previous Comments: [2004-06-05 23:55:34] php at richardneill dot org Description: Feature request: str_demoronise() On my website, I often find users pasting content that was written in Microsoft Word, and which contains undisplayable ASCII characters where there should be single/double quotes. Anyone viewing the result on a non-MS platform gets to see rectangles instead of quotes. The problem has been solved in perl here: http://www.fourmilab.ch/webtools/demoroniser/ I quote: Microsoft use their own extension to Latin-1, in which a variety of characters which do not appear in Latin-1 are inserted in the range 0x82 through 0x95--this having the merit of being incompatible with both Latin-1 and Unicode, which reserve this region for additional control characters. = I'd like to suggest the addition of a str_demoronise() function which fixes these wrong characters, and replaces them by the correct ASCII. Reproduce code: --- From the source of demoroniser, here are the substitutions made. The MS column is what Microsoft use (in Hex); the FIX column is the replacement: MS FIX 0x82, 0x83emf/em 0x84,, 0x85... 0x88^ 0x89' °/°°'-- whitsepace; no '' quotes 0x8B 0x8COe 0x91` 0x92' 0x93 0x94 0x95* 0x96- 0x97-- 0x98sup~/sup 0x99supTM/sup 0x9B 0x9Coe -- Edit this bug report at http://bugs.php.net/?id=28646edit=1
#28141 [Opn]: socket_read return type: false vs
ID: 28141
User updated by: php at richardneill dot org
-Summary: sokcet_read return type: false vs
Reported By: php at richardneill dot org
Status: Open
Bug Type: Sockets related
Operating System: Linux
PHP Version: 5.0.0RC1
New Comment:
This is still present in RC2
Previous Comments:
[2004-04-25 06:56:24] php at richardneill dot org
Description:
According to the documentation, socket_read() can return:
1)A string - normal data
2)An empty string - the other end closed the connection
3)false - something went wrong.
But it seems to be returning false on connection close.
Reproduce code:
---
$buffer=socket_read($socket,2048,PHP_NORMAL_READ);
if ($buffer===false){
echo Error: socket_read() failed: reason:
.socket_strerror(socket_last_error()). \n;
exit (1);
}elseif ($buffer==''){
echo Socket $socket returned an empty string. Closing
connection\n;
socket_close($socket);
}else{
echo Received data.trim($buffer).\n;
}
Expected result:
I'm using netcat as a client, and then killing the netcat process with
Ctrl-C to simulate remote host disconnecting.
I expect to see the socket close.
Actual result:
--
Actually, the php script exits, because socket_read returns
false instead of .
This may be a bug in the documentation for socket_read, rather than in
its behaviour.
Thanks for your help - Richard
--
Edit this bug report at http://bugs.php.net/?id=28141edit=1
#28140 [NEW]: html_errors is *on* for CLI
From: php at richardneill dot org Operating system: Linux PHP version: 5.0.0RC1 PHP Bug Type: CGI related Bug description: html_errors is *on* for CLI Description: Using php from the command line, the error messages include html tags. The html_errors directive is supposed to be overridden for PHP-CLI: http://uk.php.net/manual/en/features.commandline.php Reproduce code: --- #!/usr/local/bin/php -q ? echo no semicolon ? run this from the command line. Expected result: Parse error: parse error, expecting `','' or `';'' in /home/rjn/test.php on line 4 (this is what I see using PHP 4.3.3) Actual result: -- br / bParse error/b: parse error, unexpected T_VARIABLE, expecting ',' or ';' in b/home/rjn/test/php/b on line b4/bbr / (this is what I see in PHP 5.0.0RC1) -- Edit bug report at http://bugs.php.net/?id=28140edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28140r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28140r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28140r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28140r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28140r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28140r=needscript Try newer version: http://bugs.php.net/fix.php?id=28140r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28140r=support Expected behavior: http://bugs.php.net/fix.php?id=28140r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28140r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28140r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28140r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28140r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28140r=dst IIS Stability: http://bugs.php.net/fix.php?id=28140r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28140r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28140r=float
#28140 [Fbk-Opn]: html_errors is *on* for CLI
ID: 28140 User updated by: php at richardneill dot org Reported By: php at richardneill dot org -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Linux PHP Version: 5.0.0RC1 New Comment: Quite right - I do apologise. I had simply assumed that a script which began with #!/usr/local/bin/php would be the CLI version. (That's how it used to work, with the Mandrake rpms, but I had to compile it myself to have --enable-sockets), and the default wasn't what I expected. Sorry for wasting your time. Richard Previous Comments: [2004-04-25 05:30:22] [EMAIL PROTECTED] Not reproducable here, double check that you are indeed using the CLI version of PHP: /usr/local/bin/php -v [2004-04-25 04:06:54] php at richardneill dot org Description: Using php from the command line, the error messages include html tags. The html_errors directive is supposed to be overridden for PHP-CLI: http://uk.php.net/manual/en/features.commandline.php Reproduce code: --- #!/usr/local/bin/php -q ? echo no semicolon ? run this from the command line. Expected result: Parse error: parse error, expecting `','' or `';'' in /home/rjn/test.php on line 4 (this is what I see using PHP 4.3.3) Actual result: -- br / bParse error/b: parse error, unexpected T_VARIABLE, expecting ',' or ';' in b/home/rjn/test/php/b on line b4/bbr / (this is what I see in PHP 5.0.0RC1) -- Edit this bug report at http://bugs.php.net/?id=28140edit=1
#28141 [NEW]: sokcet_read return type: false vs
From: php at richardneill dot org
Operating system: Linux
PHP version: 5.0.0RC1
PHP Bug Type: Sockets related
Bug description: sokcet_read return type: false vs
Description:
According to the documentation, socket_read() can return:
1)A string - normal data
2)An empty string - the other end closed the connection
3)false - something went wrong.
But it seems to be returning false on connection close.
Reproduce code:
---
$buffer=socket_read($socket,2048,PHP_NORMAL_READ);
if ($buffer===false){
echo Error: socket_read() failed: reason:
.socket_strerror(socket_last_error()). \n;
exit (1);
}elseif ($buffer==''){
echo Socket $socket returned an empty string. Closing connection\n;
socket_close($socket);
}else{
echo Received data.trim($buffer).\n;
}
Expected result:
I'm using netcat as a client, and then killing the netcat process with
Ctrl-C to simulate remote host disconnecting.
I expect to see the socket close.
Actual result:
--
Actually, the php script exits, because socket_read returns
false instead of .
This may be a bug in the documentation for socket_read, rather than in its
behaviour.
Thanks for your help - Richard
--
Edit bug report at http://bugs.php.net/?id=28141edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28141r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28141r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28141r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28141r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28141r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28141r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28141r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28141r=support
Expected behavior: http://bugs.php.net/fix.php?id=28141r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28141r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28141r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28141r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28141r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28141r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28141r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28141r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28141r=float
#26818 [NEW]: getopt parses incorrectly
From: php at richardneill dot org
Operating system: Linux (Mandrake)
PHP version: 4.3.4
PHP Bug Type: CGI related
Bug description: getopt parses incorrectly
Description:
When parsing options, if the command line arguments are WRONG, php mangles
them in such a way as to give an incorrect, but valid response.
Eg my program normally takes arguments:
./getopt.php -a -x foo -y bar
(ie. option a takes no value; options x,y take values)
Therefore, if I run it as
./getopt.php -a -x -y bar
this is clearly a mistake: I omitted the value for -x.
HOWEVER, php assumes that I wanted the value for -x to be '-y'
If this is a feature, not a bug, it might be worth documentig it, or
providing a switch to enable the behaviour I'd expect. Thank you.
Reproduce code:
---
#!/usr/bin/php
?
$flags=ax:y:;
$options_array=getopt($flags);
echo Here are the results of getopt:\n;
foreach ($options_array as $key = $value){
echo \tkey:\t $key\t value is:\t $value;
if ($value===false){
echo \t[FALSE];
}
echo \n;
}
echo \n;
#N.B. If options -x and -y each expect an argument, then one might expect
# 'getopt.php -x -y foo' to result in $key=x,$value=false;
$key=y,$value=foo
# BUT actually, the result is $key=x,$value=-y; and foo is left over.
Expected result:
[rjn]$ ./getopt.php -a -x -y bar
Here are the results of getopt:
key: a value is: [FALSE]
key: x value is: [FALSE]
key: y value is: bar
Actual result:
--
[rjn]$ ./getopt.php -a -x -y bar
Here are the results of getopt:
key: a value is: [FALSE]
key: x value is: -y
--
Edit bug report at http://bugs.php.net/?id=26818edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26818r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26818r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26818r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26818r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26818r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26818r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26818r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26818r=support
Expected behavior: http://bugs.php.net/fix.php?id=26818r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26818r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26818r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26818r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26818r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26818r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26818r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26818r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26818r=float
#26818 [Bgs-Opn]: getopt parses incorrectly
ID: 26818
User updated by: php at richardneill dot org
Reported By: php at richardneill dot org
-Status: Bogus
+Status: Open
Bug Type: CGI related
Operating System: Linux (Mandrake)
PHP Version: 4.3.4
New Comment:
I agree with you about the manual. BUT, nevertheless, this is not the
behaviour that it should have. Currently, it isn't consistent with the
normal (GNU-like) command line behaviour.
If options -x and -y are supposed to take values, then if I enter the
command:
./getopt.php -a -x -y bar
it can mean only one of 2 things:
1)I, the user have made a mistake at the command line, and omitted the
value for $x. The script should be able to test for this as an error.
2)I meant to assign a null or false value to $x
(possible, not likely)
It is *very* unlikely that I meant to assign the value '-y' to $x. (If
I had meant to do this, I would have double quoted it).
Please can we at least have an option within getopts to parse options
in a standard manner? I'd suggest doing the following:
If an option expects a value, read along the command line
until reaching the next '-' or the end of line. This value (or false if
it is null) is placed in the options_array.
Thank you.
Richard
Previous Comments:
[2004-01-06 17:30:17] [EMAIL PROTECTED]
RTFM: It does not matter if an argument has leading white space. (it
means also: whitespace is omitted)
[2004-01-06 14:52:41] php at richardneill dot org
Description:
When parsing options, if the command line arguments are WRONG, php
mangles them in such a way as to give an incorrect, but valid
response.
Eg my program normally takes arguments:
./getopt.php -a -x foo -y bar
(ie. option a takes no value; options x,y take values)
Therefore, if I run it as
./getopt.php -a -x -y bar
this is clearly a mistake: I omitted the value for -x.
HOWEVER, php assumes that I wanted the value for -x to be '-y'
If this is a feature, not a bug, it might be worth documentig it, or
providing a switch to enable the behaviour I'd expect. Thank you.
Reproduce code:
---
#!/usr/bin/php
?
$flags=ax:y:;
$options_array=getopt($flags);
echo Here are the results of getopt:\n;
foreach ($options_array as $key = $value){
echo \tkey:\t $key\t value is:\t $value;
if ($value===false){
echo \t[FALSE];
}
echo \n;
}
echo \n;
#N.B. If options -x and -y each expect an argument, then one might
expect
# 'getopt.php -x -y foo' to result in $key=x,$value=false;
$key=y,$value=foo
# BUT actually, the result is $key=x,$value=-y; and foo is left
over.
Expected result:
[rjn]$ ./getopt.php -a -x -y bar
Here are the results of getopt:
key: a value is: [FALSE]
key: x value is: [FALSE]
key: y value is: bar
Actual result:
--
[rjn]$ ./getopt.php -a -x -y bar
Here are the results of getopt:
key: a value is: [FALSE]
key: x value is: -y
--
Edit this bug report at http://bugs.php.net/?id=26818edit=1
#26818 [Opn]: getopt parses incorrectly
ID: 26818
User updated by: php at richardneill dot org
Reported By: php at richardneill dot org
Status: Open
Bug Type: Feature/Change Request
Operating System: Linux (Mandrake)
PHP Version: 4.3.4
New Comment:
I do apologise - I thought that GNU's getopts was smarter than that!
So, I now agree that PHP is doing the standards-compliant thing. I
still think it would be useful if PHP had an option to parse options
my way :-)
Thanks for your help.
Richard
Previous Comments:
[2004-01-06 18:58:52] [EMAIL PROTECTED]
The function uses the GNU getopt function, so the behaviour is exactly
same. Moved the FRs.
[2004-01-06 17:53:42] php at richardneill dot org
I agree with you about the manual. BUT, nevertheless, this is not the
behaviour that it should have. Currently, it isn't consistent with the
normal (GNU-like) command line behaviour.
If options -x and -y are supposed to take values, then if I enter the
command:
./getopt.php -a -x -y bar
it can mean only one of 2 things:
1)I, the user have made a mistake at the command line, and omitted the
value for $x. The script should be able to test for this as an error.
2)I meant to assign a null or false value to $x
(possible, not likely)
It is *very* unlikely that I meant to assign the value '-y' to $x. (If
I had meant to do this, I would have double quoted it).
Please can we at least have an option within getopts to parse options
in a standard manner? I'd suggest doing the following:
If an option expects a value, read along the command line
until reaching the next '-' or the end of line. This value (or false if
it is null) is placed in the options_array.
Thank you.
Richard
[2004-01-06 17:30:17] [EMAIL PROTECTED]
RTFM: It does not matter if an argument has leading white space. (it
means also: whitespace is omitted)
[2004-01-06 14:52:41] php at richardneill dot org
Description:
When parsing options, if the command line arguments are WRONG, php
mangles them in such a way as to give an incorrect, but valid
response.
Eg my program normally takes arguments:
./getopt.php -a -x foo -y bar
(ie. option a takes no value; options x,y take values)
Therefore, if I run it as
./getopt.php -a -x -y bar
this is clearly a mistake: I omitted the value for -x.
HOWEVER, php assumes that I wanted the value for -x to be '-y'
If this is a feature, not a bug, it might be worth documentig it, or
providing a switch to enable the behaviour I'd expect. Thank you.
Reproduce code:
---
#!/usr/bin/php
?
$flags=ax:y:;
$options_array=getopt($flags);
echo Here are the results of getopt:\n;
foreach ($options_array as $key = $value){
echo \tkey:\t $key\t value is:\t $value;
if ($value===false){
echo \t[FALSE];
}
echo \n;
}
echo \n;
#N.B. If options -x and -y each expect an argument, then one might
expect
# 'getopt.php -x -y foo' to result in $key=x,$value=false;
$key=y,$value=foo
# BUT actually, the result is $key=x,$value=-y; and foo is left
over.
Expected result:
[rjn]$ ./getopt.php -a -x -y bar
Here are the results of getopt:
key: a value is: [FALSE]
key: x value is: [FALSE]
key: y value is: bar
Actual result:
--
[rjn]$ ./getopt.php -a -x -y bar
Here are the results of getopt:
key: a value is: [FALSE]
key: x value is: -y
--
Edit this bug report at http://bugs.php.net/?id=26818edit=1
#25334 [NEW]: edit_ini_file() function would be nice
From: php at richardneill dot org Operating system: Linux (Mandrake 9.1) PHP version: 4.3.1 PHP Bug Type: Feature/Change Request Bug description: edit_ini_file() function would be nice Description: Here's an idea that I think would be useful for a new function. I'd like a way to have an editable equivalent of parse_ini_file(). Many Unix programs have config files that can be edited *both* by hand, or automatically by the program. It would be nice to be able to do this in php. Eg if the file myfile.dat contains something like this: //This is a custom config or data file $foo=bar; #comment2 $wibble=bibble; /*comment 3*/ $aaa=3; Then, I might call the following in my script: edit_ini_file (myfile.dat, SET $foo=baz, UNSET $wibble, SET $bbb=4) And as a result, the file would be appropriately changed, without modifying the comments. In this case it would become: //This is a custom config/data file $foo=baz; #comment2 $wibble=false; /*comment 3*/ $aaa=3 $bbb=4; I'd suggest the function should be able to: 1)SET a variable (i.e. change it if it exists, otherwise, set it) 2)UNSET a variable 3)Add a comment (after a particular variable) 4)Change a comment. If I can be of any assistance, please let me know. I hope you like the idea. Thanks for PHP - I love it :-) -- Edit bug report at http://bugs.php.net/?id=25334edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25334r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25334r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25334r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25334r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25334r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25334r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25334r=support Expected behavior: http://bugs.php.net/fix.php?id=25334r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25334r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25334r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25334r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25334r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25334r=dst IIS Stability: http://bugs.php.net/fix.php?id=25334r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25334r=gnused
