#26168 [Opn->Csd]: phpize changes don't check for execute status on shtool
ID: 26168 Updated by: [EMAIL PROTECTED] Reported By: robbat2 at gentoo dot org -Status: Open +Status: Closed Bug Type: *Compile Issues Operating System: Gentoo Linux PHP Version: 4.3.4 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-11-07 21:21:38] robbat2 at gentoo dot org i do realize that /usr/lib/build/* will have the execute bits set on them if the install-build make target has been used, but the purpose of this patch is to [2003-11-07 17:13:55] robbat2 at gentoo dot org Patch that fixes phpize: --- php-4.3.4/./scripts/phpize.in.old 2003-11-07 14:20:41.0 -0800 +++ php-4.3.4/./scripts/phpize.in 2003-11-07 14:21:07.0 -0800 @@ -57,6 +57,7 @@ aclocal || exit 1 autoconf || exit 1 autoheader || exit 1 +test -x $builddir/build/shtool || chmod +x $builddir/build/shtool libtoolize=`$builddir/build/shtool path glibtoolize libtoolize` $libtoolize -f -c || exit 1 [2003-11-07 17:09:08] robbat2 at gentoo dot org Description: phpize as of 4.3.4 does NOT check that $builddir/build/shtool is executable before it tries to run it. Reproduce code: --- 1. unpack any source based php extension (I used turck-mmcache-2.4.6) 2. ensure that your /usr/lib/php/build/shtool does NOT have execute set. 3. in the new dir, run phpize. Expected result: should complete correctly. phpize should set shtool to be executable before it tries to run it, or at the very least it should check if it is executable. Actual result: -- you get this error: /usr/bin/phpize: line 1: /var/tmp/portage/turck-mmcache-2.4.6/work/turck-mmcache-2.4.6/build/shtool: Permission denied /usr/bin/phpize: line 61: -f: command not found -- Edit this bug report at http://bugs.php.net/?id=26168&edit=1
#26183 [Opn->Bgs]: Sablotron incorrectly erroring on DOCTYPE SYSTEM http
ID: 26183 Updated by: [EMAIL PROTECTED] Reported By: andrew at operationaldynamics dot com -Status: Open +Status: Bogus Bug Type: XML related Operating System: Gentoo Linux PHP Version: 4.3.2 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. Thank you for your interest in PHP. This is a Sablotron issue, not a PHP one. Please report this bug to Sablotron developers. Previous Comments: [2003-11-09 02:34:04] andrew at operationaldynamics dot com Description: When using the Sablotron XSLT processor, it would not let me reference a SYSTEM DTD via http. I was using: just fine, but when I needed to make the reference not rely on my location on the filesystem, I switched to this: http://goals/plan.dtd";> which no longer worked. Error below. Reproduce code: --- Calling PHP code: xslt_process($xh, $srcfile, $xslfile, $outfile) Expected result: http references should work in SYSTEM declarations! Actual result: -- Warning: Sablotron error on line 1: XML parser error 4: not well-formed (invalid token) in /home/andrew/Sites/local/goals/goalsDriver.php on line 115 WORKAROUND: By changing the DOCTYPE line to http://goals/plan.dtd";> It worked exactly as expected. I looked around, and saw many W3C examples which used SYSTEM in conjunction with an http method. The PUBLIC specification is only supposed to be used when one has done the right thing in naming a public DTD (ie, "-" isn't really an appropriate name!) Methinks that this is an upstream bug in Sablotron. AfC -- Edit this bug report at http://bugs.php.net/?id=26183&edit=1
#26177 [Opn->Bgs]: Can't store multiple variables in SHM
ID: 26177
Updated by: [EMAIL PROTECTED]
Reported By: l_faillie at yahoo dot com
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Solaris 8
PHP Version: 4.3.3
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
The non-numeric keys get converted to 0, which causes the variable to
be overwritten.
Previous Comments:
[2003-11-08 15:50:36] cunha17 at uol dot com dot br
oops! It seems that the second argument should be an integer:
int shm_put_var ( int shm_identifier, int variable_key, mixed variable)
[2003-11-08 12:49:26] l_faillie at yahoo dot com
Yes it was my workaround but ... if it's the correct beaviour of this
function, what is the usefullness of the second argument ?
[2003-11-08 12:42:22] cunha17 at uol dot com dot br
In fact, you should use an array if you want to store multiple
information.
Source 1 : storing variables
$shm = shm_attach( 2710, 512);
$data = array('val'=>'blabla',
'jour'=> date('D'));
shm_put_var( $shm, 'data', serialize($data));
Source 2 : reading variables
$shm = shm_attach( 2710, 512);
$data = unserialize(shm_get_var($shm, 'data'));
echo 'val :', $data['val'], "\n";
echo 'jour :', $data['jour'], "\n";
[2003-11-08 10:06:05] l_faillie at yahoo dot com
Description:
Hi all,
It seems only one variable can be stored in a SHM zone.
Reproduce code:
---
Source 1 : storing variables
$shm = shm_attach( 2710, 512);
shm_put_var( $shm, 'val', 'blabla');
shm_put_var( $shm, 'jour', date('D'));
Source 2 : reading variables
$shm = shm_attach( 2710, 512);
echo 'val :', shm_get_var($shm, 'val'), "\n";
echo 'jour :', shm_get_var($shm, 'jour'), "\n";
Expected result:
val :blabla
jour :Sat
Actual result:
--
val :Sat
jour :Sat
--
Edit this bug report at http://bugs.php.net/?id=26177&edit=1
#26176 [Opn->Csd]: parse_ini_file elements bug
ID: 26176 Updated by: [EMAIL PROTECTED] Reported By: glox at glox dot be -Status: Open +Status: Closed Bug Type: *General Issues Operating System: linux slackware 9.0 PHP Version: 5CVS-2003-11-08 (dev) New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-11-08 08:05:09] glox at glox dot be I switched "Expected Result" and "Actual Result" sorry [2003-11-08 07:59:45] glox at glox dot be Description: When I load a .ini file with parse_ini_file and try to echo the elements of the array it won't work. The values show up on print_r/var_dump but can't be echo'd seperately. When I use foreach it finds the elements too. I tried the same script in php4 on the same pc and it worked fine. Reproduce code: --- # phpbug.php # config.ini ; PHPIRCD Configuration File ; Client ports: you can specify up to 10 ports here, start with 0 [clientports] 0 = 6667 1 = 6668 ; Server ports: you can specify up to 10 ports here, start with 0 [serverports] 0 = 4041 Expected result: Array ( [clientports] => Array ( [0] => 6667 [1] => 6668 ) [serverports] => Array ( [0] => 4041 ) ) Array ( [0] => 6667 [1] => 6668 ) NULL Actual result: -- Array ( [clientports] => Array ( [0] => 6667 [1] => 6668 ) [serverports] => Array ( [0] => 4041 ) ) Array ( [0] => 6667 [1] => 6668 ) string(4) "6667" -- Edit this bug report at http://bugs.php.net/?id=26176&edit=1
#26187 [NEW]: mysql_num_rows returns error when empty instead of 0
From: matt at 1lsn dot com
Operating system: Slackware 8.1
PHP version: 4.3.4
PHP Bug Type: MySQL related
Bug description: mysql_num_rows returns error when empty instead of 0
Description:
when doing a mysql_num_rows, if there are no matching rows it gives an
error instead of returning 0.
Reproduce code:
---
$Query = "SELECT * FROM MyTable WHERE Field1 = '1' and Field2 = '2' ";
$Result = mysql_query($Query) or die("Error101: ".
mysql_error()."".$Query);
$CNT = mysql_num_rows($Result) OR DIE("Error 102:
"."".mysql_error()."".$Query."");
echo "There are ".$CNT." matching results. ";
Expected result:
$CNT should be set to '0' and page should display
"There are 0 matching results."
Actual result:
--
Error 102:
SELECT * FROM MyTable WHERE Field1 = '1' and Field2 = '2'
--
Edit bug report at http://bugs.php.net/?id=26187&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26187&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26187&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26187&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26187&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26187&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=26187&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26187&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26187&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26187&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26187&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26187&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26187&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26187&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26187&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26187&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26187&r=float
#26186 [Bgs]: include_path ignored using include with virtual path
ID: 26186 User updated by: jon at banton dot plus dot com Reported By: jon at banton dot plus dot com Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows 2000 Pro PHP Version: 4.3.4 New Comment: Thank you for your comment, but I have read the documentation carefully. I know what the initial "/" or "\" means, but the correct term is virtual, as an absolute path includes scheme (e.g. http). The fact is that the initial "\" indicates that the file should be located starting at the root, which is specified in the "include_path" statement. As I said, in version 4.2.1 (and I have since checked 4.2.3) it works. But in 4.3.0 it does not. The only difference is the version of PHP, not my "include_path" setting, or any of my source files. Previous Comments: [2003-11-09 08:28:30] [EMAIL PROTECTED] 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 A / or \\ at the start of a filename is interpreted as an absolute path. Please read the documentation carefully! [2003-11-09 08:04:17] jon at banton dot plus dot com Description: I have just installed PHP 4.3.4 but I cannot get the "include" statement to work for virtual paths (those from the root). I am running PHP with Apache 1.3.26 or 1.3.29 on Windows 2000 Pro. The errors I get (2 for each include statement) are all like this: [Sat Nov 08 20:24:35 2003] [error] PHP Warning: main(/includes/dates/date_table.inc): failed to open stream: No such file or directory in c:\apache-web\info_site.phtml on line 54 [Sat Nov 08 20:24:35 2003] [error] PHP Warning: main(): Failed opening '/includes/dates/date_table.inc' for inclusion (include_path='.;c:\apache-web') in c:\apache-web\info_site.phtml on line 54 Include statements work for relative paths, for full file paths and for HTTP URLs, but not for virtual paths. They used to work: I have been using PHP Version 4.2.1 with Apache 1.3.26 successfully for some time. To eliminate other factors, first I downloaded the latest version of Apache (I was using my existing version, which was 1.3.26). But changing to 1.3.29 made no difference. Then I tried installing a previous version of PHP - I tried 4.3.0, but this produces the same error. In case I had done something in my original installation (4.2.1) that I had forgotten about, I downloaded a fresh copy of 4.2.1 and installed and ran that using exactly the same procedure as I used for 4.3.4 and 4.3.0. Yes, that still worked, so the problem was in 4.3.0 and 4.3.4. Other measures I have tried include (no pun intended): changing the value of "include_path" from ".;c:\apache-web" to "c:\apache-web;." changing the back slash to a forward slash (from ".;c:\apache-web" to "c:/apache-web;.") changing the back slash to a double back slash (from ".;c:\apache-web" to ".;c:\\apache-web") [clutching at straws here] In all cases, phpinfo() reported the correct value of "include_path" Is this a known bug? I have tried searching the reported bugs for PHP, but nothing showed up. This does seem to be too fundamental to have escaped notice for (at least) four versions, though. Reproduce code: --- Expected result: File included (i.e. no entry in error.log) Actual result: -- Following entries in error.log: [Sat Nov 08 16:33:20 2003] [error] PHP Warning: main(/includes/check_browser.inc): failed to open stream: No such file or directory in c:\apache-web\info_site.phtml on line 9 [Sat Nov 08 16:33:20 2003] [error] PHP Warning: main(): Failed opening '/includes/check_browser.inc' for inclusion (include_path='.;c:\apache-web') in c:\apache-web\info_site.phtml on line 9 -- Edit this bug report at http://bugs.php.net/?id=26186&edit=1
#24393 [Com]: Can't find iconv.dll
ID: 24393 Comment by: spam at infeer dot com Reported By: zarxos at yahoo dot com Status: Bogus Bug Type: *General Issues Operating System: Windows XP PHP Version: 5CVS-2003-06-29 (dev) New Comment: To [EMAIL PROTECTED]: Very bad suggestion !!! Do you realy expect ppl to copy all *.dll to the system32 folder when trying to use a beta PHP5 (or other version)? How do you expect Ppl do any testing? What I usually did in V4.x is to copy the apache API-dll C:/php4/sapi/php4apache.dll to C:/php4/ That did the trick so far. But in PHP V5 Apache complains it can't load php4apache.dll (even if it's there). I found out that PHP5 requires an additional DLL: the C:/php4/dlls/iconv.dll for some reson. So I also copy C:/php5/dlls/iconv.dll to C:/php5/ and everything works so far again. Previous Comments: [2003-06-29 20:07:40] [EMAIL PROTECTED] If you read install.txt that comes with PHP it would tell you to copy dlls\*.dll to system32 folder. [2003-06-29 19:33:01] zarxos at yahoo dot com Description: In Windows XP and Apache 1.3.27, when you try to load a php page, it says PHP could not be loaded because iconv.dll could not be found. This is fixable by moving it to C:\Windows\System32 but I thought I would just let you guys know. Reproduce code: --- Any PHP Code Expected result: Whatever PHP page I'm trying to load. Actual result: -- 500 - Internal Server Error -- Edit this bug report at http://bugs.php.net/?id=24393&edit=1
#22108 [Com]: php doesn't ignore the utf-8 BOM
ID: 22108 Comment by: a9c83cd8bb41db324db5b449352f183 at arcor dot de Reported By: bugzilla at jellycan dot com Status: Assigned Bug Type: Feature/Change Request Operating System: * PHP Version: * Assigned To: moriyoshi New Comment: Thought about it... Now I think it's better when the BOM isn't part of the output because that would cause trouble if you want to output images or PDF or something like that... Previous Comments: [2003-11-08 06:45:22] a9c83cd8bb41db324db5b449352f183 at arcor dot de I think the best would be that PHP recognizes the BOM and outputs it before it outputs the document (but after the HTTP headers, of course) so that the document can still be recognized as UTF-8 when it's saved to disk (where no Content-Type headers with a charset specification are available). [2003-11-07 03:09:53] trunghongnguyen at yahoo dot com ertre [2003-10-31 11:12:06] [EMAIL PROTECTED] I added i18n support to Zend Engine 2 (though it's still partial one...), and one of its features contain awareness of BOM. So now you can gracefully parse scripts with BOM if you use PHP 5.0.0b2 and configure it with the option '--enable-zend-multibyte'. These features are still experimental and under testing, so that I have not been documented these but I'll add the entry to the manual, ZEND_CHANGES and so on if I feel certain of the stability and robustness of my patch, though I do not know when it is:) Anyway, I'll close this bug if '--enable-zend-multibyte' option in PHP 5.0.0b2 is assured to work well for this problem. Comments are welcome. [2003-02-07 23:13:07] bugzilla at jellycan dot com The BOM (byte order mark) is a few bytes at the very front of a file that act as a signature denoting what type of encoding has been used, and in UTF16/32 it also makes the byte order (LE or BE). Although utf-8 is byte order independent, it has become popular on windows (perhaps not so on unix) to make use of the BOM encoded in UTF-8 to flag the file as being in UTF-8 format. This allows editors to determine the type of the file from the first few characters instead of trying to guess what type the file is. Ref: Textpad 4.6 (http://textpad.com) See the Unicode FAQ for details of the utf-8 BOM... http://www.unicode.org/unicode/faq/utf_bom.html#25 The use of this should be obvious, you have to leave the my-language-only mindset that afflicts too many programmers (myself included before this job) and think about the growing multiplicity of languages on the web. I am writing web applications in Japan, with European language and CJK (Chinese/Japanese/Korean) language processing and interfaces. Thus I have php files where variable values are strings of all sorts of languages - hence utf-8 encoding. I feel that this is definitely a bug in php. Considering that: * php is slowly growing into a language-neutral (i18n/l10n possible) language * php is designed such that php commands can be liberally sprinkled through html, and html is increasing encoded in utf-8 these days * the utf-8 bom is becoming increasingly popular for reasons of indentifying the file character format * if the utf-8 bom exists php actually outputs it incorrectly and in doing so prevents header output I request that you don't see this as a feature request, but as a bug in the handling of utf-8 files. Whether the output generator is the correct characterization of this bug or not I leave up to you. Regards, Brodie. [2003-02-07 08:46:36] bugzilla at jellycan dot com Problem: When a php file is saved in utf-8 format with the UTF-8 BOM as the first three bytes of the file (EF BB BF), PHP doesn't ignore these bytes when loading and compiling the file, but instead considers them output coming prior to the http://bugs.php.net/?id=22108&edit=1
#26175 [Com]: Yet Another Solaris compilation problem :-((
ID: 26175 Comment by: simon dot boulet at divahost dot net Reported By: l_faillie at yahoo dot com Status: Bogus Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.3.4 New Comment: Bug #26105 addresses this issue. http://bugs.php.net/bug.php?id=26105 Previous Comments: [2003-11-08 12:44:16] l_faillie at yahoo dot com Which one ? I've looking in the database and found nothing :-( [2003-11-08 12:35:45] [EMAIL PROTECTED] 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. This is a duplicate of the other bugs on this issue. Latest CVS snapshot fixes the problem. [2003-11-08 05:47:21] l_faillie at yahoo dot com Description: Hi all, the compilation fails at the 1st file w/ following error : /bin/sh /export/home/laurent/bidon/php-4.3.4/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/zlib/ -I/export/home/laurent/bidon/php-4.3.4/ext/zlib/ -DPHP_ATOM_INC -I/export/home/laurent/bidon/php-4.3.4/include -I/export/home/laurent/bidon/php-4.3.4/main -I/export/home/laurent/bidon/php-4.3.4 -I/export/home/laurent/bidon/php-4.3.4/Zend -I/usr/local/include -I/usr/local/pgsql/include -I/export/home/laurent/bidon/php-4.3.4/ext/xml/expat -D_POSIX_PTHREAD_SEMANTICS -I/export/home/laurent/bidon/php-4.3.4/TSRM -g -O2 -prefer-pic -c /export/home/laurent/bidon/php-4.3.4/ext/zlib/zlib.c -o ext/zlib/zlib.lo In file included from /export/home/laurent/bidon/php-4.3.4/main/php.h:34, from /export/home/laurent/bidon/php-4.3.4/ext/zlib/zlib.c:28: /export/home/laurent/bidon/php-4.3.4/Zend/zend.h:311: argument format specified for non-function `error_function' /export/home/laurent/bidon/php-4.3.4/Zend/zend.h:312: argument format specified for non-function `printf_function' /export/home/laurent/bidon/php-4.3.4/Zend/zend.h:444: argument format specified for non-function `zend_printf' /export/home/laurent/bidon/php-4.3.4/Zend/zend.h:451: argument format specified for non-function `zend_error_cb' make: *** [ext/zlib/zlib.lo] Error 1 My system is : [1109]/export/home/laurent $uname -a SunOS zeus 5.8 Generic_108528-03 sun4u sparc SUNW,Ultra-5_10 [1121]/export/home/laurent $gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.0.1/specs Configured with: ../configure --with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld --enable-libgcj Thread model: posix gcc version 3.0.1 I think it's a Solaris related problem because I can't reproduce it on my SunServer5/NetBSD 1.6 system. -- Edit this bug report at http://bugs.php.net/?id=26175&edit=1
#25975 [Opn->Fbk]: PHP 5 object references don't survive serialization
ID: 25975
Updated by: [EMAIL PROTECTED]
Reported By: reiersol at online dot no
-Status: Open
+Status: Feedback
Bug Type: Zend Engine 2 problem
Operating System: Linux RedHat 9.0
PHP Version: 5CVS-2003-10-24 (dev)
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
This should be fixed in CVS now.
Previous Comments:
[2003-11-09 10:46:13] reiersol at online dot no
Opening the bug again
[2003-11-04 01:23:53] reiersol at online dot no
object(foo)#1 (2) {
["v1"]=>
object(bar)#2 (1) {
["value"]=>
int(42)
}
["v2"]=>
object(bar)#2 (1) {
["value"]=>
int(42)
}
}
object(foo)#3 (2) {
["v1"]=>
object(bar)#4 (1) {
["value"]=>
string(42) "and now for something completely different"
}
["v2"]=>
object(bar)#4 (1) {
["value"]=>
string(42) "and now for something completely different"
}
}
[2003-11-04 00:28:17] [EMAIL PROTECTED]
Add the missing expected result to your last example.
[2003-10-31 03:42:04] reiersol at online dot no
I guess I'll have to expand my example:
class Bar { var $value = 0; }
class Foo {
var $v1;
var $v2;
function Foo() {
$this->v1 = new Bar;
$this->v2 = $this->v1;
}
}
$f = new Foo;
$f->v2->value = 42;
var_dump($f);
$g = unserialize(serialize($f));
$g->v2->value = 'and now for something completely different';
var_dump($g);
Here's the output:
object(foo)#1 (2) {
["v1"]=>
object(bar)#2 (1) {
["value"]=>
int(42)
}
["v2"]=>
object(bar)#2 (1) {
["value"]=>
int(42)
}
}
object(foo)#3 (2) {
["v1"]=>
object(bar)#4 (1) {
["value"]=>
int(42)
}
["v2"]=>
object(bar)#5 (1) {
["value"]=>
string(42) "and now for something completely different"
}
}
That should at least make it clear that there's a difference in
behavior before and after serialization. And the behavior before
serialization is the behavior of a normal object-oriented language. (I
ported the example to Java just to make sure I wasn't crazy.)
I'm not trying to split hairs. I tried creating the kind of
sophiticated object-oriented structure that PHP 5 makes so much easier.
It worked wonderfully. But then I discovered that the structure didn't
persist across sessions. So I made this simplified example to
demonstrate the problem.
[2003-10-24 08:08:59] reiersol at online dot no
Description:
Object references inside PHP5 objects are not preserved through
serialize/unserialize like traditional PHP4 references. This means they
cannot be used in session-based applications.
Reproduce code:
---
class Bar {}
class Foo {
var $v1;
var $v2;
function Foo() {
$this->v1 = new Bar;
$this->v2 = $this->v1;
}
}
$f = new Foo;
var_dump($f);
$g = unserialize(serialize($f));
var_dump($g);
print $s1;
Expected result:
This is what I get if I use $this->v2 = &this->$v1 instead of $this->v2
= $this->v1:
object(foo)#1 (2) {
["v1"]=>
&object(bar)#2 (0) {
}
["v2"]=>
&object(bar)#2 (0) {
}
}
object(foo)#3 (2) {
["v1"]=>
&object(bar)#4 (0) {
}
["v2"]=>
&object(bar)#4 (0) {
}
}
Actual result:
--
object(foo)#1 (2) {
["v1"]=>
object(bar)#2 (0) {
}
["v2"]=>
object(bar)#2 (0) {
}
}
object(foo)#3 (2) {
["v1"]=>
object(bar)#4 (0) {
}
["v2"]=>
object(bar)#5 (0) {
}
}
--
Edit this bug report at http://bugs.php.net/?id=25975&edit=1
#25975 [Bgs->Opn]: PHP 5 object references don't survive serialization
ID: 25975
User updated by: reiersol at online dot no
Reported By: reiersol at online dot no
-Status: Bogus
+Status: Open
Bug Type: Zend Engine 2 problem
Operating System: Linux RedHat 9.0
PHP Version: 5CVS-2003-10-24 (dev)
New Comment:
Opening the bug again
Previous Comments:
[2003-11-04 01:23:53] reiersol at online dot no
object(foo)#1 (2) {
["v1"]=>
object(bar)#2 (1) {
["value"]=>
int(42)
}
["v2"]=>
object(bar)#2 (1) {
["value"]=>
int(42)
}
}
object(foo)#3 (2) {
["v1"]=>
object(bar)#4 (1) {
["value"]=>
string(42) "and now for something completely different"
}
["v2"]=>
object(bar)#4 (1) {
["value"]=>
string(42) "and now for something completely different"
}
}
[2003-11-04 00:28:17] [EMAIL PROTECTED]
Add the missing expected result to your last example.
[2003-10-31 03:42:04] reiersol at online dot no
I guess I'll have to expand my example:
class Bar { var $value = 0; }
class Foo {
var $v1;
var $v2;
function Foo() {
$this->v1 = new Bar;
$this->v2 = $this->v1;
}
}
$f = new Foo;
$f->v2->value = 42;
var_dump($f);
$g = unserialize(serialize($f));
$g->v2->value = 'and now for something completely different';
var_dump($g);
Here's the output:
object(foo)#1 (2) {
["v1"]=>
object(bar)#2 (1) {
["value"]=>
int(42)
}
["v2"]=>
object(bar)#2 (1) {
["value"]=>
int(42)
}
}
object(foo)#3 (2) {
["v1"]=>
object(bar)#4 (1) {
["value"]=>
int(42)
}
["v2"]=>
object(bar)#5 (1) {
["value"]=>
string(42) "and now for something completely different"
}
}
That should at least make it clear that there's a difference in
behavior before and after serialization. And the behavior before
serialization is the behavior of a normal object-oriented language. (I
ported the example to Java just to make sure I wasn't crazy.)
I'm not trying to split hairs. I tried creating the kind of
sophiticated object-oriented structure that PHP 5 makes so much easier.
It worked wonderfully. But then I discovered that the structure didn't
persist across sessions. So I made this simplified example to
demonstrate the problem.
[2003-10-24 08:08:59] reiersol at online dot no
Description:
Object references inside PHP5 objects are not preserved through
serialize/unserialize like traditional PHP4 references. This means they
cannot be used in session-based applications.
Reproduce code:
---
class Bar {}
class Foo {
var $v1;
var $v2;
function Foo() {
$this->v1 = new Bar;
$this->v2 = $this->v1;
}
}
$f = new Foo;
var_dump($f);
$g = unserialize(serialize($f));
var_dump($g);
print $s1;
Expected result:
This is what I get if I use $this->v2 = &this->$v1 instead of $this->v2
= $this->v1:
object(foo)#1 (2) {
["v1"]=>
&object(bar)#2 (0) {
}
["v2"]=>
&object(bar)#2 (0) {
}
}
object(foo)#3 (2) {
["v1"]=>
&object(bar)#4 (0) {
}
["v2"]=>
&object(bar)#4 (0) {
}
}
Actual result:
--
object(foo)#1 (2) {
["v1"]=>
object(bar)#2 (0) {
}
["v2"]=>
object(bar)#2 (0) {
}
}
object(foo)#3 (2) {
["v1"]=>
object(bar)#4 (0) {
}
["v2"]=>
object(bar)#5 (0) {
}
}
--
Edit this bug report at http://bugs.php.net/?id=25975&edit=1
#26185 [Csd]: Installation fails for IIS6
ID: 26185 Updated by: [EMAIL PROTECTED] Reported By: burkeden at comcast dot net Status: Closed Bug Type: IIS related Operating System: Windows Server 2003 PHP Version: 4.3.4 New Comment: My suggested quick workaround won't cause the old installer to work - it's just doing the last bit of IIS configuration which the installer failed to do. Previous Comments: [2003-11-09 09:12:02] schari at surfeu dot at thank for info but i tried command line on a 2003 gr version without a positiv result. script will bestartet but iisext not found will still occure schari [2003-11-09 08:52:15] [EMAIL PROTECTED] The new installer should be available for download in couple of hours. [2003-11-09 07:57:23] [EMAIL PROTECTED] The installer had a problem with the path to IISext. A new version of the installer has been prepared and should be available for download soon. The fixed installer reports itself as 'Installer version number 1.0.23' on the first wizard screen. A quick workaround if you don't want to wait for the new installer is to run iiseext /AddFile "c:\program files\php.exe" 1 php 1 php at the command line. [2003-11-09 07:31:19] burkeden at comcast dot net Description: This is a bug of the installation, not the PHP product: Clean Windows Server 2003 Install Install IIS v6 Run installer version of PHP 4.3.4 Installation selections: "Standard install", "C:\progra~1\php", IIS6 & above Install completes without error if I choose IIS4 & above (but afterward PHP does not work) When I choose IIS 6 & above, as I should, I always get an "IISEXT not found" error. I verified this file exists, permissions are correct, and it is in the path. -- Edit this bug report at http://bugs.php.net/?id=26185&edit=1
#26181 [Opn->Bgs]: Problems with POST and GET variables
ID: 26181
Updated by: [EMAIL PROTECTED]
Reported By: gabriel at zunto dot com
-Status: Open
+Status: Bogus
Bug Type: Output Control
Operating System: Windows 2000 Professional
PHP Version: 4.3.4
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 you'd have read the documentation right, you'd have noticed that it
works using if(!isset($_POST['delivered'])){ [...]
Previous Comments:
[2003-11-08 17:28:49] gabriel at zunto dot com
Description:
With PHP 4.3.4 is no possible to verify if POST or GET variables is
undefineds because the global variable $_POST is a Array, therefore the
index of Array $_POST is not found.
Reproduce code:
---
Expected result:
Show the string "Yes"
Actual result:
--
Notice: Undefined index: delivered in c:\\file.php on line 2
Yes
--
Edit this bug report at http://bugs.php.net/?id=26181&edit=1
#26185 [Com]: Installation fails for IIS6
ID: 26185 Comment by: schari at surfeu dot at Reported By: burkeden at comcast dot net Status: Closed Bug Type: IIS related Operating System: Windows Server 2003 PHP Version: 4.3.4 New Comment: thank for info but i tried command line on a 2003 gr version without a positiv result. script will bestartet but iisext not found will still occure schari Previous Comments: [2003-11-09 08:52:15] [EMAIL PROTECTED] The new installer should be available for download in couple of hours. [2003-11-09 07:57:23] [EMAIL PROTECTED] The installer had a problem with the path to IISext. A new version of the installer has been prepared and should be available for download soon. The fixed installer reports itself as 'Installer version number 1.0.23' on the first wizard screen. A quick workaround if you don't want to wait for the new installer is to run iiseext /AddFile "c:\program files\php.exe" 1 php 1 php at the command line. [2003-11-09 07:31:19] burkeden at comcast dot net Description: This is a bug of the installation, not the PHP product: Clean Windows Server 2003 Install Install IIS v6 Run installer version of PHP 4.3.4 Installation selections: "Standard install", "C:\progra~1\php", IIS6 & above Install completes without error if I choose IIS4 & above (but afterward PHP does not work) When I choose IIS 6 & above, as I should, I always get an "IISEXT not found" error. I verified this file exists, permissions are correct, and it is in the path. -- Edit this bug report at http://bugs.php.net/?id=26185&edit=1
#26185 [Csd]: Installation fails for IIS6
ID: 26185 Updated by: [EMAIL PROTECTED] Reported By: burkeden at comcast dot net Status: Closed Bug Type: IIS related Operating System: Windows Server 2003 PHP Version: 4.3.4 New Comment: The new installer should be available for download in couple of hours. Previous Comments: [2003-11-09 07:57:23] [EMAIL PROTECTED] The installer had a problem with the path to IISext. A new version of the installer has been prepared and should be available for download soon. The fixed installer reports itself as 'Installer version number 1.0.23' on the first wizard screen. A quick workaround if you don't want to wait for the new installer is to run iiseext /AddFile "c:\program files\php.exe" 1 php 1 php at the command line. [2003-11-09 07:31:19] burkeden at comcast dot net Description: This is a bug of the installation, not the PHP product: Clean Windows Server 2003 Install Install IIS v6 Run installer version of PHP 4.3.4 Installation selections: "Standard install", "C:\progra~1\php", IIS6 & above Install completes without error if I choose IIS4 & above (but afterward PHP does not work) When I choose IIS 6 & above, as I should, I always get an "IISEXT not found" error. I verified this file exists, permissions are correct, and it is in the path. -- Edit this bug report at http://bugs.php.net/?id=26185&edit=1
#26186 [Opn->Bgs]: include_path ignored using include with virtual path
ID: 26186 Updated by: [EMAIL PROTECTED] Reported By: jon at banton dot plus dot com -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows 2000 Pro PHP Version: 4.3.4 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 A / or \ at the start of a filename is interpreted as an absolute path. Please read the documentation carefully! Previous Comments: [2003-11-09 08:04:17] jon at banton dot plus dot com Description: I have just installed PHP 4.3.4 but I cannot get the "include" statement to work for virtual paths (those from the root). I am running PHP with Apache 1.3.26 or 1.3.29 on Windows 2000 Pro. The errors I get (2 for each include statement) are all like this: [Sat Nov 08 20:24:35 2003] [error] PHP Warning: main(/includes/dates/date_table.inc): failed to open stream: No such file or directory in c:\apache-web\info_site.phtml on line 54 [Sat Nov 08 20:24:35 2003] [error] PHP Warning: main(): Failed opening '/includes/dates/date_table.inc' for inclusion (include_path='.;c:\apache-web') in c:\apache-web\info_site.phtml on line 54 Include statements work for relative paths, for full file paths and for HTTP URLs, but not for virtual paths. They used to work: I have been using PHP Version 4.2.1 with Apache 1.3.26 successfully for some time. To eliminate other factors, first I downloaded the latest version of Apache (I was using my existing version, which was 1.3.26). But changing to 1.3.29 made no difference. Then I tried installing a previous version of PHP - I tried 4.3.0, but this produces the same error. In case I had done something in my original installation (4.2.1) that I had forgotten about, I downloaded a fresh copy of 4.2.1 and installed and ran that using exactly the same procedure as I used for 4.3.4 and 4.3.0. Yes, that still worked, so the problem was in 4.3.0 and 4.3.4. Other measures I have tried include (no pun intended): changing the value of "include_path" from ".;c:\apache-web" to "c:\apache-web;." changing the back slash to a forward slash (from ".;c:\apache-web" to "c:/apache-web;.") changing the back slash to a double back slash (from ".;c:\apache-web" to ".;c:\\apache-web") [clutching at straws here] In all cases, phpinfo() reported the correct value of "include_path" Is this a known bug? I have tried searching the reported bugs for PHP, but nothing showed up. This does seem to be too fundamental to have escaped notice for (at least) four versions, though. Reproduce code: --- Expected result: File included (i.e. no entry in error.log) Actual result: -- Following entries in error.log: [Sat Nov 08 16:33:20 2003] [error] PHP Warning: main(/includes/check_browser.inc): failed to open stream: No such file or directory in c:\apache-web\info_site.phtml on line 9 [Sat Nov 08 16:33:20 2003] [error] PHP Warning: main(): Failed opening '/includes/check_browser.inc' for inclusion (include_path='.;c:\apache-web') in c:\apache-web\info_site.phtml on line 9 -- Edit this bug report at http://bugs.php.net/?id=26186&edit=1
#26186 [NEW]: include_path ignored using include with virtual path
From: jon at banton dot plus dot com Operating system: Windows 2000 Pro PHP version: 4.3.4 PHP Bug Type: Unknown/Other Function Bug description: include_path ignored using include with virtual path Description: I have just installed PHP 4.3.4 but I cannot get the "include" statement to work for virtual paths (those from the root). I am running PHP with Apache 1.3.26 or 1.3.29 on Windows 2000 Pro. The errors I get (2 for each include statement) are all like this: [Sat Nov 08 20:24:35 2003] [error] PHP Warning: main(/includes/dates/date_table.inc): failed to open stream: No such file or directory in c:\apache-web\info_site.phtml on line 54 [Sat Nov 08 20:24:35 2003] [error] PHP Warning: main(): Failed opening '/includes/dates/date_table.inc' for inclusion (include_path='.;c:\apache-web') in c:\apache-web\info_site.phtml on line 54 Include statements work for relative paths, for full file paths and for HTTP URLs, but not for virtual paths. They used to work: I have been using PHP Version 4.2.1 with Apache 1.3.26 successfully for some time. To eliminate other factors, first I downloaded the latest version of Apache (I was using my existing version, which was 1.3.26). But changing to 1.3.29 made no difference. Then I tried installing a previous version of PHP - I tried 4.3.0, but this produces the same error. In case I had done something in my original installation (4.2.1) that I had forgotten about, I downloaded a fresh copy of 4.2.1 and installed and ran that using exactly the same procedure as I used for 4.3.4 and 4.3.0. Yes, that still worked, so the problem was in 4.3.0 and 4.3.4. Other measures I have tried include (no pun intended): changing the value of "include_path" from ".;c:\apache-web" to "c:\apache-web;." changing the back slash to a forward slash (from ".;c:\apache-web" to "c:/apache-web;.") changing the back slash to a double back slash (from ".;c:\apache-web" to ".;c:\\apache-web") [clutching at straws here] In all cases, phpinfo() reported the correct value of "include_path" Is this a known bug? I have tried searching the reported bugs for PHP, but nothing showed up. This does seem to be too fundamental to have escaped notice for (at least) four versions, though. Reproduce code: --- Expected result: File included (i.e. no entry in error.log) Actual result: -- Following entries in error.log: [Sat Nov 08 16:33:20 2003] [error] PHP Warning: main(/includes/check_browser.inc): failed to open stream: No such file or directory in c:\apache-web\info_site.phtml on line 9 [Sat Nov 08 16:33:20 2003] [error] PHP Warning: main(): Failed opening '/includes/check_browser.inc' for inclusion (include_path='.;c:\apache-web') in c:\apache-web\info_site.phtml on line 9 -- Edit bug report at http://bugs.php.net/?id=26186&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26186&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26186&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26186&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26186&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26186&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26186&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26186&r=support Expected behavior: http://bugs.php.net/fix.php?id=26186&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26186&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26186&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26186&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26186&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26186&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26186&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26186&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26186&r=float
#26185 [Opn->Csd]: Installation fails for IIS6
ID: 26185 Updated by: [EMAIL PROTECTED] Reported By: burkeden at comcast dot net -Status: Open +Status: Closed Bug Type: IIS related Operating System: Windows Server 2003 PHP Version: 4.3.4 New Comment: The installer had a problem with the path to IISext. A new version of the installer has been prepared and should be available for download soon. The fixed installer reports itself as 'Installer version number 1.0.23' on the first wizard screen. A quick workaround if you don't want to wait for the new installer is to run iiseext /AddFile "c:\program files\php.exe" 1 php 1 php at the command line. Previous Comments: [2003-11-09 07:31:19] burkeden at comcast dot net Description: This is a bug of the installation, not the PHP product: Clean Windows Server 2003 Install Install IIS v6 Run installer version of PHP 4.3.4 Installation selections: "Standard install", "C:\progra~1\php", IIS6 & above Install completes without error if I choose IIS4 & above (but afterward PHP does not work) When I choose IIS 6 & above, as I should, I always get an "IISEXT not found" error. I verified this file exists, permissions are correct, and it is in the path. -- Edit this bug report at http://bugs.php.net/?id=26185&edit=1
#26185 [NEW]: Installation fails for IIS6
From: burkeden at comcast dot net Operating system: Windows Server 2003 PHP version: 4.3.4 PHP Bug Type: IIS related Bug description: Installation fails for IIS6 Description: This is a bug of the installation, not the PHP product: Clean Windows Server 2003 Install Install IIS v6 Run installer version of PHP 4.3.4 Installation selections: "Standard install", "C:\progra~1\php", IIS6 & above Install completes without error if I choose IIS4 & above (but afterward PHP does not work) When I choose IIS 6 & above, as I should, I always get an "IISEXT not found" error. I verified this file exists, permissions are correct, and it is in the path. -- Edit bug report at http://bugs.php.net/?id=26185&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26185&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26185&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26185&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26185&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26185&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26185&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26185&r=support Expected behavior: http://bugs.php.net/fix.php?id=26185&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26185&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26185&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26185&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26185&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26185&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26185&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26185&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26185&r=float
#26184 [NEW]: unable to detect character encoding
From: tom at nooper dot com Operating system: Redhat 8 PHP version: 4.3.4 PHP Bug Type: mbstring related Bug description: unable to detect character encoding Description: I get the following error generated: mb_convert_encoding(): Unable to detect character encoding Up to 4.3.3 this works no problem. I compiled php with same options including the --enable-mbstring=all. If I look at phpinfo() output it seems that all the languages are missing no matter if I compile with --enable-mbstring=ja or other. I noticed another bug which was closed that fixed a bug in the reporting of phpinfo() for mbstring where it was suggested that all languages were included now from 4.3.4 independant of compile options. The code snippet that was used to generate the error above is simply: echo mb_convert_encoding($jText, 'SJIS','AUTO'); where $jText is some "EUC-JP" text. I tried the latest php snapshot from cvs also and it also doesn't work. If you need a short example program to reproduce this problem, I can look into it from Monday/Tuesday. -- Edit bug report at http://bugs.php.net/?id=26184&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26184&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26184&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26184&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26184&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26184&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26184&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26184&r=support Expected behavior: http://bugs.php.net/fix.php?id=26184&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26184&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26184&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26184&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26184&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26184&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26184&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26184&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26184&r=float
#26183 [NEW]: Sablotron incorrectly erroring on DOCTYPE SYSTEM http
From: andrew at operationaldynamics dot com Operating system: Gentoo Linux PHP version: 4.3.2 PHP Bug Type: XML related Bug description: Sablotron incorrectly erroring on DOCTYPE SYSTEM http Description: When using the Sablotron XSLT processor, it would not let me reference a SYSTEM DTD via http. I was using: just fine, but when I needed to make the reference not rely on my location on the filesystem, I switched to this: http://goals/plan.dtd";> which no longer worked. Error below. Reproduce code: --- Calling PHP code: xslt_process($xh, $srcfile, $xslfile, $outfile) Expected result: http references should work in SYSTEM declarations! Actual result: -- Warning: Sablotron error on line 1: XML parser error 4: not well-formed (invalid token) in /home/andrew/Sites/local/goals/goalsDriver.php on line 115 WORKAROUND: By changing the DOCTYPE line to http://goals/plan.dtd";> It worked exactly as expected. I looked around, and saw many W3C examples which used SYSTEM in conjunction with an http method. The PUBLIC specification is only supposed to be used when one has done the right thing in naming a public DTD (ie, "-" isn't really an appropriate name!) Methinks that this is an upstream bug in Sablotron. AfC -- Edit bug report at http://bugs.php.net/?id=26183&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26183&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26183&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26183&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26183&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26183&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26183&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26183&r=support Expected behavior: http://bugs.php.net/fix.php?id=26183&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26183&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26183&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26183&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26183&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26183&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26183&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26183&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26183&r=float
