Req #65646 [Opn->Asn]: re-enable CURLOPT_FOLLOWLOCATION with open_basedir or safe_mode

[aharvey]

Edit report at https://bugs.php.net/bug.php?id=65646&edit=1

 ID: 65646
 Updated by: ahar...@php.net
 Reported by:butesa at freenet dot de
 Summary:re-enable CURLOPT_FOLLOWLOCATION with open_basedir
 or safe_mode
-Status: Open
+Status: Assigned
 Type:   Feature/Change Request
 Package:cURL related
 Operating System:   any
 PHP Version:5.5.3
-Assigned To:
+Assigned To:aharvey
 Block user comment: N
 Private report: N

 New Comment:

I have an implementation of this on a branch in my GitHub fork, but don't have 
time to finish testing it tonight. I'll try to get back to it later in the week.


Previous Comments:

[2013-09-09 21:27:10] butesa at freenet dot de

Description:

CURLOPT_FOLLOWLOCATION is disabled when open_basedir is set or when safe_mode 
is on.
Since 7.19.4, curl won't follow a location-header that uses the file-protocol. 
So using CURLOPT_FOLLOWLOCATION in combination with open_basedir or safe_mode 
should be fine.
("Since 7.19.4, libcurl can limit what protocols it will automatically follow. 
The accepted protocols are set with CURLOPT_REDIR_PROTOCOLS and it excludes the 
FILE protocol by default." 
http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTFOLLOWLOCATION )







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

Bug #65634 [Com]: HTTP wrapper is very slow with protocol_version 1.1

[butesa at freenet dot de]

Edit report at https://bugs.php.net/bug.php?id=65634&edit=1

 ID: 65634
 Comment by: butesa at freenet dot de
 Reported by:butesa at freenet dot de
 Summary:HTTP wrapper is very slow with protocol_version 1.1
 Status: Not a bug
 Type:   Bug
 Package:HTTP related
 Operating System:   Ubuntu 12.04 x64
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

I don't see how it can be not a bug if a http request takes 100 seconds.
If the server uses connection: keep-alive, then the client has to close the 
connection if it doesn't want to make any further requests.


Previous Comments:

[2013-09-09 23:03:47] ahar...@php.net

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

www.google.de responds with a keep-alive connection when a HTTP/1.1 request is 
made and no Connection request header is included, which is valid in RFC 2616. 
Sending a "Connection: close" request header restores the 1.0 behaviour.


[2013-09-08 16:27:47] butesa at freenet dot de

Description:

Loading a website with the http wrapper takes very long if protocol_version is 
set to 1.1. The time it takes depends on the timeout. On some servers the 
problem doesn't occur.

I tested also on Ubuntu 10.04 (PHP 5.3.2-1ubuntu4.19) and Ubuntu 12.04 (PHP 
5.3.10-1ubuntu3.7), both 64bit.

Test script:
---
http://www.google.de/intl/de/policies/?fg=1';
foreach(array(1.0,1.1) as $proto)
{
for ($timeout = 1; $timeout < 60; $timeout+=10)
{
$st = microtime(true);
$opt = array(
'http' => array(
'timeout' => $timeout,
'protocol_version' => $proto,
),
);
$context = stream_context_create($opt);
$content = file_get_contents($url,false,$context);
printf("%2d %.1f %f %s\n", $timeout, $proto, microtime(true) - 
$st, md5($content));
}
}
?>

Expected result:

The request takes the same time, no matter what timeout and protocol_version is 
set.

Actual result:
--
Output of the test script:
For $url='http://www.google.de/intl/de/policies/?fg=1':
 1 1.0 0.279102 60bf7bc72d2a06b337c8a8464e0f9e66
11 1.0 0.277956 60bf7bc72d2a06b337c8a8464e0f9e66
21 1.0 0.283753 60bf7bc72d2a06b337c8a8464e0f9e66
31 1.0 0.285862 60bf7bc72d2a06b337c8a8464e0f9e66
41 1.0 0.277894 60bf7bc72d2a06b337c8a8464e0f9e66
51 1.0 0.285653 60bf7bc72d2a06b337c8a8464e0f9e66
 1 1.1 2.284301 60bf7bc72d2a06b337c8a8464e0f9e66
11 1.1 22.305424 60bf7bc72d2a06b337c8a8464e0f9e66
21 1.1 42.309270 60bf7bc72d2a06b337c8a8464e0f9e66
31 1.1 62.355997 60bf7bc72d2a06b337c8a8464e0f9e66
41 1.1 82.360794 60bf7bc72d2a06b337c8a8464e0f9e66
51 1.1 102.379933 60bf7bc72d2a06b337c8a8464e0f9e66

For $url='http://www.example.com':
 1 1.0 0.491382 09b9c392dc1f6e914cea287cb6be34b0
11 1.0 0.426191 09b9c392dc1f6e914cea287cb6be34b0
21 1.0 0.428513 09b9c392dc1f6e914cea287cb6be34b0
31 1.0 0.423852 09b9c392dc1f6e914cea287cb6be34b0
41 1.0 0.423751 09b9c392dc1f6e914cea287cb6be34b0
51 1.0 0.431590 09b9c392dc1f6e914cea287cb6be34b0
 1 1.1 1.420486 09b9c392dc1f6e914cea287cb6be34b0
11 1.1 6.143113 09b9c392dc1f6e914cea287cb6be34b0
21 1.1 5.994384 09b9c392dc1f6e914cea287cb6be34b0
31 1.1 5.991940 09b9c392dc1f6e914cea287cb6be34b0
41 1.1 6.012121 09b9c392dc1f6e914cea287cb6be34b0
51 1.1 6.007920 09b9c392dc1f6e914cea287cb6be34b0

For $url='http://www.php.net':
 1 1.0 1.673016 2dcc6fe85b335205a35d9980a9095735
11 1.0 1.93 2dcc6fe85b335205a35d9980a9095735
21 1.0 1.648235 2dcc6fe85b335205a35d9980a9095735
31 1.0 1.637566 2dcc6fe85b335205a35d9980a9095735
41 1.0 1.633473 2dcc6fe85b335205a35d9980a9095735
51 1.0 1.718051 2dcc6fe85b335205a35d9980a9095735
 1 1.1 1.647803 2dcc6fe85b335205a35d9980a9095735
11 1.1 1.863799 2dcc6fe85b335205a35d9980a9095735
21 1.1 1.673567 2dcc6fe85b335205a35d9980a9095735
31 1.1 1.651704 2dcc6fe85b335205a35d9980a9095735
41 1.1 1.657976 2dcc6fe85b335205a35d9980a9095735
51 1.1 1.635651 2dcc6fe85b335205a35d9980a9095735






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

Bug #65633 [Opn->Csd]: built-in server treat some http headers as case-sensitive

[aharvey]

Edit report at https://bugs.php.net/bug.php?id=65633&edit=1

 ID: 65633
 Updated by: ahar...@php.net
 Reported by:francesco dot laffi at gmail dot com
 Summary:built-in server treat some http headers as
 case-sensitive
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Built-in web server
 PHP Version:5.5Git-2013-09-08 (snap)
-Assigned To:
+Assigned To:aharvey
 Block user comment: N
 Private report: N

 New Comment:

The fix for this bug has been committed.

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.

Fixed in 5.4, 5.5 and master.


Previous Comments:

[2013-09-09 09:15:32] francesco dot laffi at gmail dot com

edited title


[2013-09-08 13:43:56] francesco dot laffi at gmail dot com

Description:

The built-in server look for info in same headers in a case-sensitive way, but 
the 
rfc2616 define http headers fields as case insensitive. 
i.e. 'cookie: foo=bar' should be recognized but the the current cli server only 
recognize correctly 'Cookie: foo=bar'

I tried to fiddle with the code to confirm it, i.e in 
`sapi/cli/php_cli_server.c` 
in the function `sapi_cli_server_read_cookies`:
replace: if (FAILURE == zend_hash_find(&client->request.headers, "Cookie", 
sizeof("Cookie"), (void**)&val))
with: if (FAILURE == zend_hash_find(&client->request.headers, "Cookie", 
sizeof("Cookie"), (void**)&val) && FAILURE == zend_hash_find(&client-
>request.headers, "cookie", sizeof("cookie"), (void**)&val))

And cookies then worked correctly even with lowercase header field. 
I never developed in C so I wont be able to produce a full patch. The above 
snippet is not a suggestion on how to fix it, just pointing where the bug is. 
In 
the same file I see there are other headers checked in the same way. 

I also noticed that even if it doesnt fill the $_COOKIE superglobal it does put 
the cookie header in $_SERVER['HTTP_COOKIE'], so its already case-insensitive 
in 
some code.

Looking around about this I found this bug on other projects but I didnt 
found it here, other sources for reference:
https://github.com/symfony/symfony/issues/8278
https://github.com/37signals/pow/issues/319

Test script:
---
echo ' index.php
php -S 127.0.0.1:8080
curl http://127.0.0.1:8080 -H 'Cookie: foo=bar'
curl http://127.0.0.1:8080 -H 'cookie: foo=bar'


Expected result:

the two curl request return the same output

Actual result:
--
> curl http://127.0.0.1:8080 -H 'Cookie: foo=bar'
array(1) {
  ["foo"]=>
  string(3) "bar"
}
> curl http://127.0.0.1:8080 -H 'cookie: foo=bar'
array(0) {
}






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

Bug #65634 [Opn->Nab]: HTTP wrapper is very slow with protocol_version 1.1

[aharvey]

Edit report at https://bugs.php.net/bug.php?id=65634&edit=1

 ID: 65634
 Updated by: ahar...@php.net
 Reported by:butesa at freenet dot de
 Summary:HTTP wrapper is very slow with protocol_version 1.1
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:HTTP related
 Operating System:   Ubuntu 12.04 x64
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 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

www.google.de responds with a keep-alive connection when a HTTP/1.1 request is 
made and no Connection request header is included, which is valid in RFC 2616. 
Sending a "Connection: close" request header restores the 1.0 behaviour.


Previous Comments:

[2013-09-08 16:27:47] butesa at freenet dot de

Description:

Loading a website with the http wrapper takes very long if protocol_version is 
set to 1.1. The time it takes depends on the timeout. On some servers the 
problem doesn't occur.

I tested also on Ubuntu 10.04 (PHP 5.3.2-1ubuntu4.19) and Ubuntu 12.04 (PHP 
5.3.10-1ubuntu3.7), both 64bit.

Test script:
---
http://www.google.de/intl/de/policies/?fg=1';
foreach(array(1.0,1.1) as $proto)
{
for ($timeout = 1; $timeout < 60; $timeout+=10)
{
$st = microtime(true);
$opt = array(
'http' => array(
'timeout' => $timeout,
'protocol_version' => $proto,
),
);
$context = stream_context_create($opt);
$content = file_get_contents($url,false,$context);
printf("%2d %.1f %f %s\n", $timeout, $proto, microtime(true) - 
$st, md5($content));
}
}
?>

Expected result:

The request takes the same time, no matter what timeout and protocol_version is 
set.

Actual result:
--
Output of the test script:
For $url='http://www.google.de/intl/de/policies/?fg=1':
 1 1.0 0.279102 60bf7bc72d2a06b337c8a8464e0f9e66
11 1.0 0.277956 60bf7bc72d2a06b337c8a8464e0f9e66
21 1.0 0.283753 60bf7bc72d2a06b337c8a8464e0f9e66
31 1.0 0.285862 60bf7bc72d2a06b337c8a8464e0f9e66
41 1.0 0.277894 60bf7bc72d2a06b337c8a8464e0f9e66
51 1.0 0.285653 60bf7bc72d2a06b337c8a8464e0f9e66
 1 1.1 2.284301 60bf7bc72d2a06b337c8a8464e0f9e66
11 1.1 22.305424 60bf7bc72d2a06b337c8a8464e0f9e66
21 1.1 42.309270 60bf7bc72d2a06b337c8a8464e0f9e66
31 1.1 62.355997 60bf7bc72d2a06b337c8a8464e0f9e66
41 1.1 82.360794 60bf7bc72d2a06b337c8a8464e0f9e66
51 1.1 102.379933 60bf7bc72d2a06b337c8a8464e0f9e66

For $url='http://www.example.com':
 1 1.0 0.491382 09b9c392dc1f6e914cea287cb6be34b0
11 1.0 0.426191 09b9c392dc1f6e914cea287cb6be34b0
21 1.0 0.428513 09b9c392dc1f6e914cea287cb6be34b0
31 1.0 0.423852 09b9c392dc1f6e914cea287cb6be34b0
41 1.0 0.423751 09b9c392dc1f6e914cea287cb6be34b0
51 1.0 0.431590 09b9c392dc1f6e914cea287cb6be34b0
 1 1.1 1.420486 09b9c392dc1f6e914cea287cb6be34b0
11 1.1 6.143113 09b9c392dc1f6e914cea287cb6be34b0
21 1.1 5.994384 09b9c392dc1f6e914cea287cb6be34b0
31 1.1 5.991940 09b9c392dc1f6e914cea287cb6be34b0
41 1.1 6.012121 09b9c392dc1f6e914cea287cb6be34b0
51 1.1 6.007920 09b9c392dc1f6e914cea287cb6be34b0

For $url='http://www.php.net':
 1 1.0 1.673016 2dcc6fe85b335205a35d9980a9095735
11 1.0 1.93 2dcc6fe85b335205a35d9980a9095735
21 1.0 1.648235 2dcc6fe85b335205a35d9980a9095735
31 1.0 1.637566 2dcc6fe85b335205a35d9980a9095735
41 1.0 1.633473 2dcc6fe85b335205a35d9980a9095735
51 1.0 1.718051 2dcc6fe85b335205a35d9980a9095735
 1 1.1 1.647803 2dcc6fe85b335205a35d9980a9095735
11 1.1 1.863799 2dcc6fe85b335205a35d9980a9095735
21 1.1 1.673567 2dcc6fe85b335205a35d9980a9095735
31 1.1 1.651704 2dcc6fe85b335205a35d9980a9095735
41 1.1 1.657976 2dcc6fe85b335205a35d9980a9095735
51 1.1 1.635651 2dcc6fe85b335205a35d9980a9095735






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

[PHP-BUG] Req #65646 [NEW]: re-enable CURLOPT_FOLLOWLOCATION with open_basedir or safe_mode

[butesa at freenet dot de]

From: butesa at freenet dot de
Operating system: any
PHP version:  5.5.3
Package:  cURL related
Bug Type: Feature/Change Request
Bug description:re-enable CURLOPT_FOLLOWLOCATION with open_basedir or safe_mode

Description:

CURLOPT_FOLLOWLOCATION is disabled when open_basedir is set or when
safe_mode is on.
Since 7.19.4, curl won't follow a location-header that uses the
file-protocol. So using CURLOPT_FOLLOWLOCATION in combination with
open_basedir or safe_mode should be fine.
("Since 7.19.4, libcurl can limit what protocols it will automatically
follow. The accepted protocols are set with CURLOPT_REDIR_PROTOCOLS and it
excludes the FILE protocol by default."
http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTFOLLOWLOCATION )


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

Bug #65643 [Opn->Nab]: Dynamically created methods cannot be called directly

[johannes]

Edit report at https://bugs.php.net/bug.php?id=65643&edit=1

 ID: 65643
 Updated by: johan...@php.net
 Reported by:yuri dot sulyma at gmail dot com
 Summary:Dynamically created methods cannot be called
 directly
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Class/Object related
 Operating System:   OS X 10.8.4
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 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

This is a limitation of PHP's type system. Functions/methods and variables 
don't share a common namespace. Currently there is no plan to change this.


Previous Comments:

[2013-09-09 18:13:07] yuri dot sulyma at gmail dot com

Description:

Methods dynamically created by assigning a closure to a property of $this 
cannot be called directly, but must instead by assigned to a variable first.

Test script:
---
class O {
  public $f;

  function __construct() {
$this->f = function() {
  echo "Dynamic method\n";
};
  }
}

$o = new O();
$f = $o->f;
$f();
$o->f();


Expected result:

Dynamic method
Dynamic method

Actual result:
--
Dynamic method
Fatal error:  Call to undefined method O::f()






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

Bug #65645 [Opn->Csd]: interactive shell doesn't support finally block

[schavery at gmail dot com]

Edit report at https://bugs.php.net/bug.php?id=65645&edit=1

 ID: 65645
 User updated by:schavery at gmail dot com
 Reported by:schavery at gmail dot com
 Summary:interactive shell doesn't support finally block
-Status: Open
+Status: Closed
 Type:   Bug
 Package:CGI/CLI related
 Operating System:   OS X 10.8.4
 PHP Version:5.4.19
 Block user comment: N
 Private report: N

 New Comment:

Only works with 5.5+, and I was running 5.4


Previous Comments:

[2013-09-09 18:48:42] schavery at gmail dot com

Description:

---
>From manual page: http://www.php.net/features.commandline.interactive
---

Using php -a

try { echo 'try'; } catch(Exception $e) { echo 'catch'; } finally { echo 
'finally'; }
returns:
PHP Parse error:  parse error in php shell code on line 1

and:

php > try {
php { echo '1';
php { } catch(Exception $e) {
php { echo '2';
php { } finally { <-- line 5
php { echo '3';
php { }
PHP Parse error:  parse error in php shell code on line 5

Test script:
---
https://bugs.php.net/bug.php?id=65645&edit=1

[PHP-BUG] Bug #65644 [NEW]: clumsy language in short_open_tag description

[richlv at nakts dot net]

From: richlv at nakts dot net
Operating system: 
PHP version:  master-Git-2013-09-09 (snap)
Package:  PHP options/info functions
Bug Type: Bug
Bug description:clumsy language in short_open_tag description

Description:

in these two files :

php.ini-production
php.ini-development

description for short_open_tag currently looks like this :

; This directive determines whether or not PHP will recognize code between
;  tags as PHP source which should be processed as such. For
several
; years we recommended that you not use the short tag shortcut and
; instead to use the full  tag combination. With the widespread
use
; of XML and use of these tags by other languages, the server can become
easily
; confused and end up parsing the wrong code in the wrong context.
; This shortcut is still supported for backwards compatibility, but we
; recommend against its use.

a couple of suggested changes :

* "you not use" -> "you do not use"
* "instead to use" -> "instead use"

it could probably be rewritten completely, but at least these two changes
should be considered


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

[PHP-BUG] Bug #65645 [NEW]: interactive shell doesn't support finally block

[schavery at gmail dot com]

From: schavery at gmail dot com
Operating system: OS X 10.8.4
PHP version:  5.4.19
Package:  CGI/CLI related
Bug Type: Bug
Bug description:interactive shell doesn't support finally block

Description:

---
>From manual page: http://www.php.net/features.commandline.interactive
---

Using php -a

try { echo 'try'; } catch(Exception $e) { echo 'catch'; } finally { echo 
'finally'; }
returns:
PHP Parse error:  parse error in php shell code on line 1

and:

php > try {
php { echo '1';
php { } catch(Exception $e) {
php { echo '2';
php { } finally { <-- line 5
php { echo '3';
php { }
PHP Parse error:  parse error in php shell code on line 5

Test script:
---
https://bugs.php.net/bug.php?id=65645&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=65645&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=65645&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=65645&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=65645&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=65645&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65645&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=65645&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=65645&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65645&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=65645&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65645&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65645&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=65645&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65645&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=65645&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=65645&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65645&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65645&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65645&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=65645&r=mysqlcfg

[PHP-BUG] Bug #65643 [NEW]: Dynamically created methods cannot be called directly

[yuri dot sulyma at gmail dot com]

From: yuri dot sulyma at gmail dot com
Operating system: OS X 10.8.4
PHP version:  5.5.3
Package:  Class/Object related
Bug Type: Bug
Bug description:Dynamically created methods cannot be called directly

Description:

Methods dynamically created by assigning a closure to a property of $this
cannot be called directly, but must instead by assigned to a variable
first.

Test script:
---
class O {
  public $f;

  function __construct() {
$this->f = function() {
  echo "Dynamic method\n";
};
  }
}

$o = new O();
$f = $o->f;
$f();
$o->f();


Expected result:

Dynamic method
Dynamic method

Actual result:
--
Dynamic method
Fatal error:  Call to undefined method O::f()

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

Bug #61859 [Com]: pdo fails on make

[austin dot bischoff at gmail dot com]

Edit report at https://bugs.php.net/bug.php?id=61859&edit=1

 ID: 61859
 Comment by: austin dot bischoff at gmail dot com
 Reported by:gencer at cmail dot cm
 Summary:pdo fails on make
 Status: Open
 Type:   Bug
 Package:Compile Failure
 Operating System:   CentOS 5.8 x86_64
 PHP Version:5.4.1
 Block user comment: N
 Private report: N

 New Comment:

I just had this issue on two separate CentOS release 6.4 (Final) servers trying 
to install and compile php 5.4.19.

The ln -s solution worked for me but I just did "ln -s ./ext/pdo" in the root 
of the extracted source files. Once I did 
this the compile and install completed as expected.


Previous Comments:

[2013-03-22 04:39:29] mike at tetonapps dot com

I had this exact problem with version 5.4.13 when attempting to compile in 
Amazon Linux (which is basically CentOS 5, and I turned off php* in the yum 
repo 
config.)

I solved it more easily by simply by adding soft links so that I would not have 
to modify any files:
php-5.4.13/pdo/php_pdo.h points to php-5.4.13/ext/pdo/php_pdo.h
php-5.4.13/pdo/php_pdo_driver.h points to php-5.4.13/ext/pdo/php_pdo_driver.h

After adding these two symbolic links, PHP compiled and installed properly.


[2012-08-21 08:28:40] paszczak000 at gmail dot com

Package glibc-2.12-1.80.el6_3.4.x86_64 already installed and latest version
Package gcc-4.4.6-4.el6.x86_64 already installed and latest version
Package glibc-devel-2.12-1.80.el6_3.4.x86_64 already installed and latest 
version
Package autoconf-2.63-5.1.el6.noarch already installed and latest version

Manually changing dirs helps, but this is workaround.


[2012-08-21 08:24:50] gencer at cmail dot cm

@paszczak000

It is all because of GLIBC and GCC. Make sure that you have autoconf installed. 
Re unpack tar.gz and recompile again. If this bug still exist manually change 
pdo/ with ext/pdo in .h files.

I hope this helps.

(yum install glibc gcc glibc-devel autoconf)


[2012-08-21 07:45:09] paszczak000 at gmail dot com

The same result with: 5.4.6 on CentOS release 6.3 (Final).


[2012-06-16 09:01:29] paszczak000 at gmail dot com

The same error I have on CentOS release 6.2 (Final) - 
2.6.32-220.13.1.el6.centos.plus.x86_64.

./configure --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin 
--sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share 
--includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec 
--localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man 
--infodir=/usr/share/info --cache-file=../config.cache --with-libdir=lib64 
--with-config-file-path=/etc --with-config-file-scan-dir=/etc/php.d 
--disable-debug --with-pic --disable-rpath --without-pear --with-bz2 
--with-curl --with-freetype-dir=/usr --with-gd --enable-gd-jis-conv 
--enable-gd-native-ttf --with-gdbm --with-gmp --enable-mbstring --with-iconv 
--with-jpeg-dir=/usr --with-pspell -with-zlib --with-zlib-dir=/usr/include 
--with-layout=GNU --enable-exif --enable-ftp --enable-sockets --enable-sysvsem 
--enable-sysvshm --enable-sysvmsg --enable-wddx --with-unixODBC=shared,/usr 
--enable-shmop --enable-calendar --without-sqlite3 --without-pdo-sqlite 
--with-libxml-dir=/usr --with-mhash --with-mcrypt --with-apxs2 --disable-d
 ba --without-unixODBC --enable-json --with-mysql --with-mysqli --enable-soap 
--with-imap-ssl --with-imap --with-openssl --with-kerberos --enable-bcmath 
--with-pdo-mysql --with-pear=/usr/lib/php --with-gettext

But version PHP 5.4.1 with the same options in compiling very well.




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=61859


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

Bug #64874 [Com]: json_decode handles whitespace and case-sensitivity incorrectly

[cmbecker69 at gmx dot de]

Edit report at https://bugs.php.net/bug.php?id=64874&edit=1

 ID: 64874
 Comment by: cmbecker69 at gmx dot de
 Reported by:chrivers at iversen-net dot dk
 Summary:json_decode handles whitespace and case-sensitivity
 incorrectly
 Status: Open
 Type:   Bug
 Package:JSON related
 Operating System:   All
 PHP Version:5.4.15
 Block user comment: N
 Private report: N

 New Comment:

There is a RFC[1] to replace the current JSON implementation with
the jsonc PECL extension, so "fixing" that implementation may not 
be reasonable anyway.

[1] 


Previous Comments:

[2013-09-09 16:24:12] ajf at ajf dot me

D:\Projects>php -r "var_dump(json_decode('tRUe'));"
bool(true)

Seems to still be broken, I'll try to fix it.


[2013-05-19 20:04:53] chrivers at iversen-net dot dk

Well, the part of the RFC that you're quoting describes the "JSON-text" type, 
which indeed must be non-
primitive.

However, the json_decode() function is documented as taking a "json value", 
which according to the spec 
is 

"""
   A JSON value MUST be an object, array, number, or string, or one of
   the following three literal names:

  false null true
"""

So that's perfectly fine, really.

There are other errors, too. For example, " true" WORKS while "true " fails, 
which makes no sense at 
all. I've created an updated test case:

 0],
$error[json_decode($x) !== $y]
  );
}

printf($fmt, "JSON", "Expected", "Actual", "JSON_ERROR", "PASS");
printf("--
\n");

// works
json_cmp("true", true);

// fails - is actually true
json_cmp("tRue", NULL);

// fails - is actually NULL
json_cmp("true ", true);

// works
json_cmp("[true ] ", array(true));
json_cmp("[ true ] ", array(true));
json_cmp("[true] ", array(true));

// works, even though the non-array version fails
json_cmp("[tRue]", NULL);

json_cmp("0", 0);
json_cmp("1", 1);

json_cmp("false", false);

json_cmp("'foo'", NULL);

json_cmp('"foo"', "foo");

json_cmp('1.123', 1.123);
json_cmp('1.123 ', 1.123);
json_cmp(' 1.123', 1.123);

json_cmp('42', 42);
json_cmp('42 ', 42);
json_cmp(' 42', 42);

json_cmp(".123", 0.123);

?>


Which gives the following results:

JSON Expected Actual   JSON_ERROR PASS 
--
'true'   true true -  -
'tRue'   NULL true -  FAIL 
'true '  true NULL FAIL   FAIL 
'[true ] '   array (  0 => true,) array (  0 => true,) -  -
'[ true ] '  array (  0 => true,) array (  0 => true,) -  -
'[true] 'array (  0 => true,) array (  0 => true,) -  -
'[tRue]' NULL NULL FAIL   -
'0'  00-  -
'1'  11-  -
'false'  falsefalse-  -
'\'foo\''NULL NULL FAIL   -
'"foo"'  'foo''foo'-  -
'1.123'  1.1231.123-  -
'1.123 ' 1.123NULL FAIL   FAIL 
' 1.123' 1.1231.123-  -
'42' 42   42   -  -
'42 '42   NULL FAIL   FAIL 
' 42'42   42   -  -
'.123'   0.1230.123-  -


I see "FAIL" 4 times, so that seems like 4 bugs to me.


[2013-05-18 15:00:32] cmbecker69 at gmx dot de

RFC 4627[1] also states in section 2:

| A JSON text is a serialized object or array.
| 
|JSON-text = object / array

According to that definition the $json argument of examples 1-3 
is not a valid JSON-text.

Furthermore:
  json_decode('true ');
  var_dump(json_last_error() === JSON_ERROR_SYNTAX);
prints:
  bool(true)
So the returned NULL is actually correct according to the documentation.

[1] 


[2013-05-17 21:48:29] chrivers at iversen-net dot dk

Description:

There are 2 problems with the json_decode function.

1) It only sometimes disregards whitespace

The RFC clearly says:

"""Insignificant whitespace is allowed before or after any of the six 
structural 
characters."""

2) It only sometimes 

Bug #64874 [Com]: json_decode handles whitespace and case-sensitivity incorrectly

[ajf at ajf dot me]

Edit report at https://bugs.php.net/bug.php?id=64874&edit=1

 ID: 64874
 Comment by: ajf at ajf dot me
 Reported by:chrivers at iversen-net dot dk
 Summary:json_decode handles whitespace and case-sensitivity
 incorrectly
 Status: Open
 Type:   Bug
 Package:JSON related
 Operating System:   All
 PHP Version:5.4.15
 Block user comment: N
 Private report: N

 New Comment:

D:\Projects>php -r "var_dump(json_decode('tRUe'));"
bool(true)

Seems to still be broken, I'll try to fix it.


Previous Comments:

[2013-05-19 20:04:53] chrivers at iversen-net dot dk

Well, the part of the RFC that you're quoting describes the "JSON-text" type, 
which indeed must be non-
primitive.

However, the json_decode() function is documented as taking a "json value", 
which according to the spec 
is 

"""
   A JSON value MUST be an object, array, number, or string, or one of
   the following three literal names:

  false null true
"""

So that's perfectly fine, really.

There are other errors, too. For example, " true" WORKS while "true " fails, 
which makes no sense at 
all. I've created an updated test case:

 0],
$error[json_decode($x) !== $y]
  );
}

printf($fmt, "JSON", "Expected", "Actual", "JSON_ERROR", "PASS");
printf("--
\n");

// works
json_cmp("true", true);

// fails - is actually true
json_cmp("tRue", NULL);

// fails - is actually NULL
json_cmp("true ", true);

// works
json_cmp("[true ] ", array(true));
json_cmp("[ true ] ", array(true));
json_cmp("[true] ", array(true));

// works, even though the non-array version fails
json_cmp("[tRue]", NULL);

json_cmp("0", 0);
json_cmp("1", 1);

json_cmp("false", false);

json_cmp("'foo'", NULL);

json_cmp('"foo"', "foo");

json_cmp('1.123', 1.123);
json_cmp('1.123 ', 1.123);
json_cmp(' 1.123', 1.123);

json_cmp('42', 42);
json_cmp('42 ', 42);
json_cmp(' 42', 42);

json_cmp(".123", 0.123);

?>


Which gives the following results:

JSON Expected Actual   JSON_ERROR PASS 
--
'true'   true true -  -
'tRue'   NULL true -  FAIL 
'true '  true NULL FAIL   FAIL 
'[true ] '   array (  0 => true,) array (  0 => true,) -  -
'[ true ] '  array (  0 => true,) array (  0 => true,) -  -
'[true] 'array (  0 => true,) array (  0 => true,) -  -
'[tRue]' NULL NULL FAIL   -
'0'  00-  -
'1'  11-  -
'false'  falsefalse-  -
'\'foo\''NULL NULL FAIL   -
'"foo"'  'foo''foo'-  -
'1.123'  1.1231.123-  -
'1.123 ' 1.123NULL FAIL   FAIL 
' 1.123' 1.1231.123-  -
'42' 42   42   -  -
'42 '42   NULL FAIL   FAIL 
' 42'42   42   -  -
'.123'   0.1230.123-  -


I see "FAIL" 4 times, so that seems like 4 bugs to me.


[2013-05-18 15:00:32] cmbecker69 at gmx dot de

RFC 4627[1] also states in section 2:

| A JSON text is a serialized object or array.
| 
|JSON-text = object / array

According to that definition the $json argument of examples 1-3 
is not a valid JSON-text.

Furthermore:
  json_decode('true ');
  var_dump(json_last_error() === JSON_ERROR_SYNTAX);
prints:
  bool(true)
So the returned NULL is actually correct according to the documentation.

[1] 


[2013-05-17 21:48:29] chrivers at iversen-net dot dk

Description:

There are 2 problems with the json_decode function.

1) It only sometimes disregards whitespace

The RFC clearly says:

"""Insignificant whitespace is allowed before or after any of the six 
structural 
characters."""

2) It only sometimes enforces lowercase-ness of identifiers

The RFC clearly says:

"""The literal names MUST be lowercase. No other literal names are allowed."""

The test script demonstrates this

Test script:
---



Expected result:

true * 5

Actual result:
--
bool(true)
bool(false)
bool(false)
bool(tr

[PHP-BUG] Bug #65642 [NEW]: sysconfdir broken in 64-bit Windows build

[krishean+php at gmail dot com]

From: krishean+php at gmail dot com
Operating system: Windows 7 x64
PHP version:  5.5.3
Package:  LDAP related
Bug Type: Bug
Bug description:sysconfdir broken in 64-bit Windows build

Description:

When trying to bind to an ldap server over ssl, you need a file called
"ldap.conf" in the directory "C:\openldap\sysconf" with a few options in it
(at least on Windows, Linux is somewhere in /etc.) In the past (php 5.4
etc.) this worked wonderfully, with php checking that directory, loading
the file, and connecting to the server just fine. In php 5.5.3 however,
this is completely broken. I used Process Monitor to check where it was
searching for ldap.conf and it seems to be searching as such:
"G:\Documents\Projects\ProjectName\%SYSCONFDIR%\ldap.conf" (the ProjectName
directory being where the currently executing script is located.) I checked
and php 5.4.18 checks in the correct directory:
"C:\openldap\sysconf\ldap.conf"

Test script:
---
$host = 'ldaps://server01';
$port = 636;
$rdn = 'CN=Jeff Smith,CN=users,DC=fabrikam,DC=com';
$pwd = 'password';
if(($conn = @ldap_connect($host, $port)) != FALSE){
ldap_set_option($conn, LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($conn, LDAP_OPT_REFERRALS, 0);
// bind to ldap connection
if(($r = @ldap_bind($conn, $rdn, $pwd)) != FALSE){
echo("Successfully connected to LDAP.\n");
}else{
echo("Error: Failed to bind to LDAP.\n"); // this happens
if($conn){
ldap_unbind($conn);
}
$conn = null;
}
}else echo("Error: Failed to connect to LDAP.\n");

Expected result:

Script should bind to ldap server over ssl (ldaps://) and report success.

Actual result:
--
Script fails to bind to ldap server over ssl.

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

Bug #65571 [Com]: Compiling fails with - missing binary operator before token "extern"

[pascal at nobus dot be]

Edit report at https://bugs.php.net/bug.php?id=65571&edit=1

 ID: 65571
 Comment by: pascal at nobus dot be
 Reported by:tony dot ar dot wright at bt dot com
 Summary:Compiling fails with - missing binary operator
 before token "extern"
 Status: Open
 Type:   Bug
 Package:Compile Failure
 Operating System:   SuSE 9
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

I had the same problem on php-5.4.19
This on a slackware-10.1

Tried the snapshot (php5.4-201309091030), and it seems to be fixed there?

However I have no idea with what change the bug is fixed.


Previous Comments:

[2013-08-28 09:37:25] tony dot ar dot wright at bt dot com

Description:

I installed 5.5.2 ok but when I tried to install 5.5.3 I get the error message:

In file included from Zend/zend_language_scanner.l:40:
Zend/zend_language_parser.h:40:1: missing binary operator before token "extern"
make: *** [Zend/zend_language_scanner.lo] Error 1


Configure options used:

'./configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--enable-ftp' '--witho
ut-ldap' '--enable-sockets' '--with-gd' '--with-freetype-dir' '--without-mcrypt'
 '--with-zlib-dir' '--with-png-dir' '--with-oci8=/export/oracle/product/10.2.0/d
b_1' '--with-openssl'








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

Bug #65637 [Nab]: Using division PHP_ROUND_HALF_UP rounds DOWN when working with 2 precision

[productivepc at hotmail dot com]

Edit report at https://bugs.php.net/bug.php?id=65637&edit=1

 ID: 65637
 User updated by:productivepc at hotmail dot com
 Reported by:productivepc at hotmail dot com
 Summary:Using division PHP_ROUND_HALF_UP rounds DOWN when
 working with 2 precision
 Status: Not a bug
 Type:   Bug
 Package:Math related
 Operating System:   Windows 7
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

Okay.  Thanks for looking in to it.  This can be closed.


Previous Comments:

[2013-09-09 06:59:03] requi...@php.net

$additionalPcCostPerDay is either 3.33 (rounded to two) or 3.333 (rounded to 
three). The actual value is ~3.3328. The rounding there is correct.

As for 0.05 drop, the difference "lost" using two decimal places is -0.003 * 16 
= 
-0.048 and you round that off to -0.05. So that's where it came from. It sounds 
like you expect the rounding to carry from one number to the next? That's not 
how 
rounding works. That's why you always round at the very end of the set of 
calculations.


[2013-09-09 05:49:28] productivepc at hotmail dot com

I went ahead and wrote it before I went to bed.  The only thing you have to 
change is the 3 to a 2 in this line:  $additionalPcCostPerDay = 
round($additionalPcCost/$totalWorkingDays,3,PHP_ROUND_HALF_UP);
You will see the price go from 182.09 when it is looking at 3 decimal places to 
182.04 when it is looking at 2 decimal places.  When rounding up even if the 
number previously was a 6 I would expect it to go to 182.10 and not drop $.05.

mainPcCost: " . $mainPcCost . "additionalPcCost: " . 
$additionalPcCost;
//  echo "additionalpcs: " . $additionalpcs;
//  echo "WorkingDaysLeft: " . $workingDaysLeft . 
"totalWorkingDays: 
" . $totalWorkingDays;
//  echo "mainPcCostPerDay: " . $mainPcCostPerDay . "
additionalPcCostPerDay: " . $additionalPcCostPerDay;
//  echo "mainPcProratedCost: " . $mainPcProratedCost . "
additionalPcProratedCost: " . $additionalPcProratedCost;
echo "totalProratedCost: " . $totalProratedCost;// . "
costPerFullMonth: " . $costPerFullMonth;
?>


[2013-09-09 05:34:34] productivepc at hotmail dot com

In your example, you are rounding to 1 decimal place and yes absolutely that 
will 
throw it off however if you do =PRODUCT(ROUNDUP(1.45,2),1000) = 1450. I removed 
all rounding except for the $additionalPcCostPerDay = 
round($additionalPcCost/$totalWorkingDays,3,PHP_ROUND_HALF_UP); and the error 
still happens.  When I attempt to round to 2 decimal places the rounding 
appears 
to round down and not up.  When I do it to 3 then it works as expected.  It is 
1:33am.  I will write a smaller script tomorrow after I sleep and post it here.


[2013-09-09 02:57:46] requi...@php.net

And by the way, you know that rounding numbers too early will throw off future 
calculations, right? 1.45 * 1000 = 1450 but roundup(1.45, 1) * 1000 = 1500. 
Don't 
round until the very end.


[2013-09-09 02:48:04] requi...@php.net

The script you've provided doesn't output the example numbers you gave. I get

additionalPcCostPerDay: 0.159 or 0.16
additionalPcProratedCost: 2.54 or 2.56
totalProratedCost: 131.34 or 131.36

Want to try the repro script again? Hopefully something a bit smaller with 
fewer 
variables?




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=65637


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

Bug #65590 [Opn]: Apache segfaults and reports zend_mm_heap corrupted

[ole dot skudsvik at gmail dot com]

Edit report at https://bugs.php.net/bug.php?id=65590&edit=1

 ID: 65590
 User updated by:ole dot skudsvik at gmail dot com
 Reported by:ole dot skudsvik at gmail dot com
 Summary:Apache segfaults and reports zend_mm_heap corrupted
 Status: Open
 Type:   Bug
 Package:Apache2 related
 Operating System:   Linux, CentOS 6
 PHP Version:5.4.19
 Block user comment: N
 Private report: N

 New Comment:

What i've found is that if you disable opcache.fast_shutdown in php.ini we do 
not experience any crashes.

The documentation of opcache.fast_shutdown states:

If enabled, a fast shutdown sequence is used for the accelerated code
The fast shutdown sequence doesn't free each allocated block, but lets
the Zend Engine Memory Manager do the work.

I've im also now able to reproduce the segfault by doing the following:


What i think happen here is:

* We call opcache_reset() which triggers a free() on all opcache allocated 
resources.

* We start the Zend application.

* When the Zend application shuts down Zend tries to free the already free'ed 
memory since it's told to do so by the fast_shutdown flag.

Ofcourse Zend should check if the memory is already free'd before trying to 
free 
it, but it seems it does not ?


Previous Comments:

[2013-08-30 09:01:29] ole dot skudsvik at gmail dot com

Description:

We are experiencing regular Apache segfaults.

We are sadly not able to reproduce as this seems to happen randomly when apache 
have been running for a while. Neither can we relate the problem to any 
spesific 
PHP code.

Apache error.log:

[Wed Aug 28 13:00:50 2013] [notice] child pid 31638 exit signal Segmentation 
fault (11)
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
zend_mm_heap corrupted
[Wed Aug 28 13:43:58 2013] [notice] child pid 13750 exit signal Segmentation 
fault (11)


GDB Backtrace:

Core was generated by `/usr/sbin/httpd'.
Program terminated with signal 11, Segmentation fault.
#0  zend_mm_add_to_free_list (heap=, 
mm_block=0x7f8e9aef8cc0) at /usr/src/debug/php-5.4.19/Zend/zend_alloc.c:748
748 if (ZEND_MM_FREE_BLOCK_SIZE(prev) != size) {
(gdb) bt
#0  zend_mm_add_to_free_list (heap=, 
mm_block=0x7f8e9aef8cc0) at /usr/src/debug/php-5.4.19/Zend/zend_alloc.c:748
#1  0x7f8e8ed74412 in _zend_mm_free_int (heap=0x7f8e9a32d6a0, 
p=0x7f8e9aef8cd0) at /usr/src/debug/php-5.4.19/Zend/zend_alloc.c:2114
#2  0x7f8e8eda6ad1 in zend_hash_destroy (ht=0x7f8e8f19ffd0) at 
/usr/src/debug/php-5.4.19/Zend/zend_hash.c:565
#3  0x7f8e8ed8d173 in shutdown_executor () at /usr/src/debug/php-
5.4.19/Zend/zend_execute_API.c:322
#4  0x7f8e8ed99e52 in zend_deactivate () at /usr/src/debug/php-
5.4.19/Zend/zend.c:938
#5  0x7f8e8ed3c67c in php_request_shutdown (dummy=) at 
/usr/src/debug/php-5.4.19/main/main.c:1803
#6  0x7f8e8ee44037 in php_apache_request_dtor (r=0x7f8e9ac8d1a8) at 
/usr/src/debug/php-5.4.19/sapi/apache2handler/sapi_apache2.c:507
#7  php_handler (r=0x7f8e9ac8d1a8) at /usr/src/debug/php-
5.4.19/sapi/apache2handler/sapi_apache2.c:679
#8  0x7f8e97ea0bb0 in ap_run_handler (r=0x7f8e9ac8d1a8) at 
/usr/src/debug/httpd-2.2.15/server/config.c:158
#9  0x7f8e97ea446e in ap_invoke_handler (r=0x7f8e9ac8d1a8) at 
/usr/src/debug/httpd-2.2.15/server/config.c:376
#10 0x7f8e97eafb30 in ap_process_request (r=0x7f8e9ac8d1a8) at 
/usr/src/debug/httpd-2.2.15/modules/http/http_request.c:282
#11 0x7f8e97eac9a8 in ap_process_http_connection (c=0x7f8e9ac80c18) at 
/usr/src/debug/httpd-2.2.15/modules/http/http_core.c:190
#12 0x7f8e97ea86b8 in ap_run_process_connection (c=0x7f8e9ac80c18) at 
/usr/src/debug/httpd-2.2.15/server/connection.c:43
#13 0x7f8e97eb4977 in child_main (child_num_arg=) at 
/usr/src/debug/httpd-2.2.15/server/mpm/prefork/prefork.c:667
#14 0x7f8e97eb4c8a in make_child (s=0x7f8e99ffe860, slot=6) at 
/usr/src/debug/httpd-2.2.15/server/mpm/prefork/prefork.c:763
#15 0x7f8e97eb590c in perform_idle_server_maintenance (_pconf=, plog=, s=) at 
/usr/src/debug/httpd-2.2.15/server/mpm/prefork/prefork.c:898
#16 ap_mpm_run (_pconf=, plog=, 
s=) at /usr/src/debug/httpd-
2.2.15/server/mpm/prefork/prefork.c:1102
#17 0x7f8e97e8c900 in main (argc=1, argv=0x7fffb01ca148) at 
/usr/src/debug/httpd-2.2.15/server/main.c:760

A complete strace of the crash is available here: 
https://gist.github.com/olesku/6387821

Test script:
---
Currently not able to reproduce.







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

Bug #65633 [Opn]: built-in server treat some http headers as case-sensitive

[francesco dot laffi at gmail dot com]

Edit report at https://bugs.php.net/bug.php?id=65633&edit=1

 ID: 65633
 User updated by:francesco dot laffi at gmail dot com
 Reported by:francesco dot laffi at gmail dot com
-Summary:PHP built-in server
+Summary:built-in server treat some http headers as
 case-sensitive
 Status: Open
 Type:   Bug
 Package:Built-in web server
 PHP Version:5.5Git-2013-09-08 (snap)
 Block user comment: N
 Private report: N

 New Comment:

edited title


Previous Comments:

[2013-09-08 13:43:56] francesco dot laffi at gmail dot com

Description:

The built-in server look for info in same headers in a case-sensitive way, but 
the 
rfc2616 define http headers fields as case insensitive. 
i.e. 'cookie: foo=bar' should be recognized but the the current cli server only 
recognize correctly 'Cookie: foo=bar'

I tried to fiddle with the code to confirm it, i.e in 
`sapi/cli/php_cli_server.c` 
in the function `sapi_cli_server_read_cookies`:
replace: if (FAILURE == zend_hash_find(&client->request.headers, "Cookie", 
sizeof("Cookie"), (void**)&val))
with: if (FAILURE == zend_hash_find(&client->request.headers, "Cookie", 
sizeof("Cookie"), (void**)&val) && FAILURE == zend_hash_find(&client-
>request.headers, "cookie", sizeof("cookie"), (void**)&val))

And cookies then worked correctly even with lowercase header field. 
I never developed in C so I wont be able to produce a full patch. The above 
snippet is not a suggestion on how to fix it, just pointing where the bug is. 
In 
the same file I see there are other headers checked in the same way. 

I also noticed that even if it doesnt fill the $_COOKIE superglobal it does put 
the cookie header in $_SERVER['HTTP_COOKIE'], so its already case-insensitive 
in 
some code.

Looking around about this I found this bug on other projects but I didnt 
found it here, other sources for reference:
https://github.com/symfony/symfony/issues/8278
https://github.com/37signals/pow/issues/319

Test script:
---
echo ' index.php
php -S 127.0.0.1:8080
curl http://127.0.0.1:8080 -H 'Cookie: foo=bar'
curl http://127.0.0.1:8080 -H 'cookie: foo=bar'


Expected result:

the two curl request return the same output

Actual result:
--
> curl http://127.0.0.1:8080 -H 'Cookie: foo=bar'
array(1) {
  ["foo"]=>
  string(3) "bar"
}
> curl http://127.0.0.1:8080 -H 'cookie: foo=bar'
array(0) {
}






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

[PHP-BUG] Bug #65641 [NEW]: PHP-FPM incorrectly defines the SCRIPT_NAME variable when using Apache

[ryotakatsuki at gmail dot com]

From: ryotakatsuki at gmail dot com
Operating system: 
PHP version:  5.5.3
Package:  FPM related
Bug Type: Bug
Bug description:PHP-FPM incorrectly defines the SCRIPT_NAME variable when using 
Apache

Description:

When using Apache + PHP_FPM, the SCRIPT_NAME variable is incorrectly set.
For 
example, accessing "http://127.0.0.1/sample/test.php/a/b/c";, results in:

ORIG_SCRIPT_NAME: 
SCRIPT_NAME: /sample/test.php/a/b/c
ORIG_SCRIPT_FILENAME: //tmp/sample/test.php/a/b/c
SCRIPT_FILENAME: //tmp/sample/test.php
PATH_INFO: /a/b/c
ORIG_PATH_INFO: 

While when using mod_php, the values are:

SCRIPT_NAME: /sample/test.php
SCRIPT_FILENAME: /tmp/sample/test.php
PATH_INFO: /a/b/c

It is also working fine when using NGINX

Test script:
---
A sameple script to reproduce the issue:

');

echo("SCRIPT_NAME: " . $_SERVER['SCRIPT_NAME']);
echo('');
echo("ORIG_SCRIPT_FILENAME: " . $_SERVER['ORIG_SCRIPT_FILENAME']);
echo('');

echo("SCRIPT_FILENAME: " . $_SERVER['SCRIPT_FILENAME']);
echo('');

echo("PATH_INFO: " . $_SERVER['PATH_INFO']);
echo('');

echo("ORIG_PATH_INFO: " . $_SERVER['ORIG_PATH_INFO']);
echo('');

?>

And a very simple apache conf:

Alias /sample /tmp/sample
ProxyPassMatch .*/sample/(test.php.*) fcgi://127.0.0.1:9000//tmp/sample/$1

Require  all granted



Expected result:

ORIG_SCRIPT_NAME: 
SCRIPT_NAME: /sample/test.php
ORIG_SCRIPT_FILENAME: //tmp/sample/test.php/a/b/c
SCRIPT_FILENAME: //tmp/sample/test.php
PATH_INFO: /a/b/c
ORIG_PATH_INFO: 


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

Bug #49104 [Com]: AppendIterator::append($iterator) calls $iterator->rewind() with no reason

[hanskrentel at yahoo dot de]

Edit report at https://bugs.php.net/bug.php?id=49104&edit=1

 ID: 49104
 Comment by: hanskrentel at yahoo dot de
 Reported by:seva dot lapsha at gmail dot com
 Summary:AppendIterator::append($iterator) calls
 $iterator->rewind() with no reason
 Status: Assigned
 Type:   Bug
 Package:SPL related
 Operating System:   *
 PHP Version:5.3.0
 Assigned To:colder
 Block user comment: N
 Private report: N

 New Comment:

AppendIterator just takes care that the internal iterator state is at a 
validated position of at least one iterator. This perhaps is not necessary at 
all, but it *might* be needed to take care of internal iterator states as PHP 
shares a lot of code across iterators (as this ticket didn't get much traction 
nor feedback from core developers, I'd say in summary nobody wants to fiddle 
with that). In the end AppendIterator is still an IteratorIterator and those 
have this internal state:

Compare: Why must I rewind IteratorIterator - 
http://stackoverflow.com/q/2458955/367456

In code: http://lxr.php.net/xref/PHP_5_4/ext/spl/spl_iterators.c#3347

If rewind on appending is an issue - and despite / in contrast to what has been 
outlined as workaround already - if those safety checks PHP does are not 
wanted, 
you can take care your own by adding the iterators directly to the internal 
collection of iterators:

getArrayIterator();
$i->append($i1);
$i->append($i2);

Some notes:

- You can append anything here, no type-check is enforced. However everything 
not a Traversable will crash the script on iteration when reached (e.g. exit 
code -1073741819). This has the benefit that unlike ArrayIterator::append() you 
*can* add Traversable (e.g. IteratorAggregate) and not only Iterator. This also 
works for Traversable only classes like DatePeriod.
- This still does work while iterating (as it does for 
AppendIterator::append()).
- ArrayAccess can be used, too: $i[] = $i1;

I hope this helps someone running into the issue in PHP user land.


Previous Comments:

[2011-03-23 18:32:46] demjan at kaluzki dot de

The rewind is invoked only on the first appended (not empty) inner-iterator. 

workaround:

$workaround = new 
ArrayIterator(array('delete_me_after_all_append_calls_are_done'));
$a = new ArrayIterator(array('a', 'b'));
$b = new ArrayIterator(array('c', 'd'));

$append = new AppendIterator();
$append->append($workaround); // invokes implicit: 
  // $workaround->rewind(); 
  // $workaround->valid(); 
  // $workaround->current(); 
  // $workaround->key(); 
  // $workaround->rewind();
$append->append($a);
$append->append($b);
unset($workaround[0]); // no further append calls are allowed, 
   // otherwise it seems to hang up in infinite loop


[2009-07-29 22:57:40] seva dot lapsha at gmail dot com

Line 6:
x This causes append to happen twice:
should be read as
* This causes rewind to happen twice:)


[2009-07-29 22:54:19] seva dot lapsha at gmail dot com

Description:

AppendIterator::append($iterator) calls $iterator->rewind() with no reason.

This causes append to happen twice:

1) when $iterator appended;
2) when $iterator starts iterating.



Reproduce code:
---
append($i1);
$i->append($i2);

foreach ($i as $n) {
echo $n;
}
?>

Expected result:

.123.456

rewind() of each append()ed iterator should be called on demand when iterating 
and not when append()ing.

Actual result:
--
..123.456

On each append() each append()ed iterator's rewind is called with no need.






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

Bug #65639 [Opn->Nab]: in_array unexpected result

[requinix]

Edit report at https://bugs.php.net/bug.php?id=65639&edit=1

 ID: 65639
 Updated by: requi...@php.net
 Reported by:sv3tli0 at bgspot dot eu
 Summary:in_array unexpected result
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Arrays related
 Operating System:   Ubuntu 13.04
 PHP Version:5.4.19
 Block user comment: N
 Private report: N

 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

in_array() does a loose comparison by default, and 0 == 'some string not INT'.
If you need a strict comparison then pass true for the third argument.

http://www.php.net/in-array


Previous Comments:

[2013-09-09 07:35:53] sv3tli0 at bgspot dot eu

Description:

Wrong result if you are checking array for existing integer 0, when array has 
none integer values.. 

Test script:
---
$array = array(1,2,3);
var_dump(in_array(0, $array)); 

$array = array(1,2,'some string not INT');
var_dump(in_array(0, $array)); 



Expected result:

boolean false 

boolean false

Actual result:
--
boolean false

boolean true






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

Bug #25678 [Com]: Issues with imageantialias and imagesetthickness

[adolf at sharklasers dot com]

Edit report at https://bugs.php.net/bug.php?id=25678&edit=1

 ID: 25678
 Comment by: adolf at sharklasers dot com
 Reported by:php-bugs at demark dot org
 Summary:Issues with imageantialias and imagesetthickness
 Status: Not a bug
 Type:   Bug
 Package:GD related
 Operating System:   Redhat 7.3 (2.4.20-20.7)
 PHP Version:4.3.3
 Block user comment: N
 Private report: N

 New Comment:

After 10 years the problem still exists! :(
A quick workaround would be to draw a second line 1 pixel displaced to the 
original line. You have 2 lines but it looks like one line with 2 pixels 
thickness.


Previous Comments:

[2003-09-28 18:57:35] php-bugs at demark dot org

Looks to be a bug in the GD library. I wrote a quick 
program in C to call GD directly and got the same 
results.


[2003-09-27 07:58:20] php-bugs at demark dot org

Description:

Neither imageantialias and imagesetthickness seem to work reliably.

The included code produces a significantly different image than one would 
expect.

Reproduce code:
---



Expected result:

This code should generate four figures on a 500 x 500 image. Each figure should 
be centered on the image.

Figure 1: Small square drawn via imageline
Figure 2: Medium square drawn via imagerectangle
Figure 3: Large square drawn via imagepolygon
Figure 4: Large circle drawn via imageellipse

All figures should be drawn with a 5 pixel thick line.
All figures should be antialiased.

Actual result:
--
As listed, the code generates a properly sized image, but none of the figures 
are antialiased and only the medium square is set to the proper thickness. All 
the other figures are drawn with a 1 pixel thick line.

This image is available at:
http://www.demark.org/phpgdbug/image.png

If I comment out the imageantialias line, no figures are antialiases (as 
expected), but only the squares are drawn with the proper thickness. Once 
again, the circle is drawn with a 1 pixel thick line.

This image is available at:
http://www.demark.org/phpgdbug/image-noaa.png








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

Bug #49013 [Com]: SOAPClient interprets the parameters array incorrectly

[cwei...@php.net]

Edit report at https://bugs.php.net/bug.php?id=49013&edit=1

 ID: 49013
 Comment by: cwei...@php.net
 Reported by:egos at biz-club dot biz
 Summary:SOAPClient interprets the parameters array
 incorrectly
 Status: Re-Opened
 Type:   Bug
 Package:SOAP related
 Operating System:   debian Lenny
 PHP Version:5.5.1
 Block user comment: N
 Private report: N

 New Comment:

I meant PHP 5.5.1, not 5.1.


Previous Comments:

[2013-09-04 13:54:14] cwei...@php.net

We can reproduce the issue on PHP 5.1, see the files at http://p.cweiske.de/53:

SoapClient: http://p.cweiske.de/53/raw/soapclienttest.php
WSDL: http://p.cweiske.de/53/raw/test.wsdl

We give an associative array of parameters:

$arguments = array(
'password' => 'password-value',
'username' => 'username-value',
);

But the SOAP request has the values in wrong order:

password-value
username-value


[2009-08-11 01:00:00] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".


[2009-08-03 15:17:46] j...@php.net

Please try using this snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/




[2009-07-22 07:20:03] egos at biz-club dot biz

Description:

on Debian Lenny (php 5.2.6.dfsg.1-1+lenny3) i run the simple call.

please, take a look at var_dump of the parameters variable and at the generated 
xml code

Before xml is generated, it sorts the parameters, so that values loose bindings 
to the keys of the array.

Reproduce code:
---
$client->__soapCall("updateMonitoring", $parameters);
var_dump($parameters);
echo "";
echo " REQUEST:\n" . $client->__getLastRequest() . "\n";




Expected result:

correct xml, based on $parameters. Here,s the var_dump of it $parameters I put 
there

  ["login"]=>
  string(4) "***"
  ["password"]=>
  string(32) "***"
  ["monitoring_id"]=>
  string(5) "18700"
  ["plan_budget_total"]=>
  string(2) "70"
  ["plan_budget_navigation"]=>
  string(1) "0"
  ["plan_pay"]=>
  string(2) "25"
  ["total"]=>
  int(66)
  ["task_training"]=>
  int(0)
  ["without_preliminary_examination"]=>
  int(0)
  ["without_competition"]=>
  int(0)
  ["city_0_59"]=>
  int(0)
  ["city_60_100"]=>
  int(0)
  ["city_101_110"]=>
  int(0)
  ["city_111_120"]=>
  int(0)
  ["city_121_130"]=>
  int(0)
  ["city_131_140"]=>
  int(0)
  ["city_141_150"]=>
  int(1)
  ["city_151_160"]=>
  int(1)
  ["city_161_170"]=>
  int(2)
  ["city_171_180"]=>
  int(0)
  ["city_181_190"]=>
  int(2)
  ["city_191_200"]=>
  int(2)
  ["city_201_210"]=>
  int(5)
  ["city_211_220"]=>
  int(3)
  ["city_221_230"]=>
  int(1)
  ["city_231_240"]=>
  int(8)
  ["city_241_250"]=>
  int(1)
  ["city_251_260"]=>
  int(4)
  ["city_261_270"]=>
  int(2)
  ["city_271_280"]=>
  int(5)
  ["city_281_290"]=>
  int(5)
  ["city_291_300"]=>
  int(3)
  ["city_301_310"]=>
  int(10)
  ["city_311_320"]=>
  int(3)
  ["city_321_330"]=>
  int(2)
  ["city_331_340"]=>
  int(2)
  ["city_341_400"]=>
  int(1)
  ["country_0_59"]=>
  int(0)
  ["country_60_100"]=>
  int(0)
  ["country_101_110"]=>
  int(0)
  ["country_111_120"]=>
  int(0)
  ["country_121_130"]=>
  int(0)
  ["country_131_140"]=>
  int(0)
  ["country_141_150"]=>
  int(0)
  ["country_151_160"]=>
  int(0)
  ["country_161_170"]=>
  int(0)
  ["country_171_180"]=>
  int(0)
  ["country_181_190"]=>
  int(0)
  ["country_191_200"]=>
  int(0)
  ["country_201_210"]=>
  int(1)
  ["country_211_220"]=>
  int(1)
  ["country_221_230"]=>
  int(0)
  ["country_231_240"]=>
  int(0)
  ["country_241_250"]=>
  int(1)
  ["country_251_260"]=>
  int(0)
  ["country_261_270"]=>
  int(0)
  ["country_271_280"]=>
  int(0)
  ["country_281_290"]=>
  int(0)
  ["country_291_300"]=>
  int(0)
  ["country_301_310"]=>
  int(0)
  ["country_311_320"]=>
  int(0)
  ["country_321_330"]=>
  int(0)
  ["country_331_340"]=>
  int(0)
  ["country_341_400"]=>
  int(0)
}

Actual result:
--

http://schemas.xmlsoap.org/soap/envelope/"; 
xmlns:ns1="urn:abiturient" xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"; 
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";>**187007002566011202253181425531032211100100







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=49013&edi

[PHP-BUG] Bug #65639 [NEW]: in_array unexpected result

[sv3tli0 at bgspot dot eu]

From: sv3tli0 at bgspot dot eu
Operating system: Ubuntu 13.04
PHP version:  5.4.19
Package:  Arrays related
Bug Type: Bug
Bug description:in_array unexpected result

Description:

Wrong result if you are checking array for existing integer 0, when array
has 
none integer values.. 

Test script:
---
$array = array(1,2,3);
var_dump(in_array(0, $array)); 

$array = array(1,2,'some string not INT');
var_dump(in_array(0, $array)); 



Expected result:

boolean false 

boolean false

Actual result:
--
boolean false

boolean true

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

Req #49493 [Com]: Add IPv6 support in gethostbyname()

[mikhey at zloy dot org]

Edit report at https://bugs.php.net/bug.php?id=49493&edit=1

 ID: 49493
 Comment by: mikhey at zloy dot org
 Reported by:tim987 at email dot com
 Summary:Add IPv6 support in gethostbyname()
 Status: Open
 Type:   Feature/Change Request
 Package:Network related
 Operating System:   *
 PHP Version:*
 Block user comment: N
 Private report: N

 New Comment:

Please, Add IPv6 support in gethostbyname


Previous Comments:

[2013-03-08 20:52:33] landy2005 at gmail dot com

any progress on this?


[2009-12-23 04:21:47] vnegrier at optilian dot com

Here is a patch (applies to 5.3.1 ext/standard/dns.c) 

If ipv6 is enabled, it will try first and fallback to ipv4 resolution if no 
record is found.

--- dns.c.orig  2009-12-23 05:13:19.0 +0100
+++ dns.c   2009-12-23 05:17:14.0 +0100
@@ -251,16 +251,27 @@
 {
struct hostent *hp;
struct in_addr in;
+   char* txt_addr;
+#if HAVE_IPV6
+   char txt_addr6[128];

-   hp = gethostbyname(name);
+   hp = gethostbyname2(name, AF_INET6);

if (!hp || !*(hp->h_addr_list)) {
-   return estrdup(name);
+#endif
+   hp = gethostbyname(name);
+   if (!hp || !*(hp->h_addr_list)) {
+   return estrdup(name);
+   }
+   memcpy(&in.s_addr, *(hp->h_addr_list), sizeof(in.s_addr));
+   txt_addr = inet_ntoa(in);
+#if HAVE_IPV6
+   } else {
+   inet_ntop(AF_INET6, *(hp->h_addr_list), txt_addr6, 
sizeof(txt_addr6));
+   txt_addr = txt_addr6;
}
-
-   memcpy(&in.s_addr, *(hp->h_addr_list), sizeof(in.s_addr));
-
-   return estrdup(inet_ntoa(in));
+#endif
+   return estrdup(txt_addr);
 }
 /* }}} */


[2009-09-08 03:42:15] tim987 at email dot com

Description:

The php function gethostbyname currently only returns IPv4 addresses as stated 
here:

http://us2.php.net/manual/en/function.gethostbyname.php

My feature request is, it should be able to return IPv6 addresses too.









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

Bug #65637 [Fbk->Nab]: Using division PHP_ROUND_HALF_UP rounds DOWN when working with 2 precision

[requinix]

Edit report at https://bugs.php.net/bug.php?id=65637&edit=1

 ID: 65637
 Updated by: requi...@php.net
 Reported by:productivepc at hotmail dot com
 Summary:Using division PHP_ROUND_HALF_UP rounds DOWN when
 working with 2 precision
-Status: Feedback
+Status: Not a bug
 Type:   Bug
 Package:Math related
 Operating System:   Windows 7
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

$additionalPcCostPerDay is either 3.33 (rounded to two) or 3.333 (rounded to 
three). The actual value is ~3.3328. The rounding there is correct.

As for 0.05 drop, the difference "lost" using two decimal places is -0.003 * 16 
= 
-0.048 and you round that off to -0.05. So that's where it came from. It sounds 
like you expect the rounding to carry from one number to the next? That's not 
how 
rounding works. That's why you always round at the very end of the set of 
calculations.


Previous Comments:

[2013-09-09 05:49:28] productivepc at hotmail dot com

I went ahead and wrote it before I went to bed.  The only thing you have to 
change is the 3 to a 2 in this line:  $additionalPcCostPerDay = 
round($additionalPcCost/$totalWorkingDays,3,PHP_ROUND_HALF_UP);
You will see the price go from 182.09 when it is looking at 3 decimal places to 
182.04 when it is looking at 2 decimal places.  When rounding up even if the 
number previously was a 6 I would expect it to go to 182.10 and not drop $.05.

mainPcCost: " . $mainPcCost . "additionalPcCost: " . 
$additionalPcCost;
//  echo "additionalpcs: " . $additionalpcs;
//  echo "WorkingDaysLeft: " . $workingDaysLeft . 
"totalWorkingDays: 
" . $totalWorkingDays;
//  echo "mainPcCostPerDay: " . $mainPcCostPerDay . "
additionalPcCostPerDay: " . $additionalPcCostPerDay;
//  echo "mainPcProratedCost: " . $mainPcProratedCost . "
additionalPcProratedCost: " . $additionalPcProratedCost;
echo "totalProratedCost: " . $totalProratedCost;// . "
costPerFullMonth: " . $costPerFullMonth;
?>


[2013-09-09 05:34:34] productivepc at hotmail dot com

In your example, you are rounding to 1 decimal place and yes absolutely that 
will 
throw it off however if you do =PRODUCT(ROUNDUP(1.45,2),1000) = 1450. I removed 
all rounding except for the $additionalPcCostPerDay = 
round($additionalPcCost/$totalWorkingDays,3,PHP_ROUND_HALF_UP); and the error 
still happens.  When I attempt to round to 2 decimal places the rounding 
appears 
to round down and not up.  When I do it to 3 then it works as expected.  It is 
1:33am.  I will write a smaller script tomorrow after I sleep and post it here.


[2013-09-09 02:57:46] requi...@php.net

And by the way, you know that rounding numbers too early will throw off future 
calculations, right? 1.45 * 1000 = 1450 but roundup(1.45, 1) * 1000 = 1500. 
Don't 
round until the very end.


[2013-09-09 02:48:04] requi...@php.net

The script you've provided doesn't output the example numbers you gave. I get

additionalPcCostPerDay: 0.159 or 0.16
additionalPcProratedCost: 2.54 or 2.56
totalProratedCost: 131.34 or 131.36

Want to try the repro script again? Hopefully something a bit smaller with 
fewer 
variables?


[2013-09-09 00:24:58] productivepc at hotmail dot com

Description:

PHP Version 5.5.0
Results on Screen when precision is set to 2 for $additionalPcCostPerDay.

mainPcCost: 169
additionalPcCost: 3.3328571428571
WorkingDaysLeft: 16
totalWorkingDays: 21
mainPcCostPerDay: 8.05
additionalPcCostPerDay: 3.333
mainPcProratedCost: 128.8
additionalPcProratedCost: 53.33
totalProratedCost: 182.13

=
Results on screen when I change the precision to 2.  Please notice everything 
has stayed the same but the totalProratedCost has changed.  
contracttermid: 2
businesstypeid: 1
mainPcCost: 169
additionalPcCost: 3.3328571428571
WorkingDaysLeft: 16
totalWorkingDays: 21
mainPcCostPerDay: 8.05
additionalPcCostPerDay: 3.33
mainPcProratedCost: 128.8
additionalPcProratedCost: 53.28
totalProratedCost: 182.08

I noticed something because I have this same thing programmed in excel.  I 
decided to add the ROUNDUP function to my excel document just like I have it in 
PHP to ensure that everything worked exactly the same and I noticed that when I 
went to 2 decimals excel actually changed the additionalPcCostPerDay to 3.34 
instead of keeping it 3.33 therefore raising the price to 182.24 and PHP 
brought 
the price down to 182.08 instead of keeping it 182.13.  Looking in to this 
further, if I use the ROUNDDOWN function 
within