#44771 [NEW]: Calling nonstatic methods in context of another objects

[igor at webta dot net]

From: igor at webta dot net
Operating system: 
PHP version:  5.3CVS-2008-04-18 (snap)
PHP Bug Type: Scripting Engine problem
Bug description:  Calling nonstatic methods in context of another objects

Description:

Calling nonstatic methods in context of another objects

Reproduce code:
---
class A
 {
 public function bar ()
 {
 sort($this->arr);
 }
 }
 
 class B
 {
 public $arr = array('a', 'c', 'b');
 
 function run ()
 {
 A::bar();
 var_dump($this->arr);
 }
 }
 
 $b = new B();
 $b->run();

Expected result:

Exception

Actual result:
--
Sorted array:

array
  0 => string 'a' (length=1)
  1 => string 'b' (length=1)
  2 => string 'c' (length=1)

-- 
Edit bug report at http://bugs.php.net/?id=44771&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=44771&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=44771&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=44771&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44771&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=44771&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=44771&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44771&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44771&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=44771&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44771&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=44771&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=44771&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44771&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=44771&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44771&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44771&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=44771&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=44771&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=44771&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44771&r=mysqlcfg

#44770 [Opn->Bgs]: Core Dump on Fbsd7 - php5-extension recode

[jani]

 ID:   44770
 Updated by:   [EMAIL PROTECTED]
 Reported By:  chargen at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: *Extensibility Functions
 Operating System: FreeBSD REL7
 PHP Version:  5.2.5
 New Comment:

RTFM: http://www.php.net/manual/en/recode.installation.php


Previous Comments:


[2008-04-18 05:03:55] chargen at gmail dot com

Description:

Core dump using PHP 5.2.- FreeBSD ports 20081804 - recode.so

I could reproduce a coredump with the recode.so extension enabled,
build from ports

/etc/make.conf

CFLAGS = -O2 -pipe -mtune=nocona -march=nocona
COPTFLAGS = -O2 -pipe -mtune=nocona -march=nocona

ports are from april 18th 2008


Reproduce code:
---

CLI result *without* recode.so enabled

ping# php -v
PHP 5.2.5 (cli) (built: Apr 18 2008 04:27:16)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies

reproducing the coredump

(deinstallation- If you`ve already build most of the PHP5-extensions
from ports:

rename the extensions .so dir to reinstall
ping# mv /usr/local/lib/php/20060613/
/usr/local/lib/php/20060613_bogus

then

cd /usr/ports/lang/php5-extensions

ping# make deinstall && make config 

enable recode

ping# make clean && make install && rehash

ping# cat /usr/local/etc/php/extensions.ini | grep "recode"

extension=recode.so

ping# php -v
PHP 5.2.5 (cli) (built: Apr 18 2008 04:27:16)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
Segmentation fault (core dumped)

no problems with the others sofar (build on AMD64 arch) , -O2 -pipe

extension=bz2.so
extension=calendar.so
extension=ctype.so
extension=pcre.so
extension=simplexml.so
extension=spl.so
extension=dom.so
extension=fileinfo.so
extension=filter.so
extension=fribidi.so
extension=ftp.so
extension=gd.so
extension=gettext.so
extension=hash.so
extension=iconv.so
extension=json.so
extension=mbstring.so
extension=mcrypt.so
extension=mhash.so
extension=ming.so
extension=mssql.so
extension=mysql.so
extension=mysqli.so
extension=openssl.so
extension=pcntl.so
extension=pdf.so
extension=pdo.so
extension=pdo_sqlite.so
extension=pgsql.so
extension=posix.so
extension=readline.so
extension=recode.so
extension=session.so
extension=sockets.so
extension=sqlite.so
extension=sysvmsg.so
extension=sysvsem.so
extension=sysvshm.so
extension=tokenizer.so
extension=xml.so
extension=wddx.so
extension=xmlreader.so
extension=xmlrpc.so
extension=xmlwriter.so
extension=xsl.so
extension=zip.so
extension=zlib.so

the recode.so crash affects cli with dumps and gives strange results 
when apache22 module is enabled

NOTE: reproduced with and without recommended php.ini
(php.ini-recommended / php.ini-dist)







-- 
Edit this bug report at http://bugs.php.net/?id=44770&edit=1

#44770 [NEW]: Core Dump on Fbsd7 - php5-extension recode

[chargen at gmail dot com]

From: chargen at gmail dot com
Operating system: FreeBSD REL7
PHP version:  5.2.5
PHP Bug Type: *Extensibility Functions
Bug description:  Core Dump on Fbsd7 - php5-extension recode

Description:

Core dump using PHP 5.2.- FreeBSD ports 20081804 - recode.so

I could reproduce a coredump with the recode.so extension enabled, build
from ports

/etc/make.conf

CFLAGS = -O2 -pipe -mtune=nocona -march=nocona
COPTFLAGS = -O2 -pipe -mtune=nocona -march=nocona

ports are from april 18th 2008


Reproduce code:
---

CLI result *without* recode.so enabled

ping# php -v
PHP 5.2.5 (cli) (built: Apr 18 2008 04:27:16)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies

reproducing the coredump

(deinstallation- If you`ve already build most of the PHP5-extensions from
ports:

rename the extensions .so dir to reinstall
ping# mv /usr/local/lib/php/20060613/ /usr/local/lib/php/20060613_bogus

then

cd /usr/ports/lang/php5-extensions

ping# make deinstall && make config 

enable recode

ping# make clean && make install && rehash

ping# cat /usr/local/etc/php/extensions.ini | grep "recode"

extension=recode.so

ping# php -v
PHP 5.2.5 (cli) (built: Apr 18 2008 04:27:16)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
Segmentation fault (core dumped)

no problems with the others sofar (build on AMD64 arch) , -O2 -pipe

extension=bz2.so
extension=calendar.so
extension=ctype.so
extension=pcre.so
extension=simplexml.so
extension=spl.so
extension=dom.so
extension=fileinfo.so
extension=filter.so
extension=fribidi.so
extension=ftp.so
extension=gd.so
extension=gettext.so
extension=hash.so
extension=iconv.so
extension=json.so
extension=mbstring.so
extension=mcrypt.so
extension=mhash.so
extension=ming.so
extension=mssql.so
extension=mysql.so
extension=mysqli.so
extension=openssl.so
extension=pcntl.so
extension=pdf.so
extension=pdo.so
extension=pdo_sqlite.so
extension=pgsql.so
extension=posix.so
extension=readline.so
extension=recode.so
extension=session.so
extension=sockets.so
extension=sqlite.so
extension=sysvmsg.so
extension=sysvsem.so
extension=sysvshm.so
extension=tokenizer.so
extension=xml.so
extension=wddx.so
extension=xmlreader.so
extension=xmlrpc.so
extension=xmlwriter.so
extension=xsl.so
extension=zip.so
extension=zlib.so

the recode.so crash affects cli with dumps and gives strange results  when
apache22 module is enabled

NOTE: reproduced with and without recommended php.ini (php.ini-recommended
/ php.ini-dist)



-- 
Edit bug report at http://bugs.php.net/?id=44770&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=44770&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=44770&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=44770&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44770&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=44770&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=44770&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44770&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44770&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=44770&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44770&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=44770&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=44770&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44770&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=44770&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44770&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44770&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=44770&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=44770&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=44770&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44770&r=mysqlcfg

#44768 [Opn->Bgs]: getAttribute can't find textarea value

[chregu]

 ID:   44768
 Updated by:   [EMAIL PROTECTED]
 Reported By:  sathia dot musso at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: DOM XML related
 Operating System: linux
 PHP Version:  5.2.5
 New Comment:

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

If there's no attribute "value" then there's nothing to print then 
there's no output.

  print $textarea->nodeName;

instead of

  print $textarea->getAttribute("value");

does produced some expected thing.


Previous Comments:


[2008-04-17 22:51:51] sathia dot musso at gmail dot com

Description:

I know there's no such attribute value="" but you can't access the
content ($textarea->textContent will not work as well) of that if the
content inside is wrapped within "lt" and "gt"  (ie when you read embed tags from textarea)

Reproduce code:
---
$documentx = new DOMDocument();
$documentx->loadHTML($data);
$textareas = $documentx->getElementsByTagName("textarea");
foreach($textareas AS $textarea){
   print($textarea->getAttribute("value"));
}











-- 
Edit this bug report at http://bugs.php.net/?id=44768&edit=1

#43053 [Com]: Scientific notation

[int-e at gmx dot de]

 ID:   43053
 Comment by:   int-e at gmx dot de
 Reported By:  owner at dragon-hearts dot net
 Status:   Verified
 Bug Type: Scripting Engine problem
 Operating System: Centos4
 PHP Version:  5CVS-2007-10-25
 New Comment:

Here's a patch that fixes the problem.

http://int-e.home.tlink.de/php/php-printf.patch

There are three changes here:
1) get rid of a hack in zend_dtoa() that sometimes kept trailing zeros
(which caused the inconsistent behaviour between printing 120 and
130)
2) change php_gcvt() to switch to E format for large numbers if the
number wouldn't fit into precision digits.
3) update a few tests to reflect the change to the precision semantics.
I believe that in each of these cases, the test was flawed. Note that a
precision of 14 (the default) means that 15 digit numbers should be
printed in E notation, at least that's how I read the sprintf
documentation.


Previous Comments:


[2008-04-15 22:37:33] rbro at hotmail dot com

Your examples work correctly for me in PHP 5.2.1, so I'm not sure if
the issue was caused by change you mentioned or something else, but it
definitely happens for me in PHP 5.2.2 and later.



[2008-04-15 20:43:16] marek dot chodor at gmail dot com

on
PHP Version 5.2.6RC1-pl1-gentoo
and PHP 5.2.4 Fedora7
the same problem

$ php -r "echo 12000;"
12000

$ php -r "echo (double)12000;"
1.2E+8

$ php -r "echo (int)(double)12000;"
12000

It could be related to this change in PHP 5.2.1:
# Changed double-to-string utilities to use BSD implementation.
(Dmitry, Tony)



[2008-04-15 09:08:48] ali at adcworks dot com

I am receiving longs via SOAP responses which represent IDs of
accounts. Due to some issue with PHP and long values when we retrieve
accounts using the same IDs we receive, we get other peoples' accounts
back - not good!

I have found the core problem and the snippet of code below shows that
the correct ID of 2853622757 is transformed into the incorrect
ID of 2853622752 (last number goes down 5).


F0 (no formatting) 

F1 (sprintf) 

F2 (number_format) 


OUTPUT
==

F0 (no formatting)
2.854E+17
F1 (sprintf)
2853622752
F2 (number_format)
2853622752



[2008-04-04 17:46:57] admin at vr-realty dot com

I had a working database for my office Stock Trading Pool when
AAAkkk 1.23E+007. The non programmers there were all freaked the
hell out. They thought E meant Error and that we had lost all of our
money. trying to tell 70+ people, that haven't seen Scientific notation
since they were in 9th grade, that it's not a problem and we will fix it
was no easy task. By the time it was brought to my attention people had
already started trying to figure out how to sue me for losing their
money, yeah it was a mess. And they didn't know that what they see is
just a thing for them to see and reference and really could be forgotten
and not updated for days. 

anyways 

I wen through and changed the MySql DB from floats to VarChars. and
type casted the $vars I pulled from the DB to float using

$curprice = (float)$price;
 and the ones that could be int like the number of shares
$curshares = (int)$shares;
 then I did the math
$total = (float)($price*$shares);

now the General population is feeling at ease and the death threats
have subsided. I'm still trying to understand why Scientific notation
would come into play.

maybe it sould be an obscure function like INT_TO_SCI($var) or
num_to_sci($var) ..

like the automatic and natural way to have the numbers over millions
sould be preserved as a whole long string no matter what the length with
the option to convert it to scientific notation if that suits your
needs.

my 2cents



[2008-03-06 15:56:45] rbro at hotmail dot com

I agree - to me, this is a BC break that wasn't listed on any changelog
or announcement.  I have been holding off on upgrading my PHP version to
anything later than 5.2.1 because of this issue.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/43053

-- 
Edit this bug report at http://bugs.php.net/?id=43053&edit=1

#44769 [NEW]: declaring private magic methods should throw error

[todd at magnifisites dot com]

From: todd at magnifisites dot com
Operating system: Any
PHP version:  5.2.5
PHP Bug Type: Class/Object related
Bug description:  declaring private magic methods should throw error

Description:

When using object overloading I thought I might receive at the very least
a warning error if I attempted to declare any of the magic methods as
private in a class definition as per the documentation:

"All overloading methods must be defined as public."

http://php.net/language.oop5.overloading.php

Also tested in PHP 6CVS-2008-04-17 (snap)

Reproduce code:
---
class MemberTest {
/**  Location for overloaded data.  */
private $data = array();
private function __set($name, $value) {
echo "Setting '$name' to '$value'\n";
$this->data[$name] = $value;
}
private function __get($name) {
echo "Getting '$name'\n";
if (array_key_exists($name, $this->data)) {
return $this->data[$name];
}
}
}
echo "\n";
$obj = new MemberTest;
$obj->a = 1;
echo $obj->a . "\n";
exit;

Expected result:

A FATAL error or at the very least a WARNING error with
error_reporting  =  E_ALL | E_STRICT

Actual result:
--

Setting 'a' to '1'
Getting 'a'
1


-- 
Edit bug report at http://bugs.php.net/?id=44769&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=44769&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=44769&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=44769&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44769&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=44769&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=44769&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44769&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44769&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=44769&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44769&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=44769&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=44769&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44769&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=44769&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44769&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44769&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=44769&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=44769&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=44769&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44769&r=mysqlcfg

#44768 [NEW]: getAttribute can't find textarea value

[sathia dot musso at gmail dot com]

From: sathia dot musso at gmail dot com
Operating system: linux
PHP version:  5.2.5
PHP Bug Type: DOM XML related
Bug description:  getAttribute can't find  textarea value

Description:

I know there's no such attribute value="" but you can't access the content
($textarea->textContent will not work as well) of that if the content
inside is wrapped within "lt" and "gt" 
(ie when you read embed tags from textarea)

Reproduce code:
---
$documentx = new DOMDocument();
$documentx->loadHTML($data);
$textareas = $documentx->getElementsByTagName("textarea");
foreach($textareas AS $textarea){
   print($textarea->getAttribute("value"));
}







-- 
Edit bug report at http://bugs.php.net/?id=44768&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=44768&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=44768&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=44768&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44768&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=44768&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=44768&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44768&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44768&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=44768&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44768&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=44768&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=44768&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44768&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=44768&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44768&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44768&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=44768&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=44768&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=44768&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44768&r=mysqlcfg

#44749 [Bgs]: FastCGI problems during large HTTP Posts (corruption or hang)

[eth at ethaniel dot com]

 ID:   44749
 User updated by:  eth at ethaniel dot com
 Reported By:  eth at ethaniel dot com
 Status:   Bogus
 Bug Type: CGI related
 Operating System: Freebsd 7.0
 PHP Version:  5.2.5
 New Comment:

is Suhosin really that bad?


Previous Comments:


[2008-04-17 21:16:44] [EMAIL PROTECTED]

Your problem is: (with _suhosin_ patch).




[2008-04-17 10:59:10] eth at ethaniel dot com

server.network-backend = "write" started causing some strange "resource
unavailable" errors in the error log, so I changed it to

server.network-backend = "writev" and everything went back to normal.



[2008-04-17 08:58:15] eth at ethaniel dot com

Seems like the problem was in lighttpd.

Setting server.network-backend = "write" in lighttpd.conf solved the
problem.



[2008-04-16 21:31:05] eth at ethaniel dot com

Description:

I use Freebsd 7.0 with lighttpd 1.4.19 and php-cgi 5.2.5 (with suhosin
patch).

I noticed, that when I do a large upload (1.2 megabytes) php works
unadequately: randomly it either corrupts the upload or just freezes.

So for instance, if I run php-cgi on a tcp port (1026) it successfully
accepts all uploads that are given to it from lighttpd and processes
them through the script. But randomly (sometimes several times in a row,
sometimes one out of 10 requests) it corrupts the post data (several
bytes in the center of the 1.2 megabyte block get corrupted - replaced
with 00 00 00 hex values). Nothing freezes at this configuration.

If I run php-cgi as a unix socket (/tmp/php.sock) it either accepts the
upload (and never shows any sign of corruption, all data is processed
normally), or just halts and leaves the connection open (doesn't reply
to the current and any new connections either).
Sometimes it just unfreezes after a while and starts accepting new
connections, sometimes I just have to respawn php-cgi.

My best guess is that it might have something to do with the freebsd
7.0 socket handling. Maybe not - maybe it really is a bug in php-cgi.

I checked - lighttpd has all the uploaded files uncorrupted. The bad
things start happening somewhere between lighttpd and fastcgi php.

Reproduce code:
---
Here is the command I use to make the upload from the remote host.

curl -vv -# -s -F "[EMAIL PROTECTED]" -H "Host: upload.host.ru" -H
"Expect:" -H "Content-Type:" -0 1.1.1.1:200/testupload.php

Note the empty Content-type - once I noticed the corruption, I decided
to make a test and debug HTTP_RAW_POST_DATA by hand. The corruption was
all the way up there.

Expected result:

The testupload.php script checks the HTTP_RAW_POST_DATA, extracts the
uploaded files from mime headers and checks it's md5 value. If MD5 is
incorrect, it logs the uploaded file and then I compare it to the normal
sample.

Actual result:
--
Nothing here.





-- 
Edit this bug report at http://bugs.php.net/?id=44749&edit=1

#44098 [Com]: imap_utf8() returns only capital letters

[brett at fogcreek dot com]

 ID:   44098
 Comment by:   brett at fogcreek dot com
 Reported By:  steffen at dislabs dot de
 Status:   No Feedback
 Bug Type: IMAP related
 Operating System: FreeBSD 6.2
 PHP Version:  5.2.5
 Assigned To:  fb-req-jani
 New Comment:

Confirmed with Ubuntu Hardy Heron's current build of PHP:
5.2.4-2ubuntu5

$ php -v
PHP 5.2.4-2ubuntu5 with Suhosin-Patch 0.9.6.2 (cli) (built: Feb 27 2008
20:43:54) 
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies

$ cat test3.php 


$ php test3.php 
LUZON®14 DOT COM


Previous Comments:


[2008-04-11 13:47:51] jason at foreflight dot com

I am seeing this too:

Red Hat Enterprise Linux ES release 4 (Nahant Update 6)
CClient: imap-2007a1



[2008-04-11 01:00:00] 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".



[2008-04-03 14:31:46] [EMAIL PROTECTED]

What c-client version did you compile PHP with?



[2008-02-13 11:06:32] steffen at dislabs dot de

ok i was wrong with debian.

This is the info from phpinfo:

FreeBSD xx 6.2-RELEASE-p9 FreeBSD 6.2-RELEASE-p9 #0: Fri Dec 28
22:40:13 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP i386



[2008-02-13 01:17:20] [EMAIL PROTECTED]

Works fine to me... What libc-client-dev version you have used?

I used 7:2002edebian1-13.1ubuntu1



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/44098

-- 
Edit this bug report at http://bugs.php.net/?id=44098&edit=1

#44749 [Opn->Bgs]: FastCGI problems during large HTTP Posts (corruption or hang)

[jani]

 ID:   44749
 Updated by:   [EMAIL PROTECTED]
 Reported By:  eth at ethaniel dot com
-Status:   Open
+Status:   Bogus
 Bug Type: CGI related
 Operating System: Freebsd 7.0
 PHP Version:  5.2.5
 New Comment:

Your problem is: (with _suhosin_ patch).



Previous Comments:


[2008-04-17 10:59:10] eth at ethaniel dot com

server.network-backend = "write" started causing some strange "resource
unavailable" errors in the error log, so I changed it to

server.network-backend = "writev" and everything went back to normal.



[2008-04-17 08:58:15] eth at ethaniel dot com

Seems like the problem was in lighttpd.

Setting server.network-backend = "write" in lighttpd.conf solved the
problem.



[2008-04-16 21:31:05] eth at ethaniel dot com

Description:

I use Freebsd 7.0 with lighttpd 1.4.19 and php-cgi 5.2.5 (with suhosin
patch).

I noticed, that when I do a large upload (1.2 megabytes) php works
unadequately: randomly it either corrupts the upload or just freezes.

So for instance, if I run php-cgi on a tcp port (1026) it successfully
accepts all uploads that are given to it from lighttpd and processes
them through the script. But randomly (sometimes several times in a row,
sometimes one out of 10 requests) it corrupts the post data (several
bytes in the center of the 1.2 megabyte block get corrupted - replaced
with 00 00 00 hex values). Nothing freezes at this configuration.

If I run php-cgi as a unix socket (/tmp/php.sock) it either accepts the
upload (and never shows any sign of corruption, all data is processed
normally), or just halts and leaves the connection open (doesn't reply
to the current and any new connections either).
Sometimes it just unfreezes after a while and starts accepting new
connections, sometimes I just have to respawn php-cgi.

My best guess is that it might have something to do with the freebsd
7.0 socket handling. Maybe not - maybe it really is a bug in php-cgi.

I checked - lighttpd has all the uploaded files uncorrupted. The bad
things start happening somewhere between lighttpd and fastcgi php.

Reproduce code:
---
Here is the command I use to make the upload from the remote host.

curl -vv -# -s -F "[EMAIL PROTECTED]" -H "Host: upload.host.ru" -H
"Expect:" -H "Content-Type:" -0 1.1.1.1:200/testupload.php

Note the empty Content-type - once I noticed the corruption, I decided
to make a test and debug HTTP_RAW_POST_DATA by hand. The corruption was
all the way up there.

Expected result:

The testupload.php script checks the HTTP_RAW_POST_DATA, extracts the
uploaded files from mime headers and checks it's md5 value. If MD5 is
incorrect, it logs the uploaded file and then I compare it to the normal
sample.

Actual result:
--
Nothing here.





-- 
Edit this bug report at http://bugs.php.net/?id=44749&edit=1

#44098 [Com]: imap_utf8() returns only capital letters

[brett at fogcreek dot com]

 ID:   44098
 Comment by:   brett at fogcreek dot com
 Reported By:  steffen at dislabs dot de
 Status:   No Feedback
 Bug Type: IMAP related
 Operating System: FreeBSD 6.2
 PHP Version:  5.2.5
 Assigned To:  fb-req-jani
 New Comment:

Here is the php5-imap info:

$ aptitude show php5-imap
Package: php5-imap
State: installed
Automatically installed: yes
Version: 5.2.3-0ubuntu3
Priority: optional
Section: universe/web
Maintainer: Ubuntu MOTU Developers <[EMAIL PROTECTED]>
Uncompressed Size: 176k
Depends: debconf (>= 0.5) | debconf-2.0, libc-client2007, libc6 (>=
2.7-1), libcomerr2 (>= 1.33-3), libkrb53 (>= 1.6.dfsg.2), libpam0g (>=
0.99.7.1), libssl0.9.8 (>= 0.9.8f-1), phpapi-20060613+lfs
Description: IMAP module for php5
 This package provides a module for IMAP functions in PHP scripts.


# ldd /usr/lib/php5/20060613+lfs/imap.so 
linux-gate.so.1 =>  (0xb7f8d000)
libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb7f27000)
libc-client.so.2007 => /usr/lib/libc-client.so.2007 (0xb7e1c000)
libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb7de9000)
libpam.so.0 => /lib/libpam.so.0 (0xb7ddf000)
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb7db6000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb7d29000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb7d06000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7d03000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7bb3000)
libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8
(0xb7a71000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7a6d000)
libz.so.1 => /usr/lib/libz.so.1 (0xb7a58000)
libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb7a5)
libkeyutils.so.1 => /lib/libkeyutils.so.1 (0xb7a4c000)
libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0xb7a39000)
/lib/ld-linux.so.2 (0xb7f8e000)


Previous Comments:


[2008-04-17 21:19:10] brett at fogcreek dot com

Confirmed with Ubuntu Hardy Heron's current build of PHP:
5.2.4-2ubuntu5

$ php -v
PHP 5.2.4-2ubuntu5 with Suhosin-Patch 0.9.6.2 (cli) (built: Feb 27 2008
20:43:54) 
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies

$ cat test3.php 


$ php test3.php 
LUZON®14 DOT COM



[2008-04-11 13:47:51] jason at foreflight dot com

I am seeing this too:

Red Hat Enterprise Linux ES release 4 (Nahant Update 6)
CClient: imap-2007a1



[2008-04-11 01:00:00] 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".



[2008-04-03 14:31:46] [EMAIL PROTECTED]

What c-client version did you compile PHP with?



[2008-02-13 11:06:32] steffen at dislabs dot de

ok i was wrong with debian.

This is the info from phpinfo:

FreeBSD xx 6.2-RELEASE-p9 FreeBSD 6.2-RELEASE-p9 #0: Fri Dec 28
22:40:13 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP i386



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/44098

-- 
Edit this bug report at http://bugs.php.net/?id=44098&edit=1

#44758 [Opn->Bgs]: msession invalid configure option

[jani]

 ID:   44758
 Updated by:   [EMAIL PROTECTED]
 Reported By:  denis at edistar dot com
-Status:   Open
+Status:   Bogus
-Bug Type: *Compile Issues
+Bug Type: *General Issues
 Operating System: Linux
 PHP Version:  5.2.5
 New Comment:

That's because there is no such extension in PHP. 
See http://cvs.php.net/viewvc.cgi/pecl/msession/ (there's no
maintainer, so nobody has made a proper PECL package of it..)


Previous Comments:


[2008-04-17 13:28:48] denis at edistar dot com

Description:

I'm trying to compile php with msession support.
Configure fails with the following message:

Notice: Following unknown configure options were used:

--with-msession

Check './configure --help' for available options


Reproduce code:
---
./configure --with-msession

Expected result:

No warnings should be generated.

Actual result:
--
Notice: Following unknown configure options were used:

--with-msession

Check './configure --help' for available options






-- 
Edit this bug report at http://bugs.php.net/?id=44758&edit=1

#44729 [Opn->Fbk]: display_errors = Off not respected

[jani]

 ID:   44729
 Updated by:   [EMAIL PROTECTED]
 Reported By:  hsbrown2 at verizon dot net
-Status:   Open
+Status:   Feedback
 Bug Type: PHP options/info functions
 Operating System: Windows Server 2008
 PHP Version:  5.2.5
 Assigned To:  fb-req-jani
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows (zip):
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

For Windows (installer):

  http://snaps.php.net/win32/php5.2-win32-installer-latest.msi

And please, use the binary distro instead of compiling yourself.
If the problem persists, please provide a live URL to the phpinfo().
Also provide the actual output in the log file.


Previous Comments:


[2008-04-16 02:26:23] hsbrown2 at verizon dot net

PHP Version 5.2.5 

System  Windows NT WINWEB1 6.0 build 6001  
Build Date  Nov 8 2007 23:32:05  
Configure Command  cscript /nologo configure.js
"--enable-snapshot-build" "--with-gd=shared" "--disable-zts"
"--disable-isapi" "--disable-activescript"  
Server API  CGI/FastCGI  
Virtual Directory Support  disabled  
Configuration File (php.ini) Path  C:\Windows  
Loaded Configuration File  C:\Windows\php.ini  
PHP API  20041225  
PHP Extension  20060613  
Zend Extension  220060519  
Debug Build  no  
Thread Safety  disabled  
Zend Memory Manager  enabled  
IPv6 Support  enabled  
Registered PHP Streams  php, file, data, http, ftp, compress.zlib,
compress.bzip2  
Registered Stream Socket Transports  tcp, udp  
Registered Stream Filters  convert.iconv.*, string.rot13,
string.toupper, string.tolower, string.strip_tags, convert.*, consumed,
zlib.*, bzip2.*  

 This program makes use of the Zend Scripting Language Engine:
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
 




PHP Credits



Configuration
PHP Core
Directive Local Value Master Value 
allow_call_time_pass_reference Off Off 
allow_url_fopen On On 
allow_url_include Off Off 
always_populate_raw_post_data Off Off 
arg_separator.input & & 
arg_separator.output & & 
asp_tags Off Off 
auto_append_file no value no value 
auto_globals_jit On On 
auto_prepend_file no value no value 
browscap no value no value 
default_charset no value no value 
default_mimetype text/html text/html 
define_syslog_variables Off Off 
disable_classes no value no value 
disable_functions no value no value 
display_errors Off Off 
display_startup_errors Off Off 
doc_root no value no value 
docref_ext no value no value 
docref_root no value no value 
enable_dl On On 
error_append_string no value no value 
error_log E:\wwwroot\logs\phperrors.log E:\wwwroot\logs\phperrors.log 
error_prepend_string no value no value 
error_reporting 6135 6135 
expose_php On On 
extension_dir ext ext 
file_uploads On On 
highlight.bg #FF #FF 
highlight.comment #FF8000 #FF8000 
highlight.default #BB #BB 
highlight.html #00 #00 
highlight.keyword #007700 #007700 
highlight.string #DD #DD 
html_errors On On 
ignore_repeated_errors Off Off 
ignore_repeated_source Off Off 
ignore_user_abort Off Off 
implicit_flush Off Off 
include_path .;C:\php5\pear .;C:\php5\pear 
log_errors On On 
log_errors_max_len 1024 1024 
magic_quotes_gpc Off Off 
magic_quotes_runtime Off Off 
magic_quotes_sybase Off Off 
mail.force_extra_parameters no value no value 
max_execution_time 30 30 
max_input_nesting_level 64 64 
max_input_time 60 60 
memory_limit 128M 128M 
open_basedir no value no value 
output_buffering 4096 4096 
output_handler no value no value 
post_max_size 8M 8M 
precision 14 14 
realpath_cache_size 16K 16K 
realpath_cache_ttl 120 120 
register_argc_argv Off Off 
register_globals Off Off 
register_long_arrays Off Off 
report_memleaks On On 
report_zend_debug On On 
safe_mode Off Off 
safe_mode_exec_dir no value no value 
safe_mode_gid Off Off 
safe_mode_include_dir no value no value 
sendmail_from [EMAIL PROTECTED] [EMAIL PROTECTED] 
sendmail_path no value no value 
serialize_precision 100 100 
short_open_tag Off Off 
SMTP localhost localhost 
smtp_port 25 25 
sql.safe_mode Off Off 
track_errors Off Off 
unserialize_callback_func no value no value 
upload_max_filesize 5M 5M 
upload_tmp_dir E:\wwwroot\tmp E:\wwwroot\tmp 
user_dir no value no value 
variables_order GPCS GPCS 
xmlrpc_error_number 0 0 
xmlrpc_errors Off Off 
y2k_compliance On On 
zend.ze1_compatibility_mode Off Off



[2008-04-15 06:26:38] [EMAIL PROTECTED]

Show the top part of the phpinfo() output please.



[2008-04-15 05:07:37] hsbrown2 at verizon dot net

Description:

On Windows Server 2008 fcgi, display_errors = Of

#44767 [NEW]: Incorrect handling of a closing # to # based comments

[ikickdogsforfun at hotmail dot com]

From: ikickdogsforfun at hotmail dot com
Operating system: Gentoo Linux
PHP version:  5.2.6RC5
PHP Bug Type: *General Issues
Bug description:  Incorrect handling of a closing # to # based comments

Description:

A # comment can be closed by a second # causing PHP to act rather oddly.
Any errors that occur on the same line but after the closing # are reported
as an error on the next line, however if there are no errors anything after
the second # is ignored and not processed as if it was a comment. I think
based on this, there needs to be some concistency about what happens when a
second # is encountered. Are these intended to be embedded comments which
can be be closed? Or should everything being ignored after the first #
untill a new line character is encountered?

Reproduce code:
---
This produces 2 errors, one on line 2, one on line 3, though they are both
about line 3:

This only echos out 'some':


Expected result:

I would expect to see 'some text' echoed out, as I was under the
impression these kinds of comments were imbedded.

Actual result:
--
See the code section

-- 
Edit bug report at http://bugs.php.net/?id=44767&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=44767&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=44767&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=44767&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44767&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=44767&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=44767&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44767&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44767&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=44767&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44767&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=44767&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=44767&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44767&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=44767&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44767&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44767&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=44767&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=44767&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=44767&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44767&r=mysqlcfg

#44648 [Asn->Csd]: Attribute names not checked for well-formedness

[rrichards]

 ID:   44648
 Updated by:   [EMAIL PROTECTED]
-Summary:  All-or-nothing for production checks in DOM interface
 Reported By:  [EMAIL PROTECTED]
-Status:   Assigned
+Status:   Closed
 Bug Type: DOM XML related
 Operating System: Windows Vista
 PHP Version:  5.2.5
 Assigned To:  rrichards
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2008-04-06 14:06:09] geoffers+phpbugs at gmail dot com

While we should be throwing exceptions when strictErrorChecking is
true, 
behaviour when it is false is undefined. I would suggest in that case
to 
keep allowing everything.



[2008-04-06 04:15:54] [EMAIL PROTECTED]

You're right, that was my mistake.

I suppose that any of the places where the DOM specification could
raise an exception would be the places where there needs to be
error-checking.

Ought of curiosity, how come we don't use gdome2?



[2008-04-05 23:22:24] [EMAIL PROTECTED]

You should read the specs more closely. Names are most certainly
checked 
and a DOMException with an INVALID_CHARACTER_ERROR error is thrown.

Some of the others I need to look at because it is perfectly fine to 
create non well formed XML using DOM though it should error during 
serialization, so for those the bug would onl be in the saveXML
routine. 
Other extensions it is not a bug because non-well formed XML support is

required because the output when used in a larger context is well
formed




[2008-04-05 23:02:49] [EMAIL PROTECTED]

One more: ]]> is not allowed in CDATA blocks.

I also suspect that the other XML extensions have bugs here.



[2008-04-05 23:02:02] [EMAIL PROTECTED]

IIRC, DOM does not make any demands on names or things like that.
libxml2, which is known for its strictness, doesn't either. So, I'm
still hoping that you'll let the checks be turned off. :-)

Some things from my investigation:

- Double hyphens (--) are not allowed in comments
- Most of the text inputs don't check for UTF-8 well-formedness.
Haven't tested numeric character entities either, but those are
suspicious
- Fake namespace declarations in attributes
($d->appendChild($d->createElement('foo:bar')); results in invalid XML,
as foo namespace was never defined)

All these result in a $d->saveXML(); that is invalid XML, and probably
some more.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/44648

-- 
Edit this bug report at http://bugs.php.net/?id=44648&edit=1

#44766 [NEW]: error in prepare but mysqli_error is empty

[cap at unagon dot com]

From: cap at unagon dot com
Operating system: Redhat 3 Enterprise
PHP version:  5.2.5
PHP Bug Type: MySQLi related
Bug description:  error in prepare but mysqli_error is empty

Description:

if there is an obvious error in a prepare statement, the error is
recognized correctly but mysqli_error is the empty string

Reproduce code:
---
 $stmt=DB::$mysqli->prepare ('INSERT INTO TYPES (TYPENAME,TYPESPEC)
VALUES (?,?,ppp)');
  if (!$stmt) {throw new Exception ("Error: Prepare failed in
registerType: ".(DB::$mysqli->error));}   

Expected result:

Expecting an exception to be thrwon with a text containing some meaningful
error description

Actual result:
--
Exception is thrown, but error is empty and errno is 0.

-- 
Edit bug report at http://bugs.php.net/?id=44766&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=44766&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=44766&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=44766&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44766&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=44766&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=44766&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44766&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44766&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=44766&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44766&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=44766&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=44766&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44766&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=44766&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44766&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44766&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=44766&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=44766&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=44766&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44766&r=mysqlcfg

#44764 [Opn->Bgs]: preg_match returning empty array on certain string lengths

[felipe]

 ID:   44764
 Updated by:   [EMAIL PROTECTED]
 Reported By:  steemann at globalpark dot de
-Status:   Open
+Status:   Bogus
-Bug Type: *Regular Expressions
+Bug Type: PCRE related
 Operating System: Linux rom 2.4.21-297-smp4G
 PHP Version:  5.2.5
 New Comment:

This is expected. The reason can be known using preg_last_error(), that
in the case returns 2. (2 = PREG_BACKTRACK_LIMIT_ERROR)

http://docs.php.net/manual/en/pcre.configuration.php#ini.pcre.backtrack-limit


Previous Comments:


[2008-04-17 18:14:17] steemann at globalpark dot de

Description:

When passing somewhat long strings to the first two parameters of 
preg_match, the function result reproducibly changes to an empty 
array if the one the strings gets too long.

The reproduce code works on PHP 5.1.4 CLI, but not on PHP 5.2.4 and 
PHP 5.2.5 CLI.
When changing the string length of 1536 into 1535, the code also 
works fine in PHP 5.2.x.

This affects the seconds parameter of preg_match.

If the 1536 in the reproduce code is reduced to 1535, the code will 
work again. But if then the number of iterations in the for loop is 
changed from 64 to 65 iterations, the code will misbehave again 
(returning the empty array).

Seems to be some length overflow somewhere.


Reproduce code:
---
$parts=array();
for ($i=1;$i<=64;$i++)
{
  $parts[]="#".$i."#";
}

preg_match("/^(.*)(".implode("|",$parts).")/",$parts[0].str_repeat("
",1536),$matches);

var_dump($matches);

Expected result:

array(3) {
  [0]=>
  string(3) "#1#"
  [1]=>
  string(0) ""
  [2]=>
  string(3) "#1#"
}


Actual result:
--
array(0) {
}






-- 
Edit this bug report at http://bugs.php.net/?id=44764&edit=1

#44755 [Opn->Bgs]: Is PHP version4 coding run in PHP version 5

[derick]

 ID:   44755
 Updated by:   [EMAIL PROTECTED]
 Reported By:  himaja_mullapudi at yahoo dot co dot in
-Status:   Open
+Status:   Bogus
 Bug Type: Unknown/Other Function
 Operating System: Linux
 PHP Version:  5.2.5
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.

.


Previous Comments:


[2008-04-17 12:08:57] himaja_mullapudi at yahoo dot co dot in

Description:

Sir,
In my system i have PHP version 4 and my site is developed in PHP
version 5. Is it possible to run the old version code in new version?






-- 
Edit this bug report at http://bugs.php.net/?id=44755&edit=1

#44756 [Opn->Bgs]: Is PHP version4 coding run in PHP version 5

[derick]

 ID:   44756
 Updated by:   [EMAIL PROTECTED]
 Reported By:  himaja_mullapudi at yahoo dot co dot in
-Status:   Open
+Status:   Bogus
 Bug Type: Unknown/Other Function
 Operating System: Linux
 PHP Version:  5.2.5
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

.


Previous Comments:


[2008-04-17 12:12:26] himaja_mullapudi at yahoo dot co dot in

Description:

Sir,
In my system i have PHP version 4 and my site is developed in PHP
version 5. Is it possible to run the old version code in new version?






-- 
Edit this bug report at http://bugs.php.net/?id=44756&edit=1

#44751 [Opn->WFx]: "configure command" line in phpinfo() annoying

[derick]

 ID:   44751
 Updated by:   [EMAIL PROTECTED]
 Reported By:  eth at ethaniel dot com
-Status:   Open
+Status:   Wont fix
 Bug Type: Feature/Change Request
 Operating System: Any
 PHP Version:  5.2.5
 New Comment:

Uh, it copies and pastes just fine for me... it's exactly the same
thing that's in config.nice. I don't see how those quotes are a problem
for copy&paste at all.


Previous Comments:


[2008-04-17 07:27:02] eth at ethaniel dot com

Description:

The phpinfo() outputs a line with the "configure command" which looks
like this

'./configure' '--with-layout=GNU'
'--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all'
'--enable-libxml' '--with-libxml-dir=/usr/local' '--enable-reflection'
'--program-prefix=' '--enable-fastcgi' '--with-regex=php'
'--with-zend-vm=CALL' '--prefix=/usr/local' '--mandir=/usr/local/man'
'--infodir=/usr/local/info/'

Notice all the 's, why add them? They make it impossible to just
copy-paste this command to the command line and make any changes to it.

I propose removing those ' characters and just leave:

./configure --with-layout=GNU
--with-config-file-scan-dir=/usr/local/etc/php --disable-all
--enable-libxml --with-libxml-dir=/usr/local --enable-reflection
--program-prefix= --enable-fastcgi --with-regex=php --with-zend-vm=CALL
--prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/






-- 
Edit this bug report at http://bugs.php.net/?id=44751&edit=1

#44764 [NEW]: preg_match returning empty array on certain string lengths

[steemann at globalpark dot de]

From: steemann at globalpark dot de
Operating system: Linux rom 2.4.21-297-smp4G
PHP version:  5.2.5
PHP Bug Type: *Regular Expressions
Bug description:  preg_match returning empty array on certain string lengths

Description:

When passing somewhat long strings to the first two parameters of 
preg_match, the function result reproducibly changes to an empty 
array if the one the strings gets too long.

The reproduce code works on PHP 5.1.4 CLI, but not on PHP 5.2.4 and 
PHP 5.2.5 CLI.
When changing the string length of 1536 into 1535, the code also 
works fine in PHP 5.2.x.

This affects the seconds parameter of preg_match.

If the 1536 in the reproduce code is reduced to 1535, the code will 
work again. But if then the number of iterations in the for loop is 
changed from 64 to 65 iterations, the code will misbehave again 
(returning the empty array).

Seems to be some length overflow somewhere.


Reproduce code:
---
$parts=array();
for ($i=1;$i<=64;$i++)
{
  $parts[]="#".$i."#";
}

preg_match("/^(.*)(".implode("|",$parts).")/",$parts[0].str_repeat("
",1536),$matches);

var_dump($matches);

Expected result:

array(3) {
  [0]=>
  string(3) "#1#"
  [1]=>
  string(0) ""
  [2]=>
  string(3) "#1#"
}


Actual result:
--
array(0) {
}


-- 
Edit bug report at http://bugs.php.net/?id=44764&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=44764&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=44764&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=44764&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44764&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=44764&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=44764&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44764&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44764&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=44764&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44764&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=44764&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=44764&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44764&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=44764&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44764&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44764&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=44764&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=44764&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=44764&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44764&r=mysqlcfg

#28038 [Com]: Sent incorrect RCPT TO commands to SMTP server

[kmax at live dot com]

 ID:   28038
 Comment by:   kmax at live dot com
 Reported By:  jordi at jcanals dot net
 Status:   Open
 Bug Type: Mail related
 Operating System: win32
 PHP Version:  5CVS, 4CVS (2006-01-06) (cvs)
 New Comment:

Issalys, you fix dont work and make no sense.
My suggestion is get some free email class (like XPertMailer) and use
it instead of mail() native function.


Previous Comments:


[2008-01-13 17:31:36] issalys at hotmail dot com

hi i have de same problem and i fix it in that way:

$headers = "From: " . $fm_snd['from'] . "( Some guy)\n"; 


it work perfect :p by



Hola tuve el mismo problema y lo solucione asi 

$headers = "From: " . $fm_snd['from'] . "( quiern sea)\n"; 


funcionoo :p by



[2007-06-28 00:38:36] [EMAIL PROTECTED]

It's propably not complicated to fix but there just isn't anyone with
enough interest to do it. Feel free to provide a patch and perhaps
someone might catch on it. Or pay someone serious cash to fix it..



[2007-02-23 14:24:43] business at ziu dot de

This bug is now open since THREE YEARS. And still the version of today
(5.2.1) can not talk to SMTP servers as it should do.
This can not be so complicated to fix.



[2006-04-14 11:55:21] [EMAIL PROTECTED]

See also bug #37073



[2006-01-06 03:17:07] [EMAIL PROTECTED]

The case reported in bug #35013 should be fixed now in CVS.
(the others are NOT!)




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/28038

-- 
Edit this bug report at http://bugs.php.net/?id=28038&edit=1

#43348 [Asn]: Mail function returns true but no email sent

[RQuadling at GMail dot com]

 ID:   43348
 User updated by:  RQuadling at GMail dot com
 Reported By:  RQuadling at GMail dot com
 Status:   Assigned
 Bug Type: Mail related
 Operating System: Windows XP SP2
 PHP Version:  5.3CVS-2007-11-20 (snap)
 Assigned To:  johannes
 New Comment:

Hi.

I have finally managed to get php to compile for windows (yippee for
me).

So I can now try and get mail() working again.

The issue is that in  ext/standard/mail.c (/* $Id: mail.c,v
1.87.2.1.2.7.2.3 2007/12/31 07:17:15 sebastian Exp $ */), line 197,
the test of ...

if (!sendmail_path)

always evaluates to false when there is no sendmail_path which would
be the case on windows.

The next line differentiates between processing for windows/netware
and everything else.

If the test is

if(0 == strlen(sendmail_path))

then that would work.

The INI_STR call in Line 194 always returns a string if the directive
is known (doesn't need to be set, just has to exist as a directive).

So, I've attached a patch which I have compiled and tested on Windows.

This is in relation to bug http://bugs.php.net/bug.php?id=43348


Index: mail.c
===
RCS file: /repository/php-src/ext/standard/mail.c,v
retrieving revision 1.87.2.1.2.7.2.3
diff -u -u -r1.87.2.1.2.7.2.3 mail.c
--- mail.c  31 Dec 2007 07:17:15 -  1.87.2.1.2.7.2.3
+++ mail.c  17 Apr 2008 14:40:33 -
@@ -194,7 +194,7 @@
   char *sendmail_path = INI_STR("sendmail_path");
   char *sendmail_cmd = NULL;

-   if (!sendmail_path) {
+   if (0 == strlen(sendmail_path)) {
 #if (defined PHP_WIN32 || defined NETWARE)
   /* handle old style win smtp sending */
   if (TSendMail(INI_STR("SMTP"), &tsm_err, &tsm_errmsg,
headers,
subject, to, message, NULL, NULL, NULL TSRMLS_CC) == FAILURE) {


Previous Comments:


[2007-12-04 16:50:44] RQuadling at GMail dot com

Just to iterate, the mail function for windows in the CVS is broken for
CLI, CGI and ISAPI.



[2007-12-04 15:54:42] pipaff at comptrio dot com

Update: Switched back to CGI and mail works again... lost the ability
to 'except users' from safe_mode in Apache config
(php_admin_value/flag), but mail works.

This is on a Linux box CentOS4... 2.6.9 kernel



[2007-12-04 08:44:57] pipaff at comptrio dot com

The title caught my eye right away...

PHP 5.2.4 as DSO fails to work properly (Apache 2.0.61)

$mail = mail("[EMAIL PROTECTED]","test","test inside","From:
[EMAIL PROTECTED]");
if($mail){
print "true";
}else{
print"false";
}


Expected: "true" and an email to be received (or false without email)

Actual: "true", but no email received, no error message/log, no record
in MTA (exim)


Recently Changed: CGI to DSO, same code worked prior using same
PHP/Apache version



[2007-11-20 17:04:54] RQuadling at GMail dot com

C:\testmail.php


and then

C:\PHP4\PHP -n C:\testmail.php
I get 4.4.7-dev message

C:\PHP5\PHP -n C:\testmail.php
I get nothing.

V:\PHP5.2.2RC2-dev\PHP -n C:\testmail.php
I get 5.2.2RC2-dev message

Today, we made a change from McAfee AV to Symantec AV. I am getting
little alerts for PHP4 and the PHP5.2.2 messages going out, but nothing
for PHP5.3.0-dev



[2007-11-20 16:46:56] [EMAIL PROTECTED]

It's pretty interesting since nothing has changed in this code between
those versions. And using the older one with exactly same line works?



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/43348

-- 
Edit this bug report at http://bugs.php.net/?id=43348&edit=1

#39858 [Com]: Lost connection to MySQL server during query by a repeated call stored proced

[james dot lewis at americanmobileventures dot com]

 ID:   39858
 Comment by:   james dot lewis at americanmobileventures dot com
 Reported By:  develar at gmail dot com
 Status:   Assigned
 Bug Type: PDO related
 Operating System: Windows XP SP2
 PHP Version:  5.2.0
 Assigned To:  wez
 New Comment:

Also having this error. PHP 5.2.5 on XP SP2, with Apache2 (XAMPP 1.6.6)


Previous Comments:


[2008-04-05 21:04:45] mgrdinic at sledxchange dot com

One last thing:

It should be noted that you can "workaround" this issue by simply
instantiating a whole new PDO object after every call that returns a
result set.

// create a PDO instance up here somewhere and perform your query...

// get the return values you need...
$result = $sth->fetchAll ();

// and just create a new object...
try {
$dbh = new PDO ( $dsn, $user, $pass );
$dbh->setAttribute(PDO::MYSQL_ATTR_USE_BUFFERED_QUERY, 1);
$dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);
} catch ( PDOException $e ) {
die ( 'PDO Connection Failed: ' . $e->getMessage () );
}

// now you can query again without the error. 


It seem like the solution is simple to do. In fact, this guy seems to
be on the right track:
http://bugs.php.net/bug.php?id=42499

Why isn't this done!

Oh well, hopefully the above, if not totally wrong : ) will help
someone else.



[2008-04-05 20:53:08] mgrdinic at sledxchange dot com

Same problem here-I'm on Vista Ultimate SP1 and IIS 7 MySQL 5.0.45

The trick is regular NON-Select queries work as expected. It's when
your Stored Procedures return result sets the problems show up. 

So for example, if the first query performs a one off select and
closes, the second query is hit with the "SQLSTATE[HY000]: General
error: 2014 Cannot execute queries while other unbuffered queries are
active error". And yes, that's with using the fetchAll.

However, if I remove the select statement from the first procedure and
run the code again, both stored procedures work fine.  

I've tried the latest snap-shots, but unfortunately I couldn't get pdo
to even load. Any ideas? Updates?



[2008-04-05 16:56:25] php at pofik dot com

Hi there - so is there a proper fix for this by now? I just started
using stored procedures more extensively and I am now hit by this bug
all the time (Windows XP SP2, MySQL 5.0.51a, PHP 5.2.1)! Apparently this
bug is a known problem since at least October 2005 (Bug #5827), so I'd
think this should be long fixed?? However, I cannot locate any
information on a proper fix except for a bunch of makeshift workarounds
(using ODBC, abandoning the connection on HY000 etc.), and tons of
people complaining about it not being fixed. 

Considering how long this bug is known and open, it would help if
someone could post some update. This issue is really really annoying.

Thanks!



[2008-02-07 12:57:17] kraus at phoenix-medien dot de

This PDO bug makes it impossible to install Magento on Windows
platforms. See
http://www.magentocommerce.com/wiki/general/installing_on_windows_with_xampp_and_wamp
for further information.



[2007-12-17 08:33:59] poon dot fung at gmail dot com

Same problem presist on Windows XP with PHP v5.2.5. Again, here is the
error message. When a query is executed after calling a stored
procedure.

code: HY000, msg: Cannot execute queries while other unbuffered queries
are active.  Consider using PDOStatement::fetchAll().  Alternatively, if
your code is only ever going to run against mysql, you may enable query
buffering by setting the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/39858

-- 
Edit this bug report at http://bugs.php.net/?id=39858&edit=1

#44762 [NEW]: DOMElement need a innerHTML

[xwisdom at yahoo dot com]

From: xwisdom at yahoo dot com
Operating system: Windows XP
PHP version:  5.2.5
PHP Bug Type: Feature/Change Request
Bug description:  DOMElement need a innerHTML

Description:

I would like to request that a innerHTML property (or method) be added to
DOMElement class. This would make it so much easier to retrieve and set the
html or xml content of a node.

Right now we have to use fragments with several lines of to get the job
done. It would be so much better to be able to do it in one line of code
:)






-- 
Edit bug report at http://bugs.php.net/?id=44762&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=44762&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=44762&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=44762&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44762&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=44762&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=44762&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44762&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44762&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=44762&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44762&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=44762&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=44762&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44762&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=44762&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44762&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44762&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=44762&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=44762&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=44762&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44762&r=mysqlcfg

#44761 [NEW]: DOM & Large Files

[xwisdom at yahoo dot com]

From: xwisdom at yahoo dot com
Operating system: Windows XP
PHP version:  5.2.5
PHP Bug Type: Feature/Change Request
Bug description:  DOM & Large Files 

Description:

I think the (X)HTML DOM features are great but I would like for it to
process the DOMDocument much faster.

It appears that the HTML DOM features in php are not able to handle large
html files (200k+). It's slow down when processing these files.

I would like to request that the DOM processing objects be given a speed
boost. The DOM that's present in the browsers are much faster at processing
the element. If this can be done then it would be great!






-- 
Edit bug report at http://bugs.php.net/?id=44761&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=44761&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=44761&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=44761&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44761&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=44761&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=44761&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44761&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44761&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=44761&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44761&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=44761&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=44761&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44761&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=44761&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44761&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44761&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=44761&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=44761&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=44761&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44761&r=mysqlcfg

#44760 [NEW]: The info test page works once, then fails.

[ahorwitz at numoda dot com]

From: ahorwitz at numoda dot com
Operating system: XP
PHP version:  5.2.5
PHP Bug Type: IIS related
Bug description:  The info test page works once, then fails.

Description:

Trying to install PHP 5 on XP with IIS. The following page runs once, then
fails when refresh is clicked. If I close the browser and try the page
again, the page loads once, then fails on refresh.

Reproduce code:
---


  
PHP Test
  
  

  The browser you're using is 
  


  
  Your browser's capabilities are: 
  

  


  



Expected result:

It should work more than once without closing and opening my web browser.

Actual result:
--
Page just attempts to load.

-- 
Edit bug report at http://bugs.php.net/?id=44760&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=44760&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=44760&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=44760&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44760&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=44760&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=44760&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44760&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44760&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=44760&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44760&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=44760&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=44760&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44760&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=44760&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44760&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44760&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=44760&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=44760&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=44760&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44760&r=mysqlcfg

#44758 [NEW]: msession invalid configure option

[denis at edistar dot com]

From: denis at edistar dot com
Operating system: Linux
PHP version:  5.2.5
PHP Bug Type: *Compile Issues
Bug description:  msession invalid configure option

Description:

I'm trying to compile php with msession support.
Configure fails with the following message:

Notice: Following unknown configure options were used:

--with-msession

Check './configure --help' for available options


Reproduce code:
---
./configure --with-msession

Expected result:

No warnings should be generated.

Actual result:
--
Notice: Following unknown configure options were used:

--with-msession

Check './configure --help' for available options


-- 
Edit bug report at http://bugs.php.net/?id=44758&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=44758&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=44758&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=44758&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44758&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=44758&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=44758&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44758&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44758&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=44758&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44758&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=44758&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=44758&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44758&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=44758&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44758&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44758&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=44758&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=44758&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=44758&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44758&r=mysqlcfg

#44745 [Opn]: child pid 913624 exit signal Segmentation fault (11)

[mssanch2002 at yahoo dot com]

 ID:   44745
 User updated by:  mssanch2002 at yahoo dot com
 Reported By:  mssanch2002 at yahoo dot com
 Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: aix 5.3
 PHP Version:  4.4.8
 New Comment:

I'm also getting these warning when I run the make.

/macs/php-4.4.8/ext/standard/info.c: In function
'php_info_write_wrapper':
/macs/php-4.4.8/ext/standard/info.c:69: warning: pointer targets in
passing argu
ment 1 of 'php_escape_html_entities' differ in signedness
/macs/php-4.4.8/ext/standard/info.c: In function 'php_info_html_esc':
/macs/php-4.4.8/ext/standard/info.c:216: warning: pointer targets in
passing arg
ument 1 of 'php_escape_html_entities' differ in signedness
/macs/php-4.4.8/ext/standard/info.c: In function 'php_print_info':
/macs/php-4.4.8/ext/standard/info.c:506: warning: pointer targets in
passing arg
ument 3 of 'zend_hash_get_current_key_ex' differ in signedness
/macs/php-4.4.8/ext/standard/info.c: At top level:
/macs/php-4.4.8/TSRM/tsrm_virtual_cwd.h:166: warning:
'php_realpath_hack' define
d but not used


Previous Comments:


[2008-04-16 18:26:40] mssanch2002 at yahoo dot com

PHP was configured with the following:

./configure  --with-oci8 --without-mysql --with-apache=../apache
--enable-debug



[2008-04-16 17:21:10] mssanch2002 at yahoo dot com

Description:

I configure apache 1.4.41 with the following config:

/configure --with-layout=Apache --prefix=/macs/apache
--activate-module=src/modules/php4/libphp4.a

I receive the following message in apache error_log when I use the
browser:

child pid 913624 exit signal Segmentation fault (11)



Actual result:
--
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "powerpc-ibm-aix5.1.0.0"...
(no debugging symbols found)...
(gdb) run -X
Starting program: /macs/apache_1.3.41/bin/httpd -X

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1]
0x1007de4c in ?? ()
(gdb) bt
#0  0x1007de4c in ?? ()
(gdb)





-- 
Edit this bug report at http://bugs.php.net/?id=44745&edit=1

#44757 [NEW]: use sql-id as key

[nobs at nobswolf dot info]

From: nobs at nobswolf dot info
Operating system: 
PHP version:  5.2.5
PHP Bug Type: Feature/Change Request
Bug description:  use sql-id as key

Description:

Let functions like pg_fetch_all use one column of the result set (most
likely the primary key or another unique key) as key of the PHP-array.

Reproduce code:
---
// this is what I currently use

$ergebnis= pg_fetch_all($resultset);

foreach ($ergebnis as $row){
  $text[$row['id']] = $row['text'];
}

// this is what I would like to have

$textA= pg_fetch_all($resultset, 'id');

// just for convenience, readability and performance


-- 
Edit bug report at http://bugs.php.net/?id=44757&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=44757&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=44757&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=44757&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44757&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=44757&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=44757&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44757&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44757&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=44757&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44757&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=44757&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=44757&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44757&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=44757&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44757&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44757&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=44757&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=44757&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=44757&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44757&r=mysqlcfg

#44756 [NEW]: Is PHP version4 coding run in PHP version 5

[himaja_mullapudi at yahoo dot co dot in]

From: himaja_mullapudi at yahoo dot co dot in
Operating system: Linux
PHP version:  5.2.5
PHP Bug Type: Unknown/Other Function
Bug description:  Is PHP version4 coding run in PHP version 5

Description:

Sir,
In my system i have PHP version 4 and my site is developed in PHP version
5. Is it possible to run the old version code in new version?


-- 
Edit bug report at http://bugs.php.net/?id=44756&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=44756&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=44756&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=44756&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44756&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=44756&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=44756&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44756&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44756&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=44756&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44756&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=44756&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=44756&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44756&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=44756&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44756&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44756&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=44756&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=44756&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=44756&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44756&r=mysqlcfg

#44755 [NEW]: Is PHP version4 coding run in PHP version 5

[himaja_mullapudi at yahoo dot co dot in]

From: himaja_mullapudi at yahoo dot co dot in
Operating system: Linux
PHP version:  5.2.5
PHP Bug Type: Unknown/Other Function
Bug description:  Is PHP version4 coding run in PHP version 5

Description:

Sir,
In my system i have PHP version 4 and my site is developed in PHP version
5. Is it possible to run the old version code in new version?


-- 
Edit bug report at http://bugs.php.net/?id=44755&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=44755&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=44755&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=44755&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44755&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=44755&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=44755&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44755&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44755&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=44755&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44755&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=44755&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=44755&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44755&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=44755&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44755&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44755&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=44755&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=44755&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=44755&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44755&r=mysqlcfg

#44594 [Opn->Csd]: unsigned long passed as $n_retries argument to imap_open()

[felipe]

 ID:   44594
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: IMAP related
 Operating System: Windows XP
 PHP Version:  5.2CVS-2008-04-01 (snap)
 Assigned To:  iliaa
 New Comment:

Hi Josie, i have fixed a typo in the fix.


Thanks.


Previous Comments:


[2008-04-17 08:47:50] [EMAIL PROTECTED]

I'm still having this problem with the most recent snapshot



[2008-04-02 16:32:08] [EMAIL PROTECTED]

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.





[2008-04-01 15:54:57] [EMAIL PROTECTED]

Description:

When a negative integer is passed as the $n_retries argument to
imap_open(), the number is passed as a signed long to the c-client
function mail_parameters(), which is expecting an unsigned long to be
passed on a SET_MAXLOGINTRIALS call. This results in $n_retries being
set to a huge number. The problem is the the function php_imap_do_open()
in ext/imap/php_imap.c. 
Below is a patch written by Andy Wharmby (CVS ID wharmby), it returns a
warning if $n_retries is less than 0:
The code as it stands is: 

#ifdef SET_MAXLOGINTRIALS
if (myargc == 5) {
convert_to_long_ex(retries);
mail_parameters(NIL, SET_MAXLOGINTRIALS, (void *)
Z_LVAL_PP(retries));
}
#endif

SOLUTION:


#ifdef SET_MAXLOGINTRIALS
if (myargc == 5) {
convert_to_long_ex(retries);

if (retries < 1) { 
php_error_docref(NULL TSRMLS_CC, E_WARNING ,"Retries 
cannot be less
than 1");
RETURN_FALSE;
} 

mail_parameters(NIL, SET_MAXLOGINTRIALS, (void *)
Z_LVAL_PP(retries));
}
#endif

The documentation for the $n_retries argument also says that the number
passed is "Number of maximum connect attempts" which is incorrect. There
is always one attempt to connect, if that fails then $n_retries sets how
many more attempts are made *after* the initial attempt.

Reproduce code:
---







-- 
Edit this bug report at http://bugs.php.net/?id=44594&edit=1

#44749 [Opn]: FastCGI problems during large HTTP Posts (corruption or hang)

[eth at ethaniel dot com]

 ID:   44749
 User updated by:  eth at ethaniel dot com
 Reported By:  eth at ethaniel dot com
 Status:   Open
 Bug Type: CGI related
 Operating System: Freebsd 7.0
 PHP Version:  5.2.5
 New Comment:

server.network-backend = "write" started causing some strange "resource
unavailable" errors in the error log, so I changed it to

server.network-backend = "writev" and everything went back to normal.


Previous Comments:


[2008-04-17 08:58:15] eth at ethaniel dot com

Seems like the problem was in lighttpd.

Setting server.network-backend = "write" in lighttpd.conf solved the
problem.



[2008-04-16 21:31:05] eth at ethaniel dot com

Description:

I use Freebsd 7.0 with lighttpd 1.4.19 and php-cgi 5.2.5 (with suhosin
patch).

I noticed, that when I do a large upload (1.2 megabytes) php works
unadequately: randomly it either corrupts the upload or just freezes.

So for instance, if I run php-cgi on a tcp port (1026) it successfully
accepts all uploads that are given to it from lighttpd and processes
them through the script. But randomly (sometimes several times in a row,
sometimes one out of 10 requests) it corrupts the post data (several
bytes in the center of the 1.2 megabyte block get corrupted - replaced
with 00 00 00 hex values). Nothing freezes at this configuration.

If I run php-cgi as a unix socket (/tmp/php.sock) it either accepts the
upload (and never shows any sign of corruption, all data is processed
normally), or just halts and leaves the connection open (doesn't reply
to the current and any new connections either).
Sometimes it just unfreezes after a while and starts accepting new
connections, sometimes I just have to respawn php-cgi.

My best guess is that it might have something to do with the freebsd
7.0 socket handling. Maybe not - maybe it really is a bug in php-cgi.

I checked - lighttpd has all the uploaded files uncorrupted. The bad
things start happening somewhere between lighttpd and fastcgi php.

Reproduce code:
---
Here is the command I use to make the upload from the remote host.

curl -vv -# -s -F "[EMAIL PROTECTED]" -H "Host: upload.host.ru" -H
"Expect:" -H "Content-Type:" -0 1.1.1.1:200/testupload.php

Note the empty Content-type - once I noticed the corruption, I decided
to make a test and debug HTTP_RAW_POST_DATA by hand. The corruption was
all the way up there.

Expected result:

The testupload.php script checks the HTTP_RAW_POST_DATA, extracts the
uploaded files from mime headers and checks it's md5 value. If MD5 is
incorrect, it logs the uploaded file and then I compare it to the normal
sample.

Actual result:
--
Nothing here.





-- 
Edit this bug report at http://bugs.php.net/?id=44749&edit=1

#42060 [Opn]: [PATCH] Add pagedResults support and more (PAT18 and PAT19 updated for 5.2.3)

[jani]

 ID:   42060
 Updated by:   [EMAIL PROTECTED]
 Reported By:  iarenuno at eteo dot mondragon dot edu
 Status:   Open
 Bug Type: LDAP related
-Operating System: Any
+Operating System: *
-PHP Version:  5.2.3
+PHP Version:  5.2.5
 New Comment:

I'm too busy at work right now, and since I don't use LDAP stuff for
anything anymore (or at least right now :), I'm not really keen on just
applying the patch. I hope someone else with more time could look into
this.


Previous Comments:


[2008-04-17 08:33:51] dan dot marsden at gmail dot com

..ignore that last comment - I can see in the php mailing lists that
Jani is in fact still around! - cool! - Jani? - any possibility you
might be able to re-look at this? - or at least tell us what you need to
allow it to be fixed?

thanks!

:-)

Dan



[2007-11-21 11:33:02] avel+php at noc dot uoa dot gr

I intend to write a wrapper function for PEAR::Pager and LDAP, to make
paged results more accessible.

Without this patch, paged results from LDAP are not possible. [Well,
they _are_ possible, if one loads the entire result set in memory. :-| 
]

How come is this patch's status "No Feedback"? What is the PHP
developers' stand on this patch as of now?

Alexandros Vellis



[2007-09-24 12:58:06] avel+php at noc dot uoa dot gr

This is a _killer_ feature that we have been waiting for a long time. 
White pages apps written in PHP, with large directories behind them,
desparetely need the paging feature -- and not only them!

The API seems intuitive to me so far. I'm eager for this to be included
in PHP 5.3.

Thanks for the patch.

Alexandros Vellis



[2007-09-07 18:40:25] ando at sys-net dot it

A working patch with test examples lined up to HEAD as of 5 minutes ago
is available here



I'm the original developer, and I'm willing to cooperate in integrating
it, if needed.  So you can re-open the bug now.

p.



[2007-09-07 14:59:29] ando at sys-net dot it

Yes, so many functions are needed to support generic stuff + dozens of
well-known, RFC/I.D. based LDAP controls and extended operations,
without code duplication.  Any developer would agree.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/42060

-- 
Edit this bug report at http://bugs.php.net/?id=42060&edit=1

#42060 [NoF->Opn]: [PATCH] Add pagedResults support and more (PAT18 and PAT19 updated for 5.2.3)

[jani]

 ID:   42060
 Updated by:   [EMAIL PROTECTED]
 Reported By:  iarenuno at eteo dot mondragon dot edu
-Status:   No Feedback
+Status:   Open
 Bug Type: LDAP related
 Operating System: Any
 PHP Version:  5.2.3
 Assigned To:  jani


Previous Comments:


[2008-04-17 08:33:51] dan dot marsden at gmail dot com

..ignore that last comment - I can see in the php mailing lists that
Jani is in fact still around! - cool! - Jani? - any possibility you
might be able to re-look at this? - or at least tell us what you need to
allow it to be fixed?

thanks!

:-)

Dan



[2008-04-17 08:21:49] dan dot marsden at gmail dot com

... I wonder if the reason that this bug hasn't had any traction is
because "jani" is no longer a PHP developer? - maybe we need to create a
"new" bug and link to this one to get it noticed by the Dev team?

:-)

Dan



[2007-11-21 11:33:02] avel+php at noc dot uoa dot gr

I intend to write a wrapper function for PEAR::Pager and LDAP, to make
paged results more accessible.

Without this patch, paged results from LDAP are not possible. [Well,
they _are_ possible, if one loads the entire result set in memory. :-| 
]

How come is this patch's status "No Feedback"? What is the PHP
developers' stand on this patch as of now?

Alexandros Vellis



[2007-09-24 12:58:06] avel+php at noc dot uoa dot gr

This is a _killer_ feature that we have been waiting for a long time. 
White pages apps written in PHP, with large directories behind them,
desparetely need the paging feature -- and not only them!

The API seems intuitive to me so far. I'm eager for this to be included
in PHP 5.3.

Thanks for the patch.

Alexandros Vellis



[2007-09-07 18:40:25] ando at sys-net dot it

A working patch with test examples lined up to HEAD as of 5 minutes ago
is available here



I'm the original developer, and I'm willing to cooperate in integrating
it, if needed.  So you can re-open the bug now.

p.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/42060

-- 
Edit this bug report at http://bugs.php.net/?id=42060&edit=1

#44752 [Opn->Bgs]: Crash with new DateTimeZone(null)

[felipe]

 ID:   44752
 Updated by:   [EMAIL PROTECTED]
 Reported By:  daniel dot oconnor at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Date/time related
 Operating System: Windows XP
 PHP Version:  5.2.5
 New Comment:

Output using 5.2.6:

object(DateTimeZone)#1 (0) {
}

Warning: timezone_open(): Unknown or bad timezone () in ...
bool(false)

Warning: timezone_open(): Unknown or bad timezone () in ...
bool(false)
object(DateTimeZone)#1 (0) {
}

Fatal error: Uncaught exception 'Exception' with message
'DateTimeZone::__construct(): Unknown or bad timezone ()' in ...
Stack trace:
#0 ...(17): DateTimeZone->__construct('')
#1 {main}
  thrown in ...


Then, it looks has been fixed.


Previous Comments:


[2008-04-17 08:06:51] daniel dot oconnor at gmail dot com

Description:

new DateTimeZone crashes apache when given something it can't
recognize.

timezone_open is more robust

This has similar symptoms to Bug #43377 ; but is probably different

Reproduce code:
---
http://bugs.php.net/?id=44752&edit=1

#44754 [NEW]: Calling a bad eval() and then include(), resets $_REQUEST

[famzah at icdsoft dot com]

From: famzah at icdsoft dot com
Operating system: Linux
PHP version:  5.2.5
PHP Bug Type: Variables related
Bug description:  Calling a bad eval() and then include(), resets $_REQUEST

Description:

If you modify an element of $_REQUEST, then call eval() with some syntax
error, and then include() or require() another file, the changes in
$_REQUEST are reset to the original values of $_REQUEST at script's startup
time. The changes in $_REQUEST are permanently lost and the include()'d
file as well as the main PHP file then operate with the reset $_REQUEST
values.

Reproduce code:
---
* Proof of concept:

PHP 5.2.5 (bug):
http://famzah.net/evalbug/index.php?test=abcdef

PHP 4.4.8 (no bug):
http://famzah.net/evalbug/index.php4?test=abcdef

* Source code:

PHP 5.2.5 (bug):
http://famzah.net/evalbug/index.txt

PHP 4.4.8 (no bug):
http://famzah.net/evalbug/index4.txt


Expected result:

The expected behavior is that after the modification of an element in
$_REQUEST, all included files as well as the main PHP file must operate
with the modified values of $_REQUEST, because this is a super-global
variable.

The above is currently true for all cases except when an eval() call is
made which contains a syntax error. For example:
eval('this is a syntax error');

I reproduced the bug using the following PHP versions:
PHP 5.2.5 (cli), Zend Engine v2.2.0
PHP 5.2.5-3 with Suhosin-Patch 0.9.6.2 (cli), Zend Engine v2.2.0

The following PHP4 version does NOT have the bug:
PHP 4.4.8 (cli), Zend Engine v1.3.0

Actual result:
--
The bug situation is as follows:
- We call "index.php" with a GET parameter ?test=abcdef
- The script does and outputs the following:
index.php: $_REQUEST value is: abcdef
index.php: Modifying $_REQUEST by setting key 'test' to 'zzz'
index.php: $_REQUEST value is: zzz
index.php: Calling eval() with no syntax error.
index.php: Including the 'dump.php' file...
dump.php: $_REQUEST value is: zzz
index.php: $_REQUEST value is: zzz
index.php: Calling eval() with a syntax error.
index.php: $_REQUEST value is: zzz
index.php: Including the 'dump.php' file...
dump.php: $_REQUEST value is: abcdef
index.php: $_REQUEST value is: abcdef

The last two lines must contain the value 'zzz', not 'abcdef'.

-- 
Edit bug report at http://bugs.php.net/?id=44754&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=44754&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=44754&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=44754&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44754&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=44754&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=44754&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44754&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44754&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=44754&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44754&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=44754&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=44754&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44754&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=44754&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44754&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44754&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=44754&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=44754&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=44754&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44754&r=mysqlcfg

#44546 [Asn->Csd]: crash with SplHeap::next()

[dmitry]

 ID:   44546
 Updated by:   [EMAIL PROTECTED]
 Reported By:  l dot alberton at quipo dot it
-Status:   Assigned
+Status:   Closed
 Bug Type: SPL related
 Operating System: Windows
 PHP Version:  5.3CVS-2008-03-27 (snap)
 Assigned To:  dmitry
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2008-04-02 09:40:36] [EMAIL PROTECTED]

Same as bug #44226




[2008-03-29 06:25:34] l dot alberton at quipo dot it

It might be the case that the bug isn't in SplHeap::next() after all,
that's just the way I experienced it. This might be a dupe of 

http://bugs.php.net/bug.php?id=44226



[2008-03-28 16:06:29] [EMAIL PROTECTED]

Your build/snapshot appears to be broken, I can't find anyone except
you that can reproduce it under windows.

Please try to run the complete test suite so you can see whether you
find other crashes



[2008-03-28 11:30:44] l dot alberton at quipo dot it

I think I have a better reproducing script:

=

$pqueue = new SplPriorityQueue();
$pqueue->insert('a', 1);
$pqueue->insert('b', 2);

try {
echo $pqueue->extract();
echo $pqueue->extract();
echo $pqueue->extract();
} catch (RuntimeException $e) {
echo "\nERROR: ".$e->getMessage();
}

=

Here, I insert 2 elements in the queue, and try to extract 3 elements.
The last extract() call should trigger a RuntimeException, and this is
the case when running the script from the command line. When running it
in a web browser, Apache crashes.

HTH



[2008-03-27 18:47:28] l dot alberton at quipo dot it

I have no idea. Nevertheless, that's the way I experienced the crash,
and without calling next() everything was fine.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/44546

-- 
Edit this bug report at http://bugs.php.net/?id=44546&edit=1

#44546 [Bgs->Asn]: crash with SplHeap::next()

[dmitry]

 ID:   44546
 Updated by:   [EMAIL PROTECTED]
 Reported By:  l dot alberton at quipo dot it
-Status:   Bogus
+Status:   Assigned
 Bug Type: SPL related
 Operating System: Windows
 PHP Version:  5.3CVS-2008-03-27 (snap)
-Assigned To:  
+Assigned To:  dmitry


Previous Comments:


[2008-04-02 09:40:36] [EMAIL PROTECTED]

Same as bug #44226




[2008-03-29 06:25:34] l dot alberton at quipo dot it

It might be the case that the bug isn't in SplHeap::next() after all,
that's just the way I experienced it. This might be a dupe of 

http://bugs.php.net/bug.php?id=44226



[2008-03-28 16:06:29] [EMAIL PROTECTED]

Your build/snapshot appears to be broken, I can't find anyone except
you that can reproduce it under windows.

Please try to run the complete test suite so you can see whether you
find other crashes



[2008-03-28 11:30:44] l dot alberton at quipo dot it

I think I have a better reproducing script:

=

$pqueue = new SplPriorityQueue();
$pqueue->insert('a', 1);
$pqueue->insert('b', 2);

try {
echo $pqueue->extract();
echo $pqueue->extract();
echo $pqueue->extract();
} catch (RuntimeException $e) {
echo "\nERROR: ".$e->getMessage();
}

=

Here, I insert 2 elements in the queue, and try to extract 3 elements.
The last extract() call should trigger a RuntimeException, and this is
the case when running the script from the command line. When running it
in a web browser, Apache crashes.

HTH



[2008-03-27 18:47:28] l dot alberton at quipo dot it

I have no idea. Nevertheless, that's the way I experienced the crash,
and without calling next() everything was fine.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/44546

-- 
Edit this bug report at http://bugs.php.net/?id=44546&edit=1

#44226 [Asn->Csd]: Throwing an exception causes crash

[dmitry]

 ID:   44226
 Updated by:   [EMAIL PROTECTED]
 Reported By:  james dot j dot hackett at gmail dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: Reproducible crash
 Operating System: linux debian 2.6.18-5-686
 PHP Version:  5.3CVS-2008-02-23 (snap)
 Assigned To:  dmitry
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2008-04-17 01:00:01] 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".



[2008-04-15 20:04:59] l dot alberton at quipo dot it

I can reproduce this bug as well. I first thought it was a SPL problem,
but it happens whenever an exception is thrown. Apache 2.2 handler, win
XP. I posted a trace here:
http://bugs.php.net/bug.php?id=44546

PS: cli is ok, no bug there.



[2008-04-09 22:02:49] mageofchrisz at gmail dot com

Hi,

I'm also having this problem but I'm not sure what type of information
I can provide that will aide in reproducing the crash. A simple snippet
of "throw new Exception('Hello, Crash!');" causes Apache 2.2.8 to
restart all its threads.

I'm not sure what I can do to help or provide more information. It's XP
SP2 (all latest updates, ie6) on a windows domain. It's an Intel Pentium
D 3.4GHz, 4GiB of RAM installed but only utilizes 3.25 of it.

Apache 2.2.8 runs with mod_ssl/2.2.8 OpenSSL/0.9.8g.

If there's any more information I can provide please let me know. I've
been trying to take the time to figure out how to compile a debug build
but i've been busy with work-related stuff.



[2008-04-09 08:59:17] [EMAIL PROTECTED]

Not reproducible.
Both CLI(w/ and w/o ZTS enabled) and Apache2(prefork) work just fine,
valgrind keeps silence.
Need more details to be able to reproduce it.



[2008-03-31 21:29:53] ghurtado at gmail dot com

I experience the same exact problem on Windows XP SP2. Throwing any PHP
Exception causes Apache 2.0.63 to crash, presumably due to a PHP process
crash. I am using the latest snapshot of PHP 5.3 as of 3/31/2008. This
same behaviour is also present in Apache 2.2.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/44226

-- 
Edit this bug report at http://bugs.php.net/?id=44226&edit=1

#44226 [NoF->Asn]: Throwing an exception causes crash

[dmitry]

 ID:   44226
 Updated by:   [EMAIL PROTECTED]
 Reported By:  james dot j dot hackett at gmail dot com
-Status:   No Feedback
+Status:   Assigned
 Bug Type: Reproducible crash
 Operating System: linux debian 2.6.18-5-686
 PHP Version:  5.3CVS-2008-02-23 (snap)
-Assigned To:  
+Assigned To:  dmitry


Previous Comments:


[2008-04-17 01:00:01] 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".



[2008-04-15 20:04:59] l dot alberton at quipo dot it

I can reproduce this bug as well. I first thought it was a SPL problem,
but it happens whenever an exception is thrown. Apache 2.2 handler, win
XP. I posted a trace here:
http://bugs.php.net/bug.php?id=44546

PS: cli is ok, no bug there.



[2008-04-09 22:02:49] mageofchrisz at gmail dot com

Hi,

I'm also having this problem but I'm not sure what type of information
I can provide that will aide in reproducing the crash. A simple snippet
of "throw new Exception('Hello, Crash!');" causes Apache 2.2.8 to
restart all its threads.

I'm not sure what I can do to help or provide more information. It's XP
SP2 (all latest updates, ie6) on a windows domain. It's an Intel Pentium
D 3.4GHz, 4GiB of RAM installed but only utilizes 3.25 of it.

Apache 2.2.8 runs with mod_ssl/2.2.8 OpenSSL/0.9.8g.

If there's any more information I can provide please let me know. I've
been trying to take the time to figure out how to compile a debug build
but i've been busy with work-related stuff.



[2008-04-09 08:59:17] [EMAIL PROTECTED]

Not reproducible.
Both CLI(w/ and w/o ZTS enabled) and Apache2(prefork) work just fine,
valgrind keeps silence.
Need more details to be able to reproduce it.



[2008-03-31 21:29:53] ghurtado at gmail dot com

I experience the same exact problem on Windows XP SP2. Throwing any PHP
Exception causes Apache 2.0.63 to crash, presumably due to a PHP process
crash. I am using the latest snapshot of PHP 5.3 as of 3/31/2008. This
same behaviour is also present in Apache 2.2.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/44226

-- 
Edit this bug report at http://bugs.php.net/?id=44226&edit=1

#44749 [Opn]: FastCGI problems during large HTTP Posts (corruption or hang)

[eth at ethaniel dot com]

 ID:   44749
 User updated by:  eth at ethaniel dot com
 Reported By:  eth at ethaniel dot com
 Status:   Open
 Bug Type: CGI related
 Operating System: Freebsd 7.0
 PHP Version:  5.2.5
 New Comment:

Seems like the problem was in lighttpd.

Setting server.network-backend = "write" in lighttpd.conf solved the
problem.


Previous Comments:


[2008-04-16 21:31:05] eth at ethaniel dot com

Description:

I use Freebsd 7.0 with lighttpd 1.4.19 and php-cgi 5.2.5 (with suhosin
patch).

I noticed, that when I do a large upload (1.2 megabytes) php works
unadequately: randomly it either corrupts the upload or just freezes.

So for instance, if I run php-cgi on a tcp port (1026) it successfully
accepts all uploads that are given to it from lighttpd and processes
them through the script. But randomly (sometimes several times in a row,
sometimes one out of 10 requests) it corrupts the post data (several
bytes in the center of the 1.2 megabyte block get corrupted - replaced
with 00 00 00 hex values). Nothing freezes at this configuration.

If I run php-cgi as a unix socket (/tmp/php.sock) it either accepts the
upload (and never shows any sign of corruption, all data is processed
normally), or just halts and leaves the connection open (doesn't reply
to the current and any new connections either).
Sometimes it just unfreezes after a while and starts accepting new
connections, sometimes I just have to respawn php-cgi.

My best guess is that it might have something to do with the freebsd
7.0 socket handling. Maybe not - maybe it really is a bug in php-cgi.

I checked - lighttpd has all the uploaded files uncorrupted. The bad
things start happening somewhere between lighttpd and fastcgi php.

Reproduce code:
---
Here is the command I use to make the upload from the remote host.

curl -vv -# -s -F "[EMAIL PROTECTED]" -H "Host: upload.host.ru" -H
"Expect:" -H "Content-Type:" -0 1.1.1.1:200/testupload.php

Note the empty Content-type - once I noticed the corruption, I decided
to make a test and debug HTTP_RAW_POST_DATA by hand. The corruption was
all the way up there.

Expected result:

The testupload.php script checks the HTTP_RAW_POST_DATA, extracts the
uploaded files from mime headers and checks it's md5 value. If MD5 is
incorrect, it logs the uploaded file and then I compare it to the normal
sample.

Actual result:
--
Nothing here.





-- 
Edit this bug report at http://bugs.php.net/?id=44749&edit=1

#44594 [Csd->Opn]: unsigned long passed as $n_retries argument to imap_open()

[jmessa]

 ID:   44594
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Closed
+Status:   Open
 Bug Type: IMAP related
 Operating System: Windows XP
 PHP Version:  5.2CVS-2008-04-01 (snap)
 Assigned To:  iliaa
 New Comment:

I'm still having this problem with the most recent snapshot


Previous Comments:


[2008-04-02 16:32:08] [EMAIL PROTECTED]

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.





[2008-04-01 15:54:57] [EMAIL PROTECTED]

Description:

When a negative integer is passed as the $n_retries argument to
imap_open(), the number is passed as a signed long to the c-client
function mail_parameters(), which is expecting an unsigned long to be
passed on a SET_MAXLOGINTRIALS call. This results in $n_retries being
set to a huge number. The problem is the the function php_imap_do_open()
in ext/imap/php_imap.c. 
Below is a patch written by Andy Wharmby (CVS ID wharmby), it returns a
warning if $n_retries is less than 0:
The code as it stands is: 

#ifdef SET_MAXLOGINTRIALS
if (myargc == 5) {
convert_to_long_ex(retries);
mail_parameters(NIL, SET_MAXLOGINTRIALS, (void *)
Z_LVAL_PP(retries));
}
#endif

SOLUTION:


#ifdef SET_MAXLOGINTRIALS
if (myargc == 5) {
convert_to_long_ex(retries);

if (retries < 1) { 
php_error_docref(NULL TSRMLS_CC, E_WARNING ,"Retries 
cannot be less
than 1");
RETURN_FALSE;
} 

mail_parameters(NIL, SET_MAXLOGINTRIALS, (void *)
Z_LVAL_PP(retries));
}
#endif

The documentation for the $n_retries argument also says that the number
passed is "Number of maximum connect attempts" which is incorrect. There
is always one attempt to connect, if that fails then $n_retries sets how
many more attempts are made *after* the initial attempt.

Reproduce code:
---







-- 
Edit this bug report at http://bugs.php.net/?id=44594&edit=1

#44096 [Com]: iconv: wrong charset

[i dot pavlov at korekom dot net]

 ID:   44096
 Comment by:   i dot pavlov at korekom dot net
 Reported By:  cpuidle at gmx dot de
 Status:   No Feedback
 Bug Type: ICONV related
 Operating System: WinXP
 PHP Version:  5.2.5
 New Comment:

The same thing here. But the problem is far from Windows-specific.
Debian based system in my case.
No usefull info found for now.


Previous Comments:


[2008-02-25 01:31:35] [EMAIL PROTECTED]

Weird Windows-specific thing.  The test case works fine on 6 different
UNIX variants I just tried it on.



[2008-02-24 23:45:29] darop68 at poczta dot onet dot pl

I have the same problem in php 5.2.5.
My code:
iconv('iso-8859-2', 'utf-8', 'test');



[2008-02-22 01:00:00] 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".



[2008-02-14 22:45:38] [EMAIL PROTECTED]

Another reason for this is that those encodings just don't exist on
your platform. The code works fine for me on Linux..



[2008-02-13 19:01:42] cpuidle at gmx dot de

See test case- file is ansi, not even any complex characters?



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/44096

-- 
Edit this bug report at http://bugs.php.net/?id=44096&edit=1

#42060 [Com]: [PATCH] Add pagedResults support and more (PAT18 and PAT19 updated for 5.2.3)

[dan dot marsden at gmail dot com]

 ID:   42060
 Comment by:   dan dot marsden at gmail dot com
 Reported By:  iarenuno at eteo dot mondragon dot edu
 Status:   No Feedback
 Bug Type: LDAP related
 Operating System: Any
 PHP Version:  5.2.3
 Assigned To:  jani
 New Comment:

..ignore that last comment - I can see in the php mailing lists that
Jani is in fact still around! - cool! - Jani? - any possibility you
might be able to re-look at this? - or at least tell us what you need to
allow it to be fixed?

thanks!

:-)

Dan


Previous Comments:


[2008-04-17 08:21:49] dan dot marsden at gmail dot com

... I wonder if the reason that this bug hasn't had any traction is
because "jani" is no longer a PHP developer? - maybe we need to create a
"new" bug and link to this one to get it noticed by the Dev team?

:-)

Dan



[2007-11-21 11:33:02] avel+php at noc dot uoa dot gr

I intend to write a wrapper function for PEAR::Pager and LDAP, to make
paged results more accessible.

Without this patch, paged results from LDAP are not possible. [Well,
they _are_ possible, if one loads the entire result set in memory. :-| 
]

How come is this patch's status "No Feedback"? What is the PHP
developers' stand on this patch as of now?

Alexandros Vellis



[2007-09-24 12:58:06] avel+php at noc dot uoa dot gr

This is a _killer_ feature that we have been waiting for a long time. 
White pages apps written in PHP, with large directories behind them,
desparetely need the paging feature -- and not only them!

The API seems intuitive to me so far. I'm eager for this to be included
in PHP 5.3.

Thanks for the patch.

Alexandros Vellis



[2007-09-07 18:40:25] ando at sys-net dot it

A working patch with test examples lined up to HEAD as of 5 minutes ago
is available here



I'm the original developer, and I'm willing to cooperate in integrating
it, if needed.  So you can re-open the bug now.

p.



[2007-09-07 14:59:29] ando at sys-net dot it

Yes, so many functions are needed to support generic stuff + dozens of
well-known, RFC/I.D. based LDAP controls and extended operations,
without code duplication.  Any developer would agree.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/42060

-- 
Edit this bug report at http://bugs.php.net/?id=42060&edit=1

#42060 [Com]: [PATCH] Add pagedResults support and more (PAT18 and PAT19 updated for 5.2.3)

[dan dot marsden at gmail dot com]

 ID:   42060
 Comment by:   dan dot marsden at gmail dot com
 Reported By:  iarenuno at eteo dot mondragon dot edu
 Status:   No Feedback
 Bug Type: LDAP related
 Operating System: Any
 PHP Version:  5.2.3
 Assigned To:  jani
 New Comment:

... I wonder if the reason that this bug hasn't had any traction is
because "jani" is no longer a PHP developer? - maybe we need to create a
"new" bug and link to this one to get it noticed by the Dev team?

:-)

Dan


Previous Comments:


[2007-11-21 11:33:02] avel+php at noc dot uoa dot gr

I intend to write a wrapper function for PEAR::Pager and LDAP, to make
paged results more accessible.

Without this patch, paged results from LDAP are not possible. [Well,
they _are_ possible, if one loads the entire result set in memory. :-| 
]

How come is this patch's status "No Feedback"? What is the PHP
developers' stand on this patch as of now?

Alexandros Vellis



[2007-09-24 12:58:06] avel+php at noc dot uoa dot gr

This is a _killer_ feature that we have been waiting for a long time. 
White pages apps written in PHP, with large directories behind them,
desparetely need the paging feature -- and not only them!

The API seems intuitive to me so far. I'm eager for this to be included
in PHP 5.3.

Thanks for the patch.

Alexandros Vellis



[2007-09-07 18:40:25] ando at sys-net dot it

A working patch with test examples lined up to HEAD as of 5 minutes ago
is available here



I'm the original developer, and I'm willing to cooperate in integrating
it, if needed.  So you can re-open the bug now.

p.



[2007-09-07 14:59:29] ando at sys-net dot it

Yes, so many functions are needed to support generic stuff + dozens of
well-known, RFC/I.D. based LDAP controls and extended operations,
without code duplication.  Any developer would agree.



[2007-09-07 14:57:40] ando at sys-net dot it

Be serious: the patch applies back up to PHP 4 (the last time an update
occurred to LDAP support).



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/42060

-- 
Edit this bug report at http://bugs.php.net/?id=42060&edit=1

#44752 [NEW]: Crash with new DateTimeZone(null)

[daniel dot oconnor at gmail dot com]

From: daniel dot oconnor at gmail dot com
Operating system: Windows XP
PHP version:  5.2.5
PHP Bug Type: Date/time related
Bug description:  Crash with new DateTimeZone(null)

Description:

new DateTimeZone crashes apache when given something it can't recognize.

timezone_open is more robust

This has similar symptoms to Bug #43377 ; but is probably different

Reproduce code:
---
http://bugs.php.net/?id=44752&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=44752&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=44752&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=44752&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44752&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=44752&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=44752&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44752&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44752&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=44752&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44752&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=44752&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=44752&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44752&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=44752&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44752&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44752&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=44752&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=44752&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=44752&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44752&r=mysqlcfg

#44751 [NEW]: "configure command" line in phpinfo() annoying

[eth at ethaniel dot com]

From: eth at ethaniel dot com
Operating system: Any
PHP version:  5.2.5
PHP Bug Type: Feature/Change Request
Bug description:  "configure command" line in phpinfo() annoying

Description:

The phpinfo() outputs a line with the "configure command" which looks like
this

'./configure' '--with-layout=GNU'
'--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all'
'--enable-libxml' '--with-libxml-dir=/usr/local' '--enable-reflection'
'--program-prefix=' '--enable-fastcgi' '--with-regex=php'
'--with-zend-vm=CALL' '--prefix=/usr/local' '--mandir=/usr/local/man'
'--infodir=/usr/local/info/'

Notice all the 's, why add them? They make it impossible to just
copy-paste this command to the command line and make any changes to it.

I propose removing those ' characters and just leave:

./configure --with-layout=GNU
--with-config-file-scan-dir=/usr/local/etc/php --disable-all
--enable-libxml --with-libxml-dir=/usr/local --enable-reflection
--program-prefix= --enable-fastcgi --with-regex=php --with-zend-vm=CALL
--prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/


-- 
Edit bug report at http://bugs.php.net/?id=44751&edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=44751&r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=44751&r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=44751&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44751&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=44751&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=44751&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44751&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44751&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=44751&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44751&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=44751&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=44751&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44751&r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=44751&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44751&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44751&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=44751&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=44751&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=44751&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44751&r=mysqlcfg