#28893 [Com]: Unexpected behaviour of "new"

2004-06-24 Thread rodolfo at rodsoft dot org 
 ID:   28893
 Comment by:   rodolfo at rodsoft dot org
 Reported By:  bf at mediaspace dot net
 Status:   Open
 Bug Type: Class/Object related
 Operating System: Linux
 PHP Version:  5.0.0RC3
 New Comment:

I've experienced something similar with 'clone' when the cloned
variable is used in mysqli_bind_result, as I said in bug #28870.


Previous Comments:


[2004-06-23 13:56:21] bf at mediaspace dot net

Description:

If using "new" in a for-loop it seems that the same instance is re-used
all the time. This is not what is expected, because in terms of OOP the
new-operator schould create a new instance every time.

Tested with 4.3.3 and 5.0RC3

Reproduce code:
---
iterator=$i;
$a[]=&$object;
}

foreach($a as $object) {
echo $object->iterator."";
}

?>

Expected result:

Output should be:

0
1
2
3
4
5
6
7
8
9


Actual result:
--
Output actual is:

9
9
9
9
9
9
9
9
9
9

-> The same instance is reused all the time.





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

#28893 [Com]: Unexpected behaviour of "new"

2004-06-24 Thread rodolfo at rodsoft dot org 
 ID:   28893
 Comment by:   rodolfo at rodsoft dot org
 Reported By:  bf at mediaspace dot net
 Status:   Open
 Bug Type: Class/Object related
 Operating System: Linux
 PHP Version:  5.0.0RC3
 New Comment:

I've just ran your example and found that if you write a[]=$object
(without &), it runs flawlessly.


Previous Comments:


[2004-06-23 18:48:02] rodolfo at rodsoft dot org

I've experienced something similar with 'clone' when the cloned
variable is used in mysqli_bind_result, as I said in bug #28870.



[2004-06-23 13:56:21] bf at mediaspace dot net

Description:

If using "new" in a for-loop it seems that the same instance is re-used
all the time. This is not what is expected, because in terms of OOP the
new-operator schould create a new instance every time.

Tested with 4.3.3 and 5.0RC3

Reproduce code:
---
iterator=$i;
$a[]=&$object;
}

foreach($a as $object) {
echo $object->iterator."";
}

?>

Expected result:

Output should be:

0
1
2
3
4
5
6
7
8
9


Actual result:
--
Output actual is:

9
9
9
9
9
9
9
9
9
9

-> The same instance is reused all the time.





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

#28870 [Opn]: mysqli_bind_result doesn't work with cloned objects

2004-06-21 Thread rodolfo at rodsoft dot org 
 ID:   28870
 User updated by:  rodolfo at rodsoft dot org
 Reported By:  rodolfo at rodsoft dot org
 Status:   Open
 Bug Type: *Database Functions
 Operating System: linux 2.6.7
 PHP Version:  5.0.0RC3
 New Comment:

A possible 'hack' that I've found is to bind the result to another
variable before cloning, and just after that restore the bind to the
original variable. This way the result is the expected one. It seems
that there's a problem of how mysqli_bind_result stores the variable
information while it is being cloned.


Previous Comments:


[2004-06-21 18:35:56] rodolfo at rodsoft dot org

Description:

If you pass to mysqli_bind_result a member variable of an object that
will be cloned and modified multiple times, each modification happens
in all cloned objects, as if they weren't cloned copies, but a single
copy of the object.

Reproduce code:
---
select_db('test');
$stmt = $db->prepare('SELECT a FROM test');
$stmt->execute();
$result = new stdclass;
// Comment the next line to have the 'right' behaviour
$stmt->bind_result($result->a);
for($i = 0; $i<10; ++$i)
{
$result->a = $i;
$results[] = clone $result;
}
foreach($results as $result)
echo $result->a,"\n";
$db->close();
?>

Expected result:

0
1
2
3
4
5
6
7
8
9

Actual result:
--
9
9
9
9
9
9
9
9
9
9





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

#28854 [Com]: Class and Vars

2004-06-21 Thread rodolfo at rodsoft dot org 
 ID:   28854
 Comment by:   rodolfo at rodsoft dot org
 Reported By:  toppi at kacke dot de
 Status:   Open
 Bug Type: *General Issues
 Operating System: linux/unix
 PHP Version:  5.0.0RC3
 New Comment:

The correct way to declare the member variables would be: 
var $a. This way, your example would be:
class a
{
   var $a;
   var $b;
   var $a;
}

which would give the correct fatal error:
Fatal error: Cannot redeclare a::$a in /var/www/htdocs/tst.php on line
5


Previous Comments:


[2004-06-20 16:27:55] toppi at kacke dot de

Description:

Class and Vars

Declare a var twice

Script breaks without error when including

Reproduce code:
---
class a {

var a;
var b;
var a;

function a(){
   //
}
}



Expected result:

any warning/error

Actual result:
--
script ends/break regular @ including-point





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

#28870 [NEW]: mysqli_bind_result doesn't work with cloned objects

2004-06-21 Thread rodolfo at rodsoft dot org 
From: rodolfo at rodsoft dot org
Operating system: linux 2.6.7
PHP version:  5.0.0RC3
PHP Bug Type: *Database Functions
Bug description:  mysqli_bind_result doesn't work with cloned objects

Description:

If you pass to mysqli_bind_result a member variable of an object that will
be cloned and modified multiple times, each modification happens in all
cloned objects, as if they weren't cloned copies, but a single copy of the
object.

Reproduce code:
---
select_db('test');
$stmt = $db->prepare('SELECT a FROM test');
$stmt->execute();
$result = new stdclass;
// Comment the next line to have the 'right' behaviour
$stmt->bind_result($result->a);
for($i = 0; $i<10; ++$i)
{
$result->a = $i;
$results[] = clone $result;
}
foreach($results as $result)
echo $result->a,"\n";
$db->close();
?>

Expected result:

0
1
2
3
4
5
6
7
8
9

Actual result:
--
9
9
9
9
9
9
9
9
9
9

-- 
Edit bug report at http://bugs.php.net/?id=28870&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=28870&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=28870&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=28870&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=28870&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28870&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=28870&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=28870&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28870&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=28870&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28870&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28870&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=28870&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28870&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=28870&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=28870&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28870&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28870&r=float

#28840 [NEW]: __destruct of a class that extends mysqli not called

2004-06-18 Thread rodolfo at rodsoft dot org 
From: rodolfo at rodsoft dot org
Operating system: linux 2.6.7
PHP version:  5.0.0RC3
PHP Bug Type: Zend Engine 2 problem
Bug description:  __destruct of a class that extends mysqli not called

Description:

When you create a class by extending mysqli or mysqli_result and add a
destructor to it (to automatically call mysqli::close, for instance), it
doesn't get called when the object gets out of scope.

Reproduce code:
---



Expected result:

born
died

Actual result:
--
born

-- 
Edit bug report at http://bugs.php.net/?id=28840&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=28840&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=28840&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=28840&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=28840&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28840&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=28840&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=28840&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28840&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=28840&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28840&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28840&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=28840&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28840&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=28840&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=28840&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28840&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28840&r=float

#28577 [Com]: mysqli doesn't compile

2004-06-11 Thread rodolfo at rodsoft dot org 
 ID:   28577
 Comment by:   rodolfo at rodsoft dot org
 Reported By:  mc at webheberg dot com
 Status:   Assigned
 Bug Type: Compile Failure
 Operating System: Linux Debian
 PHP Version:  5.0.0RC2
 Assigned To:  georg
 New Comment:

A quick fix would be to change line 193 of mysqli_prop.c 
from 

MYSQLI_MAP_PROPERTY_LONG_LONG(stmt_num_rows_read, STMT,
stmt->result->row_count);

to

MYSQLI_MAP_PROPERTY_LONG_LONG(stmt_num_rows_read, STMT,
stmt->result.rows);

Or, a better one, put the line 193 inside #if MYSQL_VERSION_ID < 40102,
and put the corrected line inside the #else. This way I hope it will
behave correctly with older versions of mysql.


Previous Comments:


[2004-05-31 12:11:05] [EMAIL PROTECTED]

Assigning to the maintainer.



[2004-05-30 13:25:33] mc at webheberg dot com

Description:

I'm trying to compile PHP5 with mysqli support. I've really tried all
what I can try. PHP5 RC1, RC2, with mysql 4.1.1, 4.1.2, 5.0.0, nothing
compiles.

For example :

./configure  --without-mysql
--with-mysqli=/src/mysql-standard-4.1.1-alpha-pc-linux-i686/bin/mysql_config

gives :

ext/mysqli/mysqli.o: In function `php_clear_stmt_bind':
/src/php-5.0.0RC2/ext/mysqli/mysqli.c:94: undefined reference to
`mysql_stmt_close'
ext/mysqli/mysqli_api.o: In function `zif_mysqli_autocommit':
/src/php-5.0.0RC2/ext/mysqli/mysqli_api.c:65: undefined reference to
`mysql_autocommit'
ext/mysqli/mysqli_api.o: In function `zif_mysqli_stmt_bind_param':
/src/php-5.0.0RC2/ext/mysqli/mysqli_api.c:174: undefined reference to
`mysql_stmt_bind_param'
ext/mysqli/mysqli_api.o: In function `zif_mysqli_stmt_bind_result':
/src/php-5.0.0RC2/ext/mysqli/mysqli_api.c:329: undefined reference to
`mysql_stmt_bind_result'

and so on 


With a source distrib of MySQL, it's not better :

./configure  --without-mysql
--with-mysqli=/usr/local/mysql/bin/mysql_config

=> it gives BUG #28376


So i've found a tip to compile, it's not very clean but it works :

./configure  --without-mysql
--with-mysqli=/src/mysql-standard-4.1.1-alpha-pc-linux-i686/bin/mysql_config
make
(let the error come)
./configure  --without-mysql
--with-mysqli=/usr/local/mysql/bin/mysql_config
make
make install


Well, finally, isnt there a serious problem with mysqli ??








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

#28743 [NEW]: array_udiff dumps core

2004-06-11 Thread rodolfo at rodsoft dot org 
From: rodolfo at rodsoft dot org
Operating system: linux 2.6.6
PHP version:  5.0.0RC2
PHP Bug Type: Reproducible crash
Bug description:  array_udiff dumps core

Description:

If you run the following script with your web browser and reload the page
a couple of times, php dumps core. My apache version is 2.0.49 with libphp
dynamically linked.

Strangely enough, if you change the array index inside the create_function
to something bogus, like "d", array_udiff returns an empty array (without
issuing an error). The second time the script is called, as usual, php
dumps core. With the correct array index, the output is ok the first time.
But dumps core the second time is called.

Reproduce code:
---
1, 'b'=>'apple');
$p1[] = array('a'=>2, 'b'=>'orange');
$p1[] = array('a'=>3, 'b'=>'banana');
$p2[] = array('a'=>3, 'b'=>'banana');
$p2[] = array('a'=>4, 'b'=>'raspberry');

echo "";
print_r(array_udiff($p1, $p2,create_function('$a,$b',
'return $a["a"]-$b["a"];')));
echo "";
?>

Expected result:

Array
(
[0] => Array
(
[a] => 1
[b] => apple
)

[1] => Array
(
[a] => 2
[b] => orange
)
)

no matter how many times we run the script

Actual result:
--
The correct result in the first time the script is run, and the following
core dump backtrace the second time:

#0 0x0001 in ?? ()
#1 0x4072bc0a in zend_call_function () from /usr/lib/apache/libphp5.so
#2 0x4067dd81 in array_user_compare () from /usr/lib/apache/libphp5.so
#3 0x407458c9 in zend_qsort() from /usr/lib/apache/libphp5.so
#4 0x40684a19 in php_array_diff () from /usr/lib/apache/libphp5.so
#5 0x0003 in ?? ()
#6 0x0004 in ?? ()
#7 0x4067dcf0 in zif_rsort() from /usr/lib/apache/libphp5.so
Previous frame inner to this frame (corrupt stack?)

-- 
Edit bug report at http://bugs.php.net/?id=28743&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=28743&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=28743&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=28743&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=28743&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28743&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=28743&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=28743&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28743&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=28743&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28743&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28743&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=28743&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28743&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=28743&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=28743&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28743&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28743&r=float

#28739 [Opn]: uasort and array_udiff doesn't work together

2004-06-11 Thread rodolfo at rodsoft dot org 
 ID:   28739
 User updated by:  rodolfo at rodsoft dot org
 Reported By:  rodolfo at rodsoft dot org
 Status:   Open
 Bug Type: Arrays related
 Operating System: linux 2.6.6
 PHP Version:  5.0.0RC2
 New Comment:

This problem apparently is in uasort. If you change uasort for, say,
uksort (and make code changes accordingly), the problem disappears.


Previous Comments:


[2004-06-11 08:32:38] rodolfo at rodsoft dot org

Description:

If you call uasort with one callback function and then call array_udiff
with another callback function, this last call will use first's
callback. If we first call array_udiff and then call uasort, everything
goes well.


Reproduce code:
---
x=$x;}
}
function a(&$a, &$b){return $a->x - $b->x;}
function b(&$a, &$b){return $a->y - $b->y;}

$p1 = array(new p(2), new p(1), new p(0));
$p2 = array(new p(0), new p(2), new p(3));

uasort($p1, 'a');
print_r($p1);
echo "\n";
print_r(array_udiff($p1,$p2, 'b')); 
?>

Expected result:

Notice: Undefined property: p::$y in tst.php on line 8

Actual result:
--
Array
(
[2] => p Object
(
[x] => 0
)

[1] => p Object
(
[x] => 1
)

[0] => p Object
(
[x] => 2
)

)
Array
(
[1] => p Object
(
[x] => 1
)

)





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

#28739 [NEW]: uasort and array_udiff doesn't work together

2004-06-10 Thread rodolfo at rodsoft dot org 
From: rodolfo at rodsoft dot org
Operating system: linux 2.6.6
PHP version:  5.0.0RC2
PHP Bug Type: Arrays related
Bug description:  uasort and array_udiff doesn't work together

Description:

If you call uasort with one callback function and then call array_udiff
with another callback function, this last call will use first's callback.
If we first call array_udiff and then call uasort, everything goes well.


Reproduce code:
---
x=$x;}
}
function a(&$a, &$b){return $a->x - $b->x;}
function b(&$a, &$b){return $a->y - $b->y;}

$p1 = array(new p(2), new p(1), new p(0));
$p2 = array(new p(0), new p(2), new p(3));

uasort($p1, 'a');
print_r($p1);
echo "\n";
print_r(array_udiff($p1,$p2, 'b')); 
?>

Expected result:

Notice: Undefined property: p::$y in tst.php on line 8

Actual result:
--
Array
(
[2] => p Object
(
[x] => 0
)

[1] => p Object
(
[x] => 1
)

[0] => p Object
(
[x] => 2
)

)
Array
(
[1] => p Object
(
[x] => 1
)

)

-- 
Edit bug report at http://bugs.php.net/?id=28739&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=28739&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=28739&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=28739&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=28739&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28739&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=28739&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=28739&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28739&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=28739&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28739&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28739&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=28739&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28739&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=28739&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=28739&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28739&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28739&r=float

#28713 [Bgs]: crash in recursive call of __call

2004-06-10 Thread rodolfo at rodsoft dot org 
 ID:   28713
 User updated by:  rodolfo at rodsoft dot org
 Reported By:  rodolfo at rodsoft dot org
 Status:   Bogus
 Bug Type: Reproducible crash
 Operating System: linux 2.6.6
 PHP Version:  5.0.0RC2
 New Comment:

You're right, but the __set and __get functions manage to get around
this problem by not allowing you to access an undefined property inside
them (which would cause recursive calling of itself). Wouldn't it be
logical to extend this behaviour to __call, not allowing one to call an
undefined member inside it? The way it is now can lead to situations
like this:

class myclass
{
function test() {} // Comment this line out and php
   // will crash. Very hard bug to trace
   // when working on a big class.

function __call($func, $args)
{
$this->test();
}
};


Previous Comments:


[2004-06-10 08:58:15] [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

The only way in which PHP is allowed to crash is in this case:
unlimited recursive calling of functions. 



[2004-06-09 20:05:35] rodolfo at rodsoft dot org

Description:

This ill-behaved code crashes php. I know one should never write things
like this, but this sample is an oversimplified version of a much
bigger code I'm working with, and I've just spot my error after trying
to simplify the code to attach here. PHP should emmit a warning when
such things happen, as with __set and __get, saying that $this->func()
isn't defined, when called inside a __call handler.

Reproduce code:
---
hello();
}
}

$a = new test;
$a->hello();
echo "You won't read this";

?>


Expected result:

A warning saying that $this->hello isn't defined.

Actual result:
--
The coredump is a bunch of

#0 0x0821d843 in zend_call_function ()
#1 0x0821e76a in call_user_function_ex ()
#2 0x0823cfa5 in zend_std_call_user_call ()
#3 0x0825f8ee in zend_do_fcall_common_helper ()
#4 0x0825faf1 in zend_do_fcall_by_name_handler ()
#5 0x0824daf8 in execute ()

repeated over and over





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

#28713 [NEW]: crash in recursive call of __call

2004-06-09 Thread rodolfo at rodsoft dot org 
From: rodolfo at rodsoft dot org
Operating system: linux 2.6.6
PHP version:  5.0.0RC2
PHP Bug Type: Reproducible crash
Bug description:  crash in recursive call of __call

Description:

This ill-behaved code crashes php. I know one should never write things
like this, but this sample is an oversimplified version of a much bigger
code I'm working with, and I've just spot my error after trying to
simplify the code to attach here. PHP should emmit a warning when such
things happen, as with __set and __get, saying that $this->func() isn't
defined, when called inside a __call handler.

Reproduce code:
---
hello();
}
}

$a = new test;
$a->hello();
echo "You won't read this";

?>


Expected result:

A warning saying that $this->hello isn't defined.

Actual result:
--
The coredump is a bunch of

#0 0x0821d843 in zend_call_function ()
#1 0x0821e76a in call_user_function_ex ()
#2 0x0823cfa5 in zend_std_call_user_call ()
#3 0x0825f8ee in zend_do_fcall_common_helper ()
#4 0x0825faf1 in zend_do_fcall_by_name_handler ()
#5 0x0824daf8 in execute ()

repeated over and over

-- 
Edit bug report at http://bugs.php.net/?id=28713&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=28713&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=28713&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=28713&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=28713&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28713&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=28713&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=28713&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28713&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=28713&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28713&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28713&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=28713&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28713&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=28713&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=28713&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28713&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28713&r=float