Req #60568 [Opn]: String arguments for func_get_arg() as well as func_has_arg()
Edit report at https://bugs.php.net/bug.php?id=60568edit=1
ID: 60568
User updated by:dan dot lugg at gmail dot com
Reported by:dan dot lugg at gmail dot com
Summary:String arguments for func_get_arg() as well as
func_has_arg()
Status: Open
Type: Feature/Change Request
Package:Reflection related
Operating System: Not Relevant
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
To expand on the func_has_arg() functionality -- As in the case of
func_get_arg(),
func_has_arg() should return FALSE for non-supplied arguments, regardless of
any
default values:
function test($foo, $bar = null){
var_dump(func_has_arg(0));
var_dump(func_has_arg('foo'));
var_dump(func_has_arg(1));
var_dump(func_has_arg('bar'));
}
test('hello');
// bool(true)
// bool(true)
// bool(false)
// bool(false)
Previous Comments:
[2011-12-20 03:37:46] dan dot lugg at gmail dot com
Description:
The following are my proposals:
func_get_arg($arg_num) should support string arguments. A given string argument
should correspond to the parameter name:
function test($foo){
var_dump(func_get_arg(0));
var_dump(func_get_arg('foo'));
}
test('hello');
// string(5) hello
// string(5) hello
As well, an additional function should be added; func_has_arg($arg_num_or_name)
which will *not* throw warnings when an out-of-bounds argument is passed. It
should accept the same argument types of int|string as func_get_arg()
function test($foo){
var_dump(func_has_arg(0));
var_dump(func_has_arg('foo'));
var_dump(func_has_arg(1));
var_dump(func_has_arg('bar'));
}
test('hello');
// bool(true)
// bool(true)
// bool(false)
// bool(false)
I find that without this functionality, it is very difficult to determine
whether or not an argument has in fact been passed in some circumstances. This
issue was brought to light when I was attempting to test for an optional
argument intended to be passed by reference.
Like the preg_* family of functions, the optional parameter by reference would
be populated with values under certain conditions of the function call. The
parameter was declared with a default value of NULL. The issue is, when passing
a previously undefined variable as an argument to this function, it has the
inherent value of NULL, making is_null($arg) fail.
One may consider unconditionally populating the variable with results, however
if the process to generate these results is expensive, then there would be a
clear advantage to testing whether the client-code has explicitly requested the
results before proceeding with the necessary process.
My colleagues and I have determined that some solutions may include:
- Adding an additional boolean flag argument to a given function, and proceed
with populating the referenced variable on a TRUE condition.
- Checking instead, the number of arguments passed with func_num_args().
- Generating some arbitrary value with low possibility of collision, defining
it as a constant, and using that as a default.
Unfortunately, these solutions are mere work-arounds. The additional boolean
flag lengthens the parameter list unnecessarily. Checking the number of passed
arguments couples the check to the parameter count. The arbitrary default value
is fraught with issues from collision to maintenance and overhead.
These issues would be mitigated by supporting string arguments to
func_get_arg()
and the proposed func_has_arg(), by decoupling the functions from parameter
count/order through the support for named parameter queries, as well as
allowing
for a genuine check of whether an argument was in fact passed (regardless of
value, default or not).
--
Edit this bug report at https://bugs.php.net/bug.php?id=60568edit=1
[PHP-BUG] Bug #60572 [NEW]: Can't make a optional callback arguments in extension
From: laruence
Operating system:
PHP version: 5.3.8
Package: *General Issues
Bug Type: Bug
Bug description:Can't make a optional callback arguments in extension
Description:
following codes in extension didn't work as expected:
zend_fcall_info fci = {0};
zend_fcall_info_cache fci_cache;
...
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, s|f, key,
klen,
fci, fci_cache) {
return;
}
if (!fci.size) {
// not a valid callback
}
in PHP script:
php_ext_function(name, NULL);
result in:
argument 2 not a valid callback...
I haved tried set the arginfo with all_null.
--
Edit bug report at https://bugs.php.net/bug.php?id=60572edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60572r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60572r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60572r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60572r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60572r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60572r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60572r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60572r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60572r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60572r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60572r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60572r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60572r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60572r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60572r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60572r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60572r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60572r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60572r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60572r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60572r=mysqlcfg
[PHP-BUG] Req #60573 [NEW]: type hinting with self keyword causes weird errors
From:
Operating system: *nix
PHP version: 5.3.8
Package: Scripting Engine problem
Bug Type: Feature/Change Request
Bug description:type hinting with self keyword causes weird errors
Description:
self should be thought as the class where the keyword is written in.
Here is then a strange behavior using inheritance :
Test script:
---
class Foo {
public function setSelf(self $s) { }
}
class Bar extends Foo {
public function setSelf(self $s) { }
}
Expected result:
Strict Standards as Bar::setself() signature doesn't respect Foo::setSelf()
signature.
Foo's one has a type hint on Foo (using self keyword), but Bar's one on Bar
(still using self keyword) : the methods then have a signature mismatch,
and PHP
should complain about that
Actual result:
--
Nothing happens.
Trying this gives the correct E_STRICT error, correct behavior :
class Foo {
public function setSelf(Foo $s) { }
}
class Bar extends Foo {
public function setSelf(Bar $s) { }
}
--
Edit bug report at https://bugs.php.net/bug.php?id=60573edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60573r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60573r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60573r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60573r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60573r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60573r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60573r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60573r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60573r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60573r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60573r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60573r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60573r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60573r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60573r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60573r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60573r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60573r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60573r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60573r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60573r=mysqlcfg
[PHP-BUG] Bug #60574 [NEW]: range() returns array of integers when arguments are numeric strings
From:
Operating system: Windows 7
PHP version: 5.3.8
Package: Scripting Engine problem
Bug Type: Bug
Bug description:range() returns array of integers when arguments are numeric
strings
Description:
Hi.
I think the 'range()' function should return an array with strings, if the
'start' and 'limit' arguments are numeric strings. Otherwise it should be
mentioned in the documentation.
Test script:
---
?php
var_dump(range('0', '9'));
Expected result:
array(10) {
[0]= string(1) 0
[1]= string(1) 1
[2]= string(1) 2
[3]= string(1) 3
[4]= string(1) 4
[5]= string(1) 5
[6]= string(1) 6
[7]= string(1) 7
[8]= string(1) 8
[9]= string(1) 9
}
Actual result:
--
array(10) {
[0]= int(0)
[1]= int(1)
[2]= int(2)
[3]= int(3)
[4]= int(4)
[5]= int(5)
[6]= int(6)
[7]= int(7)
[8]= int(8)
[9]= int(9)
}
--
Edit bug report at https://bugs.php.net/bug.php?id=60574edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60574r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60574r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60574r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60574r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60574r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60574r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60574r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60574r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60574r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60574r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60574r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60574r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60574r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60574r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60574r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60574r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60574r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60574r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60574r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60574r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60574r=mysqlcfg
[PHP-BUG] Req #60575 [NEW]: Provide a way to feed error_get_last() from custom error handler
From:
Operating system:
PHP version: Irrelevant
Package: *General Issues
Bug Type: Feature/Change Request
Bug description:Provide a way to feed error_get_last() from custom error handler
Description:
When you write a custom error handler to be used with set_error_handler(),
the error_get_last() function is no longer usable (always returns NULL)
unless you make your handler return FALSE (the internal variables required
are filled by the builtin error handler).
There should be a mechanism to feed the required error info from custom
error handler so error_get_last() can be made available.
Test script:
---
?php
function custom_error_handler($errno, $errstr, $errfile, $errline){
$ignore = ($errno error_reporting()) == 0;
if(!$ignore){
echo [Error happened: $errstr]\n;
}
return TRUE;
}
set_error_handler('custom_error_handler');
@fopen('xxx');
var_dump( error_get_last() ); // NULL
Expected result:
array(4) {
[type]=
int(2)
[message]=
string(46) fopen() expects at least 2 parameters, 1 given
[file]=
string(15) C:\tmp\test.php
[line]=
int(11)
}
Actual result:
--
NULL
--
Edit bug report at https://bugs.php.net/bug.php?id=60575edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60575r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60575r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60575r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60575r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60575r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60575r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60575r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60575r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60575r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60575r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60575r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60575r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60575r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60575r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60575r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60575r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60575r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60575r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60575r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60575r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60575r=mysqlcfg
Req #60573 [Opn]: type hinting with self keyword causes weird errors
Edit report at https://bugs.php.net/bug.php?id=60573edit=1
ID: 60573
Updated by: larue...@php.net
Reported by:jpa...@php.net
Summary:type hinting with self keyword causes weird errors
Status: Open
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: *nix
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
This is really a tough one, think about following:
?php
class Foo {
public function setSelf(self $s) { }
}
class Bar extends Foo {
public function setSelf(parent $s) { }
}
?
-
?php
class Foo {
public function setSelf(Foo $s) { }
}
class Bar extends Foo {
public function setSelf(parent $s) { }
}
---
?php
class Base {
}
class Foo extends Base{
public function setSelf(parent $s) { }
}
class Bar extends Foo {
public function setSelf(Base $s) { }
}
and more...
Previous Comments:
[2011-12-20 10:56:31] jpa...@php.net
Description:
self should be thought as the class where the keyword is written in.
Here is then a strange behavior using inheritance :
Test script:
---
class Foo {
public function setSelf(self $s) { }
}
class Bar extends Foo {
public function setSelf(self $s) { }
}
Expected result:
Strict Standards as Bar::setself() signature doesn't respect Foo::setSelf()
signature.
Foo's one has a type hint on Foo (using self keyword), but Bar's one on Bar
(still using self keyword) : the methods then have a signature mismatch, and
PHP
should complain about that
Actual result:
--
Nothing happens.
Trying this gives the correct E_STRICT error, correct behavior :
class Foo {
public function setSelf(Foo $s) { }
}
class Bar extends Foo {
public function setSelf(Bar $s) { }
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60573edit=1
Req #60573 [Asn-Opn]: type hinting with self keyword causes weird errors
Edit report at https://bugs.php.net/bug.php?id=60573edit=1
ID: 60573
Updated by: larue...@php.net
Reported by:jpa...@php.net
Summary:type hinting with self keyword causes weird errors
-Status: Assigned
+Status: Open
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: *nix
PHP Version:5.3.8
Assigned To:laruence
Block user comment: N
Private report: N
Previous Comments:
[2011-12-20 12:31:44] larue...@php.net
This is really a tough one, think about following:
?php
class Foo {
public function setSelf(self $s) { }
}
class Bar extends Foo {
public function setSelf(parent $s) { }
}
?
-
?php
class Foo {
public function setSelf(Foo $s) { }
}
class Bar extends Foo {
public function setSelf(parent $s) { }
}
---
?php
class Base {
}
class Foo extends Base{
public function setSelf(parent $s) { }
}
class Bar extends Foo {
public function setSelf(Base $s) { }
}
and more...
[2011-12-20 10:56:31] jpa...@php.net
Description:
self should be thought as the class where the keyword is written in.
Here is then a strange behavior using inheritance :
Test script:
---
class Foo {
public function setSelf(self $s) { }
}
class Bar extends Foo {
public function setSelf(self $s) { }
}
Expected result:
Strict Standards as Bar::setself() signature doesn't respect Foo::setSelf()
signature.
Foo's one has a type hint on Foo (using self keyword), but Bar's one on Bar
(still using self keyword) : the methods then have a signature mismatch, and
PHP
should complain about that
Actual result:
--
Nothing happens.
Trying this gives the correct E_STRICT error, correct behavior :
class Foo {
public function setSelf(Foo $s) { }
}
class Bar extends Foo {
public function setSelf(Bar $s) { }
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60573edit=1
Req #60573 [Asn]: type hinting with self keyword causes weird errors
Edit report at https://bugs.php.net/bug.php?id=60573edit=1
ID: 60573
Updated by: larue...@php.net
Reported by:jpa...@php.net
Summary:type hinting with self keyword causes weird errors
Status: Assigned
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: *nix
PHP Version:5.3.8
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
I have a patch now, will apply it after do careful testings
Previous Comments:
[2011-12-20 12:31:44] larue...@php.net
This is really a tough one, think about following:
?php
class Foo {
public function setSelf(self $s) { }
}
class Bar extends Foo {
public function setSelf(parent $s) { }
}
?
-
?php
class Foo {
public function setSelf(Foo $s) { }
}
class Bar extends Foo {
public function setSelf(parent $s) { }
}
---
?php
class Base {
}
class Foo extends Base{
public function setSelf(parent $s) { }
}
class Bar extends Foo {
public function setSelf(Base $s) { }
}
and more...
[2011-12-20 10:56:31] jpa...@php.net
Description:
self should be thought as the class where the keyword is written in.
Here is then a strange behavior using inheritance :
Test script:
---
class Foo {
public function setSelf(self $s) { }
}
class Bar extends Foo {
public function setSelf(self $s) { }
}
Expected result:
Strict Standards as Bar::setself() signature doesn't respect Foo::setSelf()
signature.
Foo's one has a type hint on Foo (using self keyword), but Bar's one on Bar
(still using self keyword) : the methods then have a signature mismatch, and
PHP
should complain about that
Actual result:
--
Nothing happens.
Trying this gives the correct E_STRICT error, correct behavior :
class Foo {
public function setSelf(Foo $s) { }
}
class Bar extends Foo {
public function setSelf(Bar $s) { }
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60573edit=1
Bug #60572 [Opn-Bgs]: Can't make a optional callback arguments in extension
Edit report at https://bugs.php.net/bug.php?id=60572edit=1
ID: 60572
Updated by: cataphr...@php.net
Reported by:larue...@php.net
Summary:Can't make a optional callback arguments in
extension
-Status: Open
+Status: Bogus
Type: Bug
Package:*General Issues
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Optional means accepting the argument was not given, not accepting a NULL.
To accept NULLs, you have to use !, otherwise the argument is coerced to
whatever type you're expecting, which is not possible here.
so
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, s|f!, key, klen,
fci, fci_cache) {
Previous Comments:
[2011-12-20 09:52:59] larue...@php.net
Description:
following codes in extension didn't work as expected:
zend_fcall_info fci = {0};
zend_fcall_info_cache fci_cache;
...
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, s|f, key, klen,
fci, fci_cache) {
return;
}
if (!fci.size) {
// not a valid callback
}
in PHP script:
php_ext_function(name, NULL);
result in:
argument 2 not a valid callback...
I haved tried set the arginfo with all_null.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60572edit=1
Bug #60572 [Bgs]: Can't make a optional callback arguments in extension
Edit report at https://bugs.php.net/bug.php?id=60572edit=1
ID: 60572
Updated by: larue...@php.net
Reported by:larue...@php.net
Summary:Can't make a optional callback arguments in
extension
Status: Bogus
Type: Bug
Package:*General Issues
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
ah, thanks cataphract.
Previous Comments:
[2011-12-20 13:17:38] cataphr...@php.net
Optional means accepting the argument was not given, not accepting a NULL.
To accept NULLs, you have to use !, otherwise the argument is coerced to
whatever type you're expecting, which is not possible here.
so
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, s|f!, key, klen,
fci, fci_cache) {
[2011-12-20 09:52:59] larue...@php.net
Description:
following codes in extension didn't work as expected:
zend_fcall_info fci = {0};
zend_fcall_info_cache fci_cache;
...
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, s|f, key, klen,
fci, fci_cache) {
return;
}
if (!fci.size) {
// not a valid callback
}
in PHP script:
php_ext_function(name, NULL);
result in:
argument 2 not a valid callback...
I haved tried set the arginfo with all_null.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60572edit=1
Bug #60535 [Opn]: php ends prematurely when reading from pipe
Edit report at https://bugs.php.net/bug.php?id=60535edit=1 ID: 60535 User updated by:andreas_nordal_4 at hotmail dot com Reported by:andreas_nordal_4 at hotmail dot com Summary:php ends prematurely when reading from pipe Status: Open Type: Bug Package:*General Issues Operating System: Windows 7 Enterprise SP1 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: I think I can reproduce bug 26271. I had to modify the testcase, by setting the second argument of str_repeat 10 times higher, and adding the suggested sleep. I don't get a parse error, but the amount of sleep after proc_open determines the returnvalue of fwrite. If not sleeping, I always get 8192 no matter the argument to str_repeat. Previous Comments: [2011-12-16 16:30:41] cataphr...@php.net Maybe this is the same as bug #52911. Can you check it out? If so, this should be marked a duplicate. [2011-12-15 15:26:26] andreas_nordal_4 at hotmail dot com Description: I am using the command-line `php` program in a bash script to generate a html file, like so: # stage 1: intermediate=$(php doc.php) # stage 2: echo $intermediate | php doc.html Stage 2 doesn't work on Windows when doc.html gets big (observed sizes in bytes: 42033, 42079, 41989, 42856, 41924). Php just ends prematurely, without printing any error message to either standard error or out. The size of doc.html is consistent every time I try, but depends on, at least, the amount of static content (between ? an, d ?) in $intermediate. The output always ends on a linefeed. I also tried piping a pure html file of size 32597 (https://bugs.php.net/report.php) through php in similar fashion. This time, the output size was inconsistent. Mostly, it was truncated to 16423, sometimes not truncated, and once truncated to 8945. Absurdly, this workaround works: echo $intermediate | tee intermediate.php; cat intermediate.php | php doc.html The fact that tee is able to read everything from the same pipe, and php succeeds when its input comes from cat, makes me think this is php's fault (likely a timing issue) rather than bash. Of course, I might be wrong. The same bash script works flawlessly on Linux. I have php version 5.3.8 both on Linux and Windows. The installer I used on Windows is named php-5.3.8-Win32-VC9-x86.msi, has filesize 40300544 and md5sum 2eacd59df8d6b46d5538f2935514d77b. This bug might explain bug 26271 (which deals with named pipes): In his case, I can imagine that the writer would hang if the reader ends prematurely. Just speculating. -- Edit this bug report at https://bugs.php.net/bug.php?id=60535edit=1
Req #60364 [Opn]: Implement ability to recover from fatal errors in eval()'d code
Edit report at https://bugs.php.net/bug.php?id=60364edit=1
ID: 60364
User updated by:zyss at mail dot zp dot ua
Reported by:zyss at mail dot zp dot ua
Summary:Implement ability to recover from fatal errors in
eval()'d code
Status: Open
Type: Feature/Change Request
Package:*General Issues
Operating System: All
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
This could be solved more straight forward solved by making fatal errors an
Exception in PHP
Yes, that would be ideal (this is how Java handles missing classes and methods
and it works just fine).
PHP borrowed from Java many features (classes, interfaces, instanceof, ...),
why not to implement one more useful thing â not to kill scripts when
something is missing?
Previous Comments:
[2011-12-20 03:46:08] hanskrentel at yahoo dot de
Why specific for eval and not include and/or overal?
This could be solved more straight forward solved by making fatal errors an
Exception in PHP, like suggested in #28331 (which names eval in a comment as a
use-case).
[2011-11-23 13:27:35] zyss at mail dot zp dot ua
Description:
Sometimes eval() is used as a way to execute PHP code within a shell (legal
remote access for debugging purposes) or to execute code compiled to PHP from
higher-level scripting language or the code stored in the database etc.
The common problem is that a call of non-existing function (or object
instantiation) results in termination of the whole script, not just eval'd code.
I think that it's not correct in such cases.
The obvious way to implement it would be adding flags to eval() function (as a
second argument) one of which could indicate that eval() should not terminate
the script but just return an error or raise an exception.
Such flags could be:
EVAL_FATAL_DIE// current behavior
EVAL_FATAL_ERROR // return FALSE
EVAL_FATAL_EXCEPTION // raise an exception of a predefined class (e.g.
EvalException)
Test script:
---
try {
eval('non_existing_function()', EVAL_FATAL_EXCEPTION);
}
catch (EvalException $e) {
Logger::log('Error in eval\'d code', $e);
}
Expected result:
Exception being logged and script continued its execution.
Actual result:
--
Fatal error: Call to undefined function non_existing_function() in ... :
eval()'d code(1) on line 1
--
Edit this bug report at https://bugs.php.net/bug.php?id=60364edit=1
[PHP-BUG] Bug #60576 [NEW]: PHP cURL crash connecting to IIS6 website with NTLM authentication
From:
Operating system: Windows Server 2003/XP/7 (32/64)
PHP version: 5.3.8
Package: cURL related
Bug Type: Bug
Bug description:PHP cURL crash connecting to IIS6 website with NTLM
authentication
Description:
If one connects to an IIS 6 website configured with Windows
Authentication
without the correct authentication credentials and authentication type set
one would expect the PHP code (see sample code) to return the HTTP status
code 401 and exit normally.
This is the behaviour as seen with PHP 5.3.6. For the version 5.3.7/5.3.8
(and
also tested with the snapshot 5.3 r321148) the PHP process crashes with an
access violation (see backtrace). Only if correct authentication
credentials are given and the cURL option CURLOPT_HTTPAUTH is set to
CURLAUTH_NTLM (CURLAUTH_ANY or CURLAUTH_ANYSAFE will not work!) the script
terminates successfully and returns the content of the then authenticated
request.
The behaviour is not limited to requests to localhost (as in the sample
code) and a request to an IIS 7 website with Windows Authentication will
show the expected result (status 401 - no access violation).
Test script:
---
?php
$curl = curl_init(http://localhost;);
curl_setopt($curl, CURLOPT_VERBOSE, true);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
// if the authentication information are not given
// in exactly this way the process will crash with
// an access violation.
//curl_setopt($curl, CURLOPT_HTTPAUTH, CURLAUTH_NTLM);
//curl_setopt($curl, CURLOPT_USERPWD, 'domain/user:password');
$data = curl_exec($curl);
if(curl_errno($curl)) {
echo 'cURL error: ' . curl_error($curl).\n;
}
curl_close($curl);
Expected result:
* About to connect() to localhost port 80 (#0)
* Trying 127.0.0.1... * connected
* Connected to localhost (127.0.0.1) port 80 (#0)
GET / HTTP/1.1
Host: localhost
Accept: */*
HTTP/1.1 401 Unauthorized
Content-Length: 1656
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
Date: Tue, 20 Dec 2011 15:17:01 GMT
* Connection #0 to host localhost left intact
* Closing connection #0
Actual result:
--
hread 0 - System ID 836
Entry point php!mainCRTStartup
Create time 20.12.2011 15:59:09
Time spent in user mode 0 Days 0:0:0.0
Time spent in kernel mode 0 Days 0:0:0.62
.NET Call Stack
Full Call Stack
Function Arg 1 Arg 2 Arg 3 Source
wow64!Wow64NotifyDebugger+9 6b0064f2
wow64!Wow64KiRaiseException+172 6b006866 0140d730
wow64!Wow64SystemServiceEx+d6 78b83c7d
wow64cpu!ServiceNoTurbo+28 6b006a5a 7efdf000
wow64!RunCpuSimulation+a 6b005e0d
wow64!Wow64LdrpInitialize+2ed 77ed7a00 00c0f710
ntdll!LdrpInitializeProcess+1558 77ed519f
ntdll!LdrpInitialize+18f 77ef2af5
ntdll!KiUserApcDispatcher+15
0x77d59680
Exception Information
PHP_CURL!CURL_INPUT_NEGOTIATE+104In
php__PID__2880__Date__12_20_2011__Time_04_02_22PM__536__Second_Chance_Exception_C005.dmp
the assembly instruction at
php_curl!Curl_input_negotiate+104 in
C:\home\PHP\php-5.3-nts-windows-vc9-x86-r321148\ext\php_curl.dll from The
PHP Group
has caused an access violation exception (0xC005) when trying to read
from memory
location 0x0044 on thread 0
--
Edit bug report at https://bugs.php.net/bug.php?id=60576edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60576r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60576r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60576r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60576r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60576r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60576r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60576r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60576r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60576r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60576r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60576r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60576r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60576r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60576r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60576r=php4
Daylight Savings:
Req #60573 [PATCH]: type hinting with self keyword causes weird errors
Edit report at https://bugs.php.net/bug.php?id=60573edit=1
ID: 60573
Patch added by: larue...@php.net
Reported by:jpa...@php.net
Summary:type hinting with self keyword causes weird errors
Status: Assigned
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: *nix
PHP Version:5.3.8
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug60573.patch
Revision: 1324396875
URL:
https://bugs.php.net/patch-display.php?bug=60573patch=bug60573.patchrevision=1324396875
Previous Comments:
[2011-12-20 12:53:38] larue...@php.net
I have a patch now, will apply it after do careful testings
[2011-12-20 12:31:44] larue...@php.net
This is really a tough one, think about following:
?php
class Foo {
public function setSelf(self $s) { }
}
class Bar extends Foo {
public function setSelf(parent $s) { }
}
?
-
?php
class Foo {
public function setSelf(Foo $s) { }
}
class Bar extends Foo {
public function setSelf(parent $s) { }
}
---
?php
class Base {
}
class Foo extends Base{
public function setSelf(parent $s) { }
}
class Bar extends Foo {
public function setSelf(Base $s) { }
}
and more...
[2011-12-20 10:56:31] jpa...@php.net
Description:
self should be thought as the class where the keyword is written in.
Here is then a strange behavior using inheritance :
Test script:
---
class Foo {
public function setSelf(self $s) { }
}
class Bar extends Foo {
public function setSelf(self $s) { }
}
Expected result:
Strict Standards as Bar::setself() signature doesn't respect Foo::setSelf()
signature.
Foo's one has a type hint on Foo (using self keyword), but Bar's one on Bar
(still using self keyword) : the methods then have a signature mismatch, and
PHP
should complain about that
Actual result:
--
Nothing happens.
Trying this gives the correct E_STRICT error, correct behavior :
class Foo {
public function setSelf(Foo $s) { }
}
class Bar extends Foo {
public function setSelf(Bar $s) { }
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60573edit=1
Req #60573 [PATCH]: type hinting with self keyword causes weird errors
Edit report at https://bugs.php.net/bug.php?id=60573edit=1
ID: 60573
Patch added by: larue...@php.net
Reported by:jpa...@php.net
Summary:type hinting with self keyword causes weird errors
Status: Assigned
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: *nix
PHP Version:5.3.8
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug60573.phpt
Revision: 1324396902
URL:
https://bugs.php.net/patch-display.php?bug=60573patch=bug60573.phptrevision=1324396902
Previous Comments:
[2011-12-20 16:01:15] larue...@php.net
The following patch has been added/updated:
Patch Name: bug60573.patch
Revision: 1324396875
URL:
https://bugs.php.net/patch-display.php?bug=60573patch=bug60573.patchrevision=1324396875
[2011-12-20 12:53:38] larue...@php.net
I have a patch now, will apply it after do careful testings
[2011-12-20 12:31:44] larue...@php.net
This is really a tough one, think about following:
?php
class Foo {
public function setSelf(self $s) { }
}
class Bar extends Foo {
public function setSelf(parent $s) { }
}
?
-
?php
class Foo {
public function setSelf(Foo $s) { }
}
class Bar extends Foo {
public function setSelf(parent $s) { }
}
---
?php
class Base {
}
class Foo extends Base{
public function setSelf(parent $s) { }
}
class Bar extends Foo {
public function setSelf(Base $s) { }
}
and more...
[2011-12-20 10:56:31] jpa...@php.net
Description:
self should be thought as the class where the keyword is written in.
Here is then a strange behavior using inheritance :
Test script:
---
class Foo {
public function setSelf(self $s) { }
}
class Bar extends Foo {
public function setSelf(self $s) { }
}
Expected result:
Strict Standards as Bar::setself() signature doesn't respect Foo::setSelf()
signature.
Foo's one has a type hint on Foo (using self keyword), but Bar's one on Bar
(still using self keyword) : the methods then have a signature mismatch, and
PHP
should complain about that
Actual result:
--
Nothing happens.
Trying this gives the correct E_STRICT error, correct behavior :
class Foo {
public function setSelf(Foo $s) { }
}
class Bar extends Foo {
public function setSelf(Bar $s) { }
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60573edit=1
Req #60573 [Com]: type hinting with self keyword causes weird errors
Edit report at https://bugs.php.net/bug.php?id=60573edit=1
ID: 60573
Comment by: larue...@php.net
Reported by:jpa...@php.net
Summary:type hinting with self keyword causes weird errors
Status: Assigned
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: *nix
PHP Version:5.3.8
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
a patch for php 5.4 was submitted, since 5.4 will generate detailed info about
the
prototype argument list, so this defect is more significant for 5.4.
and Tyrael suggest commit this only after 5.4.0 release. so leave this open, I
will commit later.
thanks
Previous Comments:
[2011-12-20 16:01:42] larue...@php.net
The following patch has been added/updated:
Patch Name: bug60573.phpt
Revision: 1324396902
URL:
https://bugs.php.net/patch-display.php?bug=60573patch=bug60573.phptrevision=1324396902
[2011-12-20 16:01:15] larue...@php.net
The following patch has been added/updated:
Patch Name: bug60573.patch
Revision: 1324396875
URL:
https://bugs.php.net/patch-display.php?bug=60573patch=bug60573.patchrevision=1324396875
[2011-12-20 12:53:38] larue...@php.net
I have a patch now, will apply it after do careful testings
[2011-12-20 12:31:44] larue...@php.net
This is really a tough one, think about following:
?php
class Foo {
public function setSelf(self $s) { }
}
class Bar extends Foo {
public function setSelf(parent $s) { }
}
?
-
?php
class Foo {
public function setSelf(Foo $s) { }
}
class Bar extends Foo {
public function setSelf(parent $s) { }
}
---
?php
class Base {
}
class Foo extends Base{
public function setSelf(parent $s) { }
}
class Bar extends Foo {
public function setSelf(Base $s) { }
}
and more...
[2011-12-20 10:56:31] jpa...@php.net
Description:
self should be thought as the class where the keyword is written in.
Here is then a strange behavior using inheritance :
Test script:
---
class Foo {
public function setSelf(self $s) { }
}
class Bar extends Foo {
public function setSelf(self $s) { }
}
Expected result:
Strict Standards as Bar::setself() signature doesn't respect Foo::setSelf()
signature.
Foo's one has a type hint on Foo (using self keyword), but Bar's one on Bar
(still using self keyword) : the methods then have a signature mismatch, and
PHP
should complain about that
Actual result:
--
Nothing happens.
Trying this gives the correct E_STRICT error, correct behavior :
class Foo {
public function setSelf(Foo $s) { }
}
class Bar extends Foo {
public function setSelf(Bar $s) { }
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60573edit=1
[PHP-BUG] Req #60577 [NEW]: count(new EmptyIterator) returns 1
From: Operating system: PHP version: 5.4SVN-2011-12-20 (SVN) Package: SPL related Bug Type: Feature/Change Request Bug description:count(new EmptyIterator) returns 1 Description: As an object that simulates a list of zero items, count(new EmptyIterator) should return zero. Test script: --- ?php $it = new EmptyIterator; var_dump(count($it)); Expected result: int(0) Actual result: -- int(1) -- Edit bug report at https://bugs.php.net/bug.php?id=60577edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60577r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60577r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60577r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60577r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60577r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60577r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60577r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60577r=needscript Try newer version: https://bugs.php.net/fix.php?id=60577r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60577r=support Expected behavior: https://bugs.php.net/fix.php?id=60577r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60577r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60577r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60577r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60577r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60577r=dst IIS Stability: https://bugs.php.net/fix.php?id=60577r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60577r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60577r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60577r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60577r=mysqlcfg
[PHP-BUG] Bug #60578 [NEW]: IMAP-functions don't work!
From:
Operating system: Linux
PHP version: Irrelevant
Package: IMAP related
Bug Type: Bug
Bug description:IMAP-functions don't work!
Description:
Note:
1. imap.so is loaded (as seen from the script and, through
get_loaded_extensions() function);
2. imap.ini is parsed (as seen from phpinfo() function);
3. php is compiled with imap (as seen from phpinfo() function, IMAP
c-Client
Version 2007e);
4. error log file (php.ini) don't record any failures after launching the
script;
5. connection to IMAP Server (dovecot) through telnet doesn't have any
problem.
Moreover, when I start the script I see that the connection to IMAP Server
goes
well but it is disconnected immediately. That is compared to telnet
connection,
the connection through imap_open function doesn't stay opened!
6. webserver (apache) configuration is checked for misconfiguration (as
imap-
functions start from webserver environment).Nothing found.
Test script:
---
?php
if(extension_loaded(imap))
{
echo preimap loaded/pre;
}else{
echo preimap not loaded/pre;
}
$mbox =
imap_open({X.com:143/novalidate-cert},user_name,user_pass);
if($mbox !== FALSE)
{
$list = imap_list($mbox,{X.com:143/novalidate-cert},*);
}else{
echobr,The stream is closed!;
}
?
Expected result:
An array containing the names of the mailboxes ($list).
Actual result:
--
imap loaded
Notice: Undefined variable: mbox in /usr/lib/cgi-bin/PPP.php on line 24
Fatal
error: Call to undefined function  imap_list() in /usr/lib/cgi-bin/PPP.php
on
line 27
--
Edit bug report at https://bugs.php.net/bug.php?id=60578edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60578r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60578r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60578r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60578r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60578r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60578r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60578r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60578r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60578r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60578r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60578r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60578r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60578r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60578r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60578r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60578r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60578r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60578r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60578r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60578r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60578r=mysqlcfg
[PHP-BUG] Bug #60579 [NEW]: IMAP-functions don't work!
From:
Operating system: Linux
PHP version: Irrelevant
Package: IMAP related
Bug Type: Bug
Bug description:IMAP-functions don't work!
Description:
Note:
1. imap.so is loaded (as seen from the script and, through
get_loaded_extensions() function);
2. imap.ini is parsed (as seen from phpinfo() function);
3. php is compiled with imap (as seen from phpinfo() function, IMAP
c-Client
Version 2007e);
4. error log file (php.ini) don't record any failures after launching the
script;
5. connection to IMAP Server (dovecot) through telnet doesn't have any
problem.
Moreover, when I start the script I see that the connection to IMAP Server
goes
well but it is disconnected immediately. That is compared to telnet
connection,
the connection through imap_open function doesn't stay opened!
6. webserver (apache) configuration is checked for misconfiguration (as
imap-
functions start from webserver environment).Nothing found.
Test script:
---
?php
if(extension_loaded(imap))
{
echo preimap loaded/pre;
}else{
echo preimap not loaded/pre;
}
$mbox =
imap_open({X.com:143/novalidate-cert},user_name,user_pass);
if($mbox !== FALSE)
{
$list = imap_list($mbox,{X.com:143/novalidate-cert},*);
}else{
echobr,The stream is closed!;
}
?
Expected result:
An array containing the names of the mailboxes ($list).
Actual result:
--
imap loaded
Notice: Undefined variable: mbox in /usr/lib/cgi-bin/PPP.php on line 24
Fatal
error: Call to undefined function  imap_list() in /usr/lib/cgi-bin/PPP.php
on
line 27
--
Edit bug report at https://bugs.php.net/bug.php?id=60579edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60579r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60579r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60579r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60579r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60579r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60579r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60579r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60579r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60579r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60579r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60579r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60579r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60579r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60579r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60579r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60579r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60579r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60579r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60579r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60579r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60579r=mysqlcfg
[PHP-BUG] Bug #60580 [NEW]: IMAP-functions don't work!
From:
Operating system: Linux
PHP version: Irrelevant
Package: IMAP related
Bug Type: Bug
Bug description:IMAP-functions don't work!
Description:
Note:
1. imap.so is loaded (as seen from the script and, through
get_loaded_extensions() function);
2. imap.ini is parsed (as seen from phpinfo() function);
3. php is compiled with imap (as seen from phpinfo() function, IMAP
c-Client
Version 2007e);
4. error log file (php.ini) don't record any failures after launching the
script;
5. connection to IMAP Server (dovecot) through telnet doesn't have any
problem.
Moreover, when I start the script I see that the connection to IMAP Server
goes
well but it is disconnected immediately. That is compared to telnet
connection,
the connection through imap_open function doesn't stay opened!
6. webserver (apache) configuration is checked for misconfiguration (as
imap-
functions start from webserver environment).Nothing found.
Test script:
---
?php
if(extension_loaded(imap))
{
echo preimap loaded/pre;
}else{
echo preimap not loaded/pre;
}
$mbox =
imap_open({X.com:143/novalidate-cert},user_name,user_pass);
if($mbox !== FALSE)
{
$list = imap_list($mbox,{X.com:143/novalidate-cert},*);
}else{
echobr,The stream is closed!;
}
?
Expected result:
An array containing the names of the mailboxes ($list).
Actual result:
--
imap loaded
Notice: Undefined variable: mbox in /usr/lib/cgi-bin/PPP.php on line 24
Fatal
error: Call to undefined function  imap_list() in /usr/lib/cgi-bin/PPP.php
on
line 27
--
Edit bug report at https://bugs.php.net/bug.php?id=60580edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60580r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60580r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60580r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60580r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60580r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60580r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60580r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60580r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60580r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60580r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60580r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60580r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60580r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60580r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60580r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60580r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60580r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60580r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60580r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60580r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60580r=mysqlcfg
[PHP-BUG] Req #60581 [NEW]: Russia have no summer/winter offset from 2011
From:
Operating system: ubuntu
PHP version: 5.3.8
Package: Date/time related
Bug Type: Feature/Change Request
Bug description:Russia have no summer/winter offset from 2011
Description:
Russia have no summer/winter offset from 2011
Test script:
---
$winter = new DateTime('2012-12-21', new DateTimeZone('Europe/Moscow'));
$summer = new DateTime('2012-04-21', new DateTimeZone('Europe/Moscow'));
$tz[winter]= ($winter-getOffset())/60/60;
$tz[summer]= ($summer-getOffset())/60/60;
$tz[diff]=$tz[summer]-$tz[winter];
echo $tz[diff];
Expected result:
0
Actual result:
--
1
--
Edit bug report at https://bugs.php.net/bug.php?id=60581edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60581r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60581r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60581r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60581r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60581r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60581r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60581r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60581r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60581r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60581r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60581r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60581r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60581r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60581r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60581r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60581r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60581r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60581r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60581r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60581r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60581r=mysqlcfg
Bug #60519 [Bgs]: OCILobRead2 could not be located in OCI.dll
Edit report at https://bugs.php.net/bug.php?id=60519edit=1 ID: 60519 Updated by: s...@php.net Reported by:webmaster at sharpthoughts dot com Summary:OCILobRead2 could not be located in OCI.dll Status: Bogus Type: Bug -Package:Compile Failure +Package:OCI8 related Operating System: Windows Xp PHP Version:PHP Block user comment: N Private report: N New Comment: An error mentioning OCILobRead2 indicates that some Oracle libraries are being loaded, but not the correct version. This indicates a user-configuration issue, common on Windows due to the Windows dependency model. The bug system is not the place to get support for diagnosing this but I'd be happy to follow up in another forum. Previous Comments: [2011-12-15 04:15:05] webmaster at sharphoughts dot com Now we are really getting down to interesting information! The post above about the command line working was only half right. PHP worked at the command line UNTIL I closed the error window mentioned above and then clicked Finished in the installer program. After that, attempting to run the exact same script as a minute ago results in the OCILobRead2 error mentioned at the beginning of this bug report! This seems to indicate to me that the msi installer is undoing something right before it closes. [2011-12-15 04:10:40] webmaster at sharphoughts dot com I uninstalled the msi I used last time (php-5.2.17-Win32-VC6-x86.msi) and tried installing the other apache-compatible windows download (php-5.2.17-nts-Win32-VC6-x86.msi). I got the same error message as before during installation (with the additional issue that the only web servers listed are fastiss and other cgi). The error message is: Error trying to acccess the local web service: GetObject Failed. You will need to manually configure the web server. I am thinking that either msi files in general don't work too well or that VC6 is the issue. On the plus side, the command line seems to work with this download. [2011-12-15 03:50:41] webmaster at sharphoughts dot com After further consideration, I think that PART of the fault resides in a failure of the msi (windows installer) of either the apache httpd package or the php package (whichever is responsible for it) to put it the proper loadmodule for php. My reason for this statement is that there is no such loadmodule in the apache conf file. Additionally, the php installation process hickupped with a failure to find a getobject of some sort. Perhaps the install never finished for that reason, explaining why php doesn't work from the command line either. Just a WAG. [2011-12-15 03:39:31] webmaster at sharpthoughts dot com This is NOT an Oracle bug. I saw that comment as well and dismissed it because it was not apropos. Please un-bogus this report and un-relate it to the OCI8 package. This issue does NOT relate to OCI8 or any other database product. This issue relates to non-viable windows installation for the latest stable release of PHP for use with apache. [2011-12-14 15:32:42] s...@php.net php_oci8.dll requires Oracle 10gR2 or later client libraries. php_oci8_11g.dll requires Oracle 11gR2 client libraries. The source code compiles various features (or internal behaviors) depending on the Oracle version used during compilation; the runtime Oracle library version therefore needs to have those features. 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 https://bugs.php.net/bug.php?id=60519 -- Edit this bug report at https://bugs.php.net/bug.php?id=60519edit=1
[PHP-BUG] Bug #60582 [NEW]: pdo-dblib compile fails against FreeTDS 0.91
From: Operating system: RHEL5 PHP version: 5.3.8 Package: PDO related Bug Type: Bug Bug description:pdo-dblib compile fails against FreeTDS 0.91 Description: pdo_dblib fails to compile against FreeTDS 0.91 due to redeclaration of LPBYTE. Patch attached. -- Edit bug report at https://bugs.php.net/bug.php?id=60582edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60582r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60582r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60582r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60582r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60582r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60582r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60582r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60582r=needscript Try newer version: https://bugs.php.net/fix.php?id=60582r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60582r=support Expected behavior: https://bugs.php.net/fix.php?id=60582r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60582r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60582r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60582r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60582r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60582r=dst IIS Stability: https://bugs.php.net/fix.php?id=60582r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60582r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60582r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60582r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60582r=mysqlcfg
Bug #60582 [Opn-Bgs]: pdo-dblib compile fails against FreeTDS 0.91
Edit report at https://bugs.php.net/bug.php?id=60582edit=1 ID: 60582 Updated by: fel...@php.net Reported by:jbnance at tresgeek dot net Summary:pdo-dblib compile fails against FreeTDS 0.91 -Status: Open +Status: Bogus Type: Bug Package:PDO related Operating System: RHEL5 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: This issue has been fixed in PHP 5.3.9RC2 Previous Comments: [2011-12-20 23:31:52] jbnance at tresgeek dot net Description: pdo_dblib fails to compile against FreeTDS 0.91 due to redeclaration of LPBYTE. Patch attached. -- Edit this bug report at https://bugs.php.net/bug.php?id=60582edit=1
Bug #60579 [Opn-Bgs]: IMAP-functions don't work!
Edit report at https://bugs.php.net/bug.php?id=60579edit=1
ID: 60579
Updated by: fel...@php.net
Reported by:profymath at yahoo dot com
Summary:IMAP-functions don't work!
-Status: Open
+Status: Bogus
Type: Bug
Package:IMAP related
Operating System: Linux
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
.
Previous Comments:
[2011-12-20 22:27:00] profymath at yahoo dot com
Description:
Note:
1. imap.so is loaded (as seen from the script and, through
get_loaded_extensions() function);
2. imap.ini is parsed (as seen from phpinfo() function);
3. php is compiled with imap (as seen from phpinfo() function, IMAP c-Client
Version 2007e);
4. error log file (php.ini) don't record any failures after launching the
script;
5. connection to IMAP Server (dovecot) through telnet doesn't have any problem.
Moreover, when I start the script I see that the connection to IMAP Server goes
well but it is disconnected immediately. That is compared to telnet connection,
the connection through imap_open function doesn't stay opened!
6. webserver (apache) configuration is checked for misconfiguration (as imap-
functions start from webserver environment).Nothing found.
Test script:
---
?php
if(extension_loaded(imap))
{
echo preimap loaded/pre;
}else{
echo preimap not loaded/pre;
}
$mbox = imap_open({X.com:143/novalidate-cert},user_name,user_pass);
if($mbox !== FALSE)
{
$list = imap_list($mbox,{X.com:143/novalidate-cert},*);
}else{
echobr,The stream is closed!;
}
?
Expected result:
An array containing the names of the mailboxes ($list).
Actual result:
--
imap loaded
Notice: Undefined variable: mbox in /usr/lib/cgi-bin/PPP.php on line 24 Fatal
error: Call to undefined function  imap_list() in /usr/lib/cgi-bin/PPP.php on
line 27
--
Edit this bug report at https://bugs.php.net/bug.php?id=60579edit=1
Bug #60580 [Opn-Bgs]: IMAP-functions don't work!
Edit report at https://bugs.php.net/bug.php?id=60580edit=1
ID: 60580
Updated by: fel...@php.net
Reported by:profymath at yahoo dot com
Summary:IMAP-functions don't work!
-Status: Open
+Status: Bogus
Type: Bug
Package:IMAP related
Operating System: Linux
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
.
Previous Comments:
[2011-12-20 22:27:46] profymath at yahoo dot com
Description:
Note:
1. imap.so is loaded (as seen from the script and, through
get_loaded_extensions() function);
2. imap.ini is parsed (as seen from phpinfo() function);
3. php is compiled with imap (as seen from phpinfo() function, IMAP c-Client
Version 2007e);
4. error log file (php.ini) don't record any failures after launching the
script;
5. connection to IMAP Server (dovecot) through telnet doesn't have any problem.
Moreover, when I start the script I see that the connection to IMAP Server goes
well but it is disconnected immediately. That is compared to telnet connection,
the connection through imap_open function doesn't stay opened!
6. webserver (apache) configuration is checked for misconfiguration (as imap-
functions start from webserver environment).Nothing found.
Test script:
---
?php
if(extension_loaded(imap))
{
echo preimap loaded/pre;
}else{
echo preimap not loaded/pre;
}
$mbox = imap_open({X.com:143/novalidate-cert},user_name,user_pass);
if($mbox !== FALSE)
{
$list = imap_list($mbox,{X.com:143/novalidate-cert},*);
}else{
echobr,The stream is closed!;
}
?
Expected result:
An array containing the names of the mailboxes ($list).
Actual result:
--
imap loaded
Notice: Undefined variable: mbox in /usr/lib/cgi-bin/PPP.php on line 24 Fatal
error: Call to undefined function  imap_list() in /usr/lib/cgi-bin/PPP.php on
line 27
--
Edit this bug report at https://bugs.php.net/bug.php?id=60580edit=1
Bug #53230 [Com]: extracting file go to infinite loop
Edit report at https://bugs.php.net/bug.php?id=53230edit=1 ID: 53230 Comment by: phpbugs at joern dot heissler dot de Reported by:vincent dot gibault at gmail dot com Summary:extracting file go to infinite loop Status: Assigned Type: Bug Package:Zip Related Operating System: archlinux x86_64 PHP Version:5.3.3 Assigned To:pajoye Block user comment: N Private report: N New Comment: ziplib-0.10 seems to fix that bug. Previous Comments: [2011-11-13 20:28:42] paj...@php.net Yes please do, the more we have the better. I can already reproduce it using bug.zip. thanks :) [2011-11-13 14:07:46] dave at bugsplatsoftware dot com I can provide additional example zip files that fail. This problem causes my website performance to plummet occaisionally, requiring a restart of Apache. I'd be happy to help evaluate fixes, or to know of any possible work-arounds. [2011-02-22 01:29:45] tbrasta at gmail dot com Your file is corrupted. It contains invalid crc, compressed and uncompressed data lenghts of archived file. It is libzip related bug. More details here http://nih.at/listarchive/libzip-discuss/msg00074.html. [2010-11-03 21:25:32] vincent dot gibault at gmail dot com Hello, here is the link: http://www.corrida-noel-issy.com/bug.zip [2010-11-02 22:37:59] paj...@php.net Please provide a link to the zip you are using for this bug. 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 https://bugs.php.net/bug.php?id=53230 -- Edit this bug report at https://bugs.php.net/bug.php?id=53230edit=1
Bug #53742 [Com]: Late static binding does not work via reflection
Edit report at https://bugs.php.net/bug.php?id=53742edit=1
ID: 53742
Comment by: will dot fitch at gmail dot com
Reported by:blue-tidus159 at hotmail dot com
Summary:Late static binding does not work via reflection
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Windows 7 x64
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
This is fixed in 5.4 and HEAD:
Fatal error: Class A contains 1 abstract method and must therefore be declared
abstract or implement the remaining methods (A::callLate)
Previous Comments:
[2011-08-04 19:13:37] josh at joshbutts dot com
Still exists in PHP 5.3.5. Reproducible with the script above.
[2011-05-12 20:06:23] phdaemon at gmail dot com
I experienced this bug when building a new automation framework using PHPUnit +
selenium.
IT seems that PHPUnit uses reflection to instantiate a static function called
suite which handles an array of browsers and duplicating a testcase to run in
each one.
I was on the latest ubuntu package: PHP 5.3.3-1ubuntu9.5 with Suhosin-Patch
(cli) (built: May 3 2011 00:49:55)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
I got around it by switching the reflection to call_user_func but this should
probably be fixed as PHPUnit is very popular.
[2011-01-13 21:22:52] blue-tidus159 at hotmail dot com
Description:
When a static method is called through reflection, late static binding does not
work. Probably because the getMethod() returns the method associated to the
parent class.
Test script:
---
class A{
public static function call(){
static::callLate();
}
public static abstract function callLate();
}
class B{
public static function callLate(){
echo 'Late static binding';
}
}
B::call();
$class = new ReflectionClass('B');
$class-getMethod('call')-invoke(null);
Expected result:
Late static binding
Late static binding
Actual result:
--
Late static binding
Cannot call abstract method B::callLate()
--
Edit this bug report at https://bugs.php.net/bug.php?id=53742edit=1
Bug #53742 [Opn-Csd]: Late static binding does not work via reflection
Edit report at https://bugs.php.net/bug.php?id=53742edit=1
ID: 53742
Updated by: larue...@php.net
Reported by:blue-tidus159 at hotmail dot com
Summary:Late static binding does not work via reflection
-Status: Open
+Status: Closed
Type: Bug
Package:Scripting Engine problem
Operating System: Windows 7 x64
PHP Version:Irrelevant
-Assigned To:
+Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
dup to #60367
Previous Comments:
[2011-12-21 07:02:47] will dot fitch at gmail dot com
This is fixed in 5.4 and HEAD:
Fatal error: Class A contains 1 abstract method and must therefore be declared
abstract or implement the remaining methods (A::callLate)
[2011-08-04 19:13:37] josh at joshbutts dot com
Still exists in PHP 5.3.5. Reproducible with the script above.
[2011-05-12 20:06:23] phdaemon at gmail dot com
I experienced this bug when building a new automation framework using PHPUnit +
selenium.
IT seems that PHPUnit uses reflection to instantiate a static function called
suite which handles an array of browsers and duplicating a testcase to run in
each one.
I was on the latest ubuntu package: PHP 5.3.3-1ubuntu9.5 with Suhosin-Patch
(cli) (built: May 3 2011 00:49:55)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
I got around it by switching the reflection to call_user_func but this should
probably be fixed as PHPUnit is very popular.
[2011-01-13 21:22:52] blue-tidus159 at hotmail dot com
Description:
When a static method is called through reflection, late static binding does not
work. Probably because the getMethod() returns the method associated to the
parent class.
Test script:
---
class A{
public static function call(){
static::callLate();
}
public static abstract function callLate();
}
class B{
public static function callLate(){
echo 'Late static binding';
}
}
B::call();
$class = new ReflectionClass('B');
$class-getMethod('call')-invoke(null);
Expected result:
Late static binding
Late static binding
Actual result:
--
Late static binding
Cannot call abstract method B::callLate()
--
Edit this bug report at https://bugs.php.net/bug.php?id=53742edit=1
