Bug #65118 [Com]: Building with IBM xlc phar enabled or make test results in segmentation fault

[howard dot allison at pva dot sozvers dot at]

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

 ID: 65118
 Comment by: howard dot allison at pva dot sozvers dot at
 Reported by:howard dot allison at chello dot at
 Summary:Building with IBM xlc  phar enabled or make test
 results in segmentation fault
 Status: Open
 Type:   Bug
 Package:Compile Failure
 Operating System:   AIX 6.1
 PHP Version:5.4.16
 Block user comment: N
 Private report: N

 New Comment:

try changing your optimizer flag from -O to -O1


Previous Comments:

[2013-06-25 06:45:41] howard dot allison at chello dot at

Description:

Using IBM xlc with the following environment:
LDFLAGS=-L/opt/pware/lib -Wl,-blibpath:/opt/pware/lib:/usr/lib 
-Wl,-bmaxdata:0x8000
CFLAGS=-qmaxmem=-1 -DSYSV -D_AIX -D_AIX32 -D_AIX41 -D_AIX43 -D_AIX51 -D_AIX52 
-D_AIX53 -D_AIX61 -D_ALL_SOURCE -DFUNCPROTO=15 -O -I/opt/pware/include

on AIX 6.1 cannot build PHP with phar , and even if built without phar 
generates a core dump on make test.

Test script:
---
./configure --with-iconv=/opt/pware --with-libxml-dir=/opt/pware --enable-debug
make

Expected result:

successful make

Actual result:
--
Segmentation fault in zend_mm_panic at line 92 in file 
"/app/RpmBuild/Work/php-5.4.16/Zend/zend_alloc.c" ($t1)
   92   kill(getpid(), SIGSEGV);
(dbx) where
zend_mm_panic(message = "\200A"), line 92 in "zend_alloc.c"
_zend_mm_alloc_int(heap = (nil), size = 297, __zend_filename = (nil), 
__zend_lineno = 273675100, __zend_orig_filename = warning: Unable to access 
address 0x178 from core
(invalid char ptr (0x0178)), __zend_orig_lineno = 0), line 2014 in 
"zend_alloc.c"
_emalloc(size = 273743976, __zend_filename = warning: Unable to access address 
0x185 from core
(invalid char ptr (0x0185)), __zend_lineno = 1, __zend_orig_filename = "", 
__zend_orig_lineno = 273743976), line 2425 in "zend_alloc.c"
_zend_hash_index_update_or_next_insert(ht = (nil), h = 805991784, pData = 
0x2ff20660, nDataSize = 273727512, pDest = 0x100231b4, flag = 805816404, 
__zend_filename = "/\362^G^P0^G\244\324^P^Q^H ", __zend_lineno = 805807316), 
line 412 in "zend_hash.c"
ZEND_ADD_ARRAY_ELEMENT_SPEC_CONST_UNUSED_HANDLER(execute_data = 0x017c), 
line 5633 in "zend_vm_execute.h"
ZEND_INIT_ARRAY_SPEC_CONST_UNUSED_HANDLER(execute_data = (nil)), line 5653 in 
"zend_vm_execute.h"
unnamed block in zend_execute.execute(op_array = 0x2ff21e60), line 409 in 
"zend_vm_execute.h"
zend_execute.execute(op_array = 0x2ff21e60), line 409 in "zend_vm_execute.h"
zend_execute_scripts(type = 8, retval = (nil), file_count = 3, ... = 0x0, 
0x2ff21e60, 0x0, 0x75696c64, 0x5f707265), line 1315 in "zend.c"
unnamed block in php_execute_script(primary_file = 0x2ff21e60), line 2494 in 
"main.c"
unnamed block in php_execute_script(primary_file = 0x2ff21e60), line 2494 in 
"main.c"
php_execute_script(primary_file = 0x2ff21e60), line 2494 in "main.c"
unnamed block in do_cli(argc = 13, argv = 0x2ff22690), line 988 in "php_cli.c"
do_cli(argc = 13, argv = 0x2ff22690), line 988 in "php_cli.c"
unnamed block in php_cli.main(argc = 13, argv = 0x2ff22690), line 1364 in 
"php_cli.c"
php_cli.main(argc = 13, argv = 0x2ff22690), line 1364 in "php_cli.c"







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

Bug #55204 [NoF->Csd]: ICONV iconv_strlen() causing apache to crash/segmentation fault(11)

[michel02 at hotmail dot com]

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

 ID: 55204
 User updated by:michel02 at hotmail dot com
 Reported by:michel02 at hotmail dot com
 Summary:ICONV iconv_strlen() causing apache to
 crash/segmentation fault(11)
-Status: No Feedback
+Status: Closed
 Type:   Bug
 Package:ICONV related
 Operating System:   Solaris 10
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

Damn you seem to be correct! Did not spot that untill now.. resolved!


Previous Comments:

[2013-08-26 09:23:38] skrueger at europe dot com

Ah this is so stupid, I was missing the 
pkg://solaris/system/library/iconv/unicode-core package...

To check if you're missing it too (only works on Solaris 11.1):

$ iconv -l
Failed to open the directory /usr/lib/iconv/geniconvtbl/binarytables/.

When you get that, you need to install the unicode-core pkg and everything 
(including php's iconv_strlen) will be fine after that.


[2013-08-25 22:04:15] skrueger at europe dot com

I see the same error on Solaris 11.1:

root@www:/tmp# /usr/php/5.3/bin/php -v
PHP 5.3.14 (cli) (built: Aug 30 2012 01:52:21)

root@www:/tmp# /usr/php/5.3/bin/php /tmp/iconv_strlen.php 
PHP Notice:  iconv_strlen(): Unknown error (22) in /tmp/iconv_strlen.php on 
line 
5
PHP Stack trace:
PHP   1. {main}() /tmp/iconv_strlen.php:0
PHP   2. iconv_strlen() /tmp/iconv_strlen.php:5

Notice: iconv_strlen(): Unknown error (22) in /tmp/iconv_strlen.php on line 5

Call Stack:
0.0002 315392   1. {main}() /tmp/iconv_strlen.php:0
0.0002 315568   2. iconv_strlen() /tmp/iconv_strlen.php:5


And also on PHP 5.5.3:

root@www:/tmp# /opt/php5/bin/php -v
PHP 5.5.3 (cli) (built: Aug 25 2013 19:41:00) 

root@www:/tmp# /opt/php5/bin/php /tmp/iconv_strlen.php 
PHP Notice:  iconv_strlen(): Unknown error (22) in /tmp/iconv_strlen.php on 
line 
5

Notice: iconv_strlen(): Unknown error (22) in /tmp/iconv_strlen.php on line 5


[2013-02-18 00:34:56] php-bugs at lists dot php dot net

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


[2012-06-21 14:44:52] gabriel dot rota at gmail dot com

this LD_PRELOAD fixed my issue

export LD_PRELOAD=/usr/local/lib/preloadable_libiconv.so


[2011-07-15 17:42:10] fel...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.






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


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

Bug #65392 [Opn->Fbk]: Warning for a success message with ftp_chdir

[felipe]

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

 ID: 65392
 Updated by: fel...@php.net
 Reported by:Laurent dot Lyaudet at gmail dot com
 Summary:Warning for a success message with ftp_chdir
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:FTP related
 Operating System:   Debian Linux
 PHP Version:5.4.17
 Block user comment: N
 Private report: N

 New Comment:

Do you know what ftp server are you trying connect to?


Previous Comments:

[2013-08-05 09:45:47] Laurent dot Lyaudet at gmail dot com

Description:

Hi,

I found the following trace in an error log of a php script I launch as 
background task.

//---
root@wheezyDEVLaurent:~# more /home/web/teliedi/log/logErreur.txt
2013-08-05 : 11:05:11 :  02 | runPersistant.php
   | ftp_chdir(): Requested file action okay, co
mpleted.
2013-08-05 : 11:05:11 : CALLSTACK - DESC (Nb ignores : 1, Nb limite : 0)

--

Appel : ErreurCli(2,"ftp_chdir(): Requested file action okay, completed.","/home
/web/teliedi/appli/includes/classes/CRecipientFtp.php",341,array(true,CServeurFt
p))

Fichier : /home/web/teliedi/appli/includes/classes/CRecipientFtp.php
Ligne : 341
Appel : ftp_chdir(RESOURCE,"TOUR_XML")

//

It is surprising to obtain a warning but the message is "Requested file action 
okay, completed."

The version is latest debian package for wheezy but more ancient than 5.4.17
root@wheezyDEVLaurent:~# php --version
PHP 5.4.4-14+deb7u3 (cli) (built: Jul 17 2013 14:54:08)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans

I have no idea how to reproduce this bug and I don't know if it has been 
already corrected. I think a code analysis of ftp_chdir is needed to find in 
which case one can throw a warning with this message.

Let me know if I can help further.

Best regards,
   Laurent Lyaudet











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

Bug #65601 [Ver->Asn]: SplFileObject->valid() should not return false when it reached EOF

[felipe]

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

 ID: 65601
 Updated by: fel...@php.net
 Reported by:kentaro at ranvis dot com
 Summary:SplFileObject->valid() should not return false when
 it reached EOF
-Status: Verified
+Status: Assigned
 Type:   Bug
 Package:SPL related
 Operating System:   *
 PHP Version:5.5.3
-Assigned To:
+Assigned To:colder
 Block user comment: N
 Private report: N



Previous Comments:

[2013-09-01 11:49:58] requi...@php.net

Related to bug #65600.

The first eof() assertion should be === true as rewind() would have rewound the 
stream and, to maintain normal iteration behavior, read the first line.

Using the READ_AHEAD flag will enable the behavior you're expecting. I don't 
know 
if that requirement is intentional or necessary.


[2013-09-01 10:15:20] kentaro at ranvis dot com

Description:

PHP document says that SplFileObject->valid() checks if a file pointer is not 
at EOF, just like SplFileObject->eof().
But since SplFileObject implements Iterator, valid() should not return false 
while the current element is valid.

Test script:
---
$f = new SplFileObject('php://memory', 'r+');
assert('$f instanceof Iterator');
$f->fwrite("line 1");
$f->rewind();
assert('$f->valid() === true');
assert('$f->eof() === false');
assert('$f->current() === "line 1"');
assert('$f->valid() === true'); // fails
assert('$f->eof() === true');








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

[PHP-BUG] Bug #65633 [NEW]: PHP built-in server

[francesco dot laffi at gmail dot com]

From: francesco dot laffi at gmail dot com
Operating system: 
PHP version:  5.5Git-2013-09-08 (snap)
Package:  Built-in web server
Bug Type: Bug
Bug description:PHP built-in server 

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

[PHP-BUG] Bug #65634 [NEW]: HTTP wrapper is very slow with protocol_version 1.1

[butesa at freenet dot de]

From: butesa at freenet dot de
Operating system: Ubuntu 12.04 x64
PHP version:  5.5.3
Package:  HTTP related
Bug Type: Bug
Bug description:HTTP wrapper is very slow with protocol_version 1.1

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

Bug #65632 [Fbk->Opn]: php ( CLI ) - 5-6 seconds execution time.

[saleh at va dot com dot sa]

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

 ID: 65632
 User updated by:saleh at va dot com dot sa
 Reported by:saleh at va dot com dot sa
 Summary:php ( CLI ) - 5-6 seconds execution time.
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   CentOS X86_64
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

http://vaiasa.com/out.txt

looks like php is trying to include libs that is not there!

note i compiled with -with-libdir=lib64
and all the required libs installed and php did not complie that its not found.


Previous Comments:

[2013-09-08 05:45:57] ras...@php.net

That doesn't sound right. I see no such delay on Centos here. Could you please 
run this:

strace -Ff -tt -T -o out.txt php hello.php

And put out.txt somewhere we can see it? (it's going to be too long to paste 
into 
the bug report)


[2013-09-08 01:41:05] saleh at va dot com dot sa

Description:

there is an execution delay ( 5 seconds ) when running PHP from the command 
line.
however this thing dose not happen on the Apache module.

PHP: 5.5.3 (latest)
OS: CentOS x86_64
Compile command:

Configure Command =>  './configure'  '--with-apxs2' '--with-openssl' '--with-
pcre-regex' '--with-zlib' '--enable-bcmath' '--with-bz2' '--enable-calendar' '--
with-curl' '--enable-exif' '--enable-ftp' '--with-gd' '--with-vpx-dir' '--with-
jpeg-dir' '--with-png-dir' '--with-xpm-dir' '--with-freetype-dir' 
'--with-t1lib' 
'--enable-gd-native-ttf' '--with-gettext' '--with-mhash' '--with-imap' '--with-
kerberos' '--with-imap-ssl' '--enable-intl' '--with-ldap' '--with-ldap-sasl' '--
enable-mbstring' '--with-mcrypt' '--with-mysql' '--with-mysqli' '--with-
unixODBC=/usr' '--enable-pcntl' '--with-pdo-mysql' '--with-libedit' '--with-
readline' '--enable-shmop' '--with-libxml-dir' '--with-snmp' '--enable-soap' '--
enable-sockets' '--with-tidy' '--enable-wddx' '--with-xmlrpc' 
'--with-iconv-dir' 
'--with-xsl' '--enable-zip' '--with-zlib-dir' '--with-pcre-dir' '--with-pear' '-
-with-libdir=lib64' '--enable-opcache=no'


Test script:
---


or just runing `php -v`

Expected result:

less than 1 secound execution time

Actual result:
--
5 seconds execution time






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

Bug #65632 [Com]: php ( CLI ) - 5-6 seconds execution time.

[saleh at va dot com dot sa]

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

 ID: 65632
 Comment by: saleh at va dot com dot sa
 Reported by:saleh at va dot com dot sa
 Summary:php ( CLI ) - 5-6 seconds execution time.
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   CentOS X86_64
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

why is it connecting to my DNS server !

31769 20:37:22.164603 socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3 
<0.30>
31769 20:37:22.164710 connect(3, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("192.168.1.3")}, 16) = 0 <0.30> 
31769 20:37:22.164824 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, 
revents=POLLOUT}]) <0.26>
31769 20:37:22.164925 sendto(3, 
"wh\1\0\0\1\0\0\0\0\0\0\3lan\2va\3com\2sa\0\0\1\0\1", 31, MSG_NOSIGNAL, NULL, 
0) 
= 31 <0.37>
31769 20:37:22.165035 poll([{fd=3, events=POLLIN|POLLOUT}], 1, 5000) = 1 
([{fd=3, revents=POLLOUT}]) <0.24>  
31769 20:37:22.165132 sendto(3, 
"\314\33\1\0\0\1\0\0\0\0\0\0\3lan\2va\3com\2sa\0\0\34\0\1", 31, MSG_NOSIGNAL, 
NULL, 0) = 31 <0.32>
31769 20:37:22.165247 poll([{fd=3, events=POLLIN}], 1, 4999) = 1 ([{fd=3, 
revents=POLLIN}]) <0.000659>
31769 20:37:22.165991 ioctl(3, FIONREAD, [47]) = 0 <0.27>
31769 20:37:22.166092 recvfrom(3, 
"wh\201\0\0\1\0\1\0\0\0\0\3lan\2va\3com\2sa\0\0\1\0\1\300"..., 2048, 0, 
{sa_family=AF_INET, sin_port=htons(53), sin_addr=i$
31769 20:37:22.166271 poll([{fd=3, events=POLLIN}], 1, 4998) = 1 ([{fd=3, 
revents=POLLIN}]) <3.723296>


Previous Comments:

[2013-09-08 17:45:05] saleh at va dot com dot sa

http://vaiasa.com/out.txt

looks like php is trying to include libs that is not there!

note i compiled with -with-libdir=lib64
and all the required libs installed and php did not complie that its not found.


[2013-09-08 05:45:57] ras...@php.net

That doesn't sound right. I see no such delay on Centos here. Could you please 
run this:

strace -Ff -tt -T -o out.txt php hello.php

And put out.txt somewhere we can see it? (it's going to be too long to paste 
into 
the bug report)


[2013-09-08 01:41:05] saleh at va dot com dot sa

Description:

there is an execution delay ( 5 seconds ) when running PHP from the command 
line.
however this thing dose not happen on the Apache module.

PHP: 5.5.3 (latest)
OS: CentOS x86_64
Compile command:

Configure Command =>  './configure'  '--with-apxs2' '--with-openssl' '--with-
pcre-regex' '--with-zlib' '--enable-bcmath' '--with-bz2' '--enable-calendar' '--
with-curl' '--enable-exif' '--enable-ftp' '--with-gd' '--with-vpx-dir' '--with-
jpeg-dir' '--with-png-dir' '--with-xpm-dir' '--with-freetype-dir' 
'--with-t1lib' 
'--enable-gd-native-ttf' '--with-gettext' '--with-mhash' '--with-imap' '--with-
kerberos' '--with-imap-ssl' '--enable-intl' '--with-ldap' '--with-ldap-sasl' '--
enable-mbstring' '--with-mcrypt' '--with-mysql' '--with-mysqli' '--with-
unixODBC=/usr' '--enable-pcntl' '--with-pdo-mysql' '--with-libedit' '--with-
readline' '--enable-shmop' '--with-libxml-dir' '--with-snmp' '--enable-soap' '--
enable-sockets' '--with-tidy' '--enable-wddx' '--with-xmlrpc' 
'--with-iconv-dir' 
'--with-xsl' '--enable-zip' '--with-zlib-dir' '--with-pcre-dir' '--with-pear' '-
-with-libdir=lib64' '--enable-opcache=no'


Test script:
---


or just runing `php -v`

Expected result:

less than 1 secound execution time

Actual result:
--
5 seconds execution time






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

Bug #65632 [Com]: php ( CLI ) - 5-6 seconds execution time.

[saleh at va dot com dot sa]

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

 ID: 65632
 Comment by: saleh at va dot com dot sa
 Reported by:saleh at va dot com dot sa
 Summary:php ( CLI ) - 5-6 seconds execution time.
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   CentOS X86_64
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

problem FIXED by adding:

MyIP MyHostname

to: /etc/hosts

now the cli is working as usual.


Previous Comments:

[2013-09-08 18:32:15] saleh at va dot com dot sa

why is it connecting to my DNS server !

31769 20:37:22.164603 socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3 
<0.30>
31769 20:37:22.164710 connect(3, {sa_family=AF_INET, sin_port=htons(53), 
sin_addr=inet_addr("192.168.1.3")}, 16) = 0 <0.30> 
31769 20:37:22.164824 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, 
revents=POLLOUT}]) <0.26>
31769 20:37:22.164925 sendto(3, 
"wh\1\0\0\1\0\0\0\0\0\0\3lan\2va\3com\2sa\0\0\1\0\1", 31, MSG_NOSIGNAL, NULL, 
0) 
= 31 <0.37>
31769 20:37:22.165035 poll([{fd=3, events=POLLIN|POLLOUT}], 1, 5000) = 1 
([{fd=3, revents=POLLOUT}]) <0.24>  
31769 20:37:22.165132 sendto(3, 
"\314\33\1\0\0\1\0\0\0\0\0\0\3lan\2va\3com\2sa\0\0\34\0\1", 31, MSG_NOSIGNAL, 
NULL, 0) = 31 <0.32>
31769 20:37:22.165247 poll([{fd=3, events=POLLIN}], 1, 4999) = 1 ([{fd=3, 
revents=POLLIN}]) <0.000659>
31769 20:37:22.165991 ioctl(3, FIONREAD, [47]) = 0 <0.27>
31769 20:37:22.166092 recvfrom(3, 
"wh\201\0\0\1\0\1\0\0\0\0\3lan\2va\3com\2sa\0\0\1\0\1\300"..., 2048, 0, 
{sa_family=AF_INET, sin_port=htons(53), sin_addr=i$
31769 20:37:22.166271 poll([{fd=3, events=POLLIN}], 1, 4998) = 1 ([{fd=3, 
revents=POLLIN}]) <3.723296>


[2013-09-08 17:45:05] saleh at va dot com dot sa

http://vaiasa.com/out.txt

looks like php is trying to include libs that is not there!

note i compiled with -with-libdir=lib64
and all the required libs installed and php did not complie that its not found.


[2013-09-08 05:45:57] ras...@php.net

That doesn't sound right. I see no such delay on Centos here. Could you please 
run this:

strace -Ff -tt -T -o out.txt php hello.php

And put out.txt somewhere we can see it? (it's going to be too long to paste 
into 
the bug report)


[2013-09-08 01:41:05] saleh at va dot com dot sa

Description:

there is an execution delay ( 5 seconds ) when running PHP from the command 
line.
however this thing dose not happen on the Apache module.

PHP: 5.5.3 (latest)
OS: CentOS x86_64
Compile command:

Configure Command =>  './configure'  '--with-apxs2' '--with-openssl' '--with-
pcre-regex' '--with-zlib' '--enable-bcmath' '--with-bz2' '--enable-calendar' '--
with-curl' '--enable-exif' '--enable-ftp' '--with-gd' '--with-vpx-dir' '--with-
jpeg-dir' '--with-png-dir' '--with-xpm-dir' '--with-freetype-dir' 
'--with-t1lib' 
'--enable-gd-native-ttf' '--with-gettext' '--with-mhash' '--with-imap' '--with-
kerberos' '--with-imap-ssl' '--enable-intl' '--with-ldap' '--with-ldap-sasl' '--
enable-mbstring' '--with-mcrypt' '--with-mysql' '--with-mysqli' '--with-
unixODBC=/usr' '--enable-pcntl' '--with-pdo-mysql' '--with-libedit' '--with-
readline' '--enable-shmop' '--with-libxml-dir' '--with-snmp' '--enable-soap' '--
enable-sockets' '--with-tidy' '--enable-wddx' '--with-xmlrpc' 
'--with-iconv-dir' 
'--with-xsl' '--enable-zip' '--with-zlib-dir' '--with-pcre-dir' '--with-pear' '-
-with-libdir=lib64' '--enable-opcache=no'


Test script:
---


or just runing `php -v`

Expected result:

less than 1 secound execution time

Actual result:
--
5 seconds execution time






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

[PHP-BUG] Bug #65635 [NEW]: cannot dereference array

[TorrAB at Yahoo dot com]

From: TorrAB at Yahoo dot com
Operating system: Windows XP
PHP version:  5.5.3
Package:  Compile Failure
Bug Type: Bug
Bug description:cannot dereference array

Description:

Parse error: syntax error, unexpected "(T_ENCAPSED_AND_WHITESPACE),
expecting identifier (T_STRING) or variable (T_VARIABLE) or number
(T_NUM_STRING).
Apparently, the parser cannot dereference $Apt['Color']. May be linked to
bug 23022. But why the ?

Test script:
---
 $Apt){
$Colo=$Apt['Color'];
echo "";
echo '';}

#Parse error: syntax error, unexpected '' (T_ENCAPSED_AND_WHITESPACE),
expecting identifier (T_STRING) or variable (T_VARIABLE) or number
(T_NUM_STRING) in C:\Apache24\htdocs\GoodBadB.php on line 10:
forEach ($GLOBALS['Aps'] as $GLOBALS['X'] => $Apt){
echo "";
#Apparently, the parser cannot dereference $Apt['Color']. May be linked to
bug 23022. But why the ?
echo '';}
?>


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

Bug #65635 [Com]: cannot dereference array

[cmbecker69 at gmx dot de]

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

 ID: 65635
 Comment by: cmbecker69 at gmx dot de
 Reported by:TorrAB at Yahoo dot com
 Summary:cannot dereference array
 Status: Open
 Type:   Bug
 Package:Compile Failure
 Operating System:   Windows XP
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

> Apparently, the parser cannot dereference $Apt['Color'].

No.  The parser won't just accept this syntax.  See the manual[1]
on how to use array indexes in strings.

IMHO, this is not a bug.

[1]  



Previous Comments:

[2013-09-08 18:57:46] TorrAB at Yahoo dot com

Description:

Parse error: syntax error, unexpected "(T_ENCAPSED_AND_WHITESPACE), expecting 
identifier (T_STRING) or variable (T_VARIABLE) or number (T_NUM_STRING).
Apparently, the parser cannot dereference $Apt['Color']. May be linked to bug 
23022. But why the ?

Test script:
---
 $Apt){
$Colo=$Apt['Color'];
echo "";
echo '';}

#Parse error: syntax error, unexpected '' (T_ENCAPSED_AND_WHITESPACE), 
expecting identifier (T_STRING) or variable (T_VARIABLE) or number 
(T_NUM_STRING) in C:\Apache24\htdocs\GoodBadB.php on line 10:
forEach ($GLOBALS['Aps'] as $GLOBALS['X'] => $Apt){
echo "";
#Apparently, the parser cannot dereference $Apt['Color']. May be linked to bug 
23022. But why the ?
echo '';}
?>







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

Bug #65630 [Com]: filter_var() return false with german umlauts

[cmbecker69 at gmx dot de]

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

 ID: 65630
 Comment by: cmbecker69 at gmx dot de
 Reported by:marvin-wegener at outlook dot com
 Summary:filter_var() return false with german umlauts
 Status: Open
 Type:   Bug
 Package:Filter related
 Operating System:   Windows/Linux
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

Unfortunately, the manual[1] is not explicit about that issue, 
but I assume that FILTER_VALIDATE_EMAIL validates according to
RFC 5322, which does not cater for IDNs.  If so, this might be
regarded as "documentation problem".

This bug report is related to request #65385[2].

[1] 
[2] 


Previous Comments:

[2013-09-07 16:16:08] marvin-wegener at outlook dot com

Description:

Hello,

If I use the following script, the filter_var return always false, but the 
Domain is possible.

It is possible to fix it, that Domains with ÜÖÄ are exepted?

Thanks you in advance!

Test script:
---








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

Bug #65635 [Opn->Nab]: cannot dereference array

[nikic]

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

 ID: 65635
 Updated by: ni...@php.net
 Reported by:TorrAB at Yahoo dot com
 Summary:cannot dereference array
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Compile Failure
 Operating System:   Windows XP
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

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

Thank you for your interest in PHP.

Correct, this is not a bug. In string interpolation use either "... $array[key] 
..." or "... {$array['key']} ...".


Previous Comments:

[2013-09-08 21:31:40] cmbecker69 at gmx dot de

> Apparently, the parser cannot dereference $Apt['Color'].

No.  The parser won't just accept this syntax.  See the manual[1]
on how to use array indexes in strings.

IMHO, this is not a bug.

[1]  



[2013-09-08 18:57:46] TorrAB at Yahoo dot com

Description:

Parse error: syntax error, unexpected "(T_ENCAPSED_AND_WHITESPACE), expecting 
identifier (T_STRING) or variable (T_VARIABLE) or number (T_NUM_STRING).
Apparently, the parser cannot dereference $Apt['Color']. May be linked to bug 
23022. But why the ?

Test script:
---
 $Apt){
$Colo=$Apt['Color'];
echo "";
echo '';}

#Parse error: syntax error, unexpected '' (T_ENCAPSED_AND_WHITESPACE), 
expecting identifier (T_STRING) or variable (T_VARIABLE) or number 
(T_NUM_STRING) in C:\Apache24\htdocs\GoodBadB.php on line 10:
forEach ($GLOBALS['Aps'] as $GLOBALS['X'] => $Apt){
echo "";
#Apparently, the parser cannot dereference $Apt['Color']. May be linked to bug 
23022. But why the ?
echo '';}
?>







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

[PHP-BUG] Bug #65636 [NEW]: Stream path cannot contail null char (chr(0))

[bilge at scriptfusion dot com]

From: bilge at scriptfusion dot com
Operating system: Linux
PHP version:  5.5.3
Package:  Streams related
Bug Type: Bug
Bug description:Stream path cannot contail null char (chr(0))

Description:

Stream path can contain any character, whether URL encoded or not, except
for the null character. Including a null character in the path raises the
following error:

file_get_contents() expects parameter 1 to be a valid path, string given

Both the use case and test suite to support the claims above can be found
at
https://github.com/Bilge/VerbatimStream/tree/eb185806f9bea3ee65b7d0f3e42dcd27a7b40614

The use case is a custom stream wrapper that takes the path and converts it
into a read-only data stream. The current workaround is to urlencode any
path that contains nulls. However, this approach provides little benefit
over the data wrapper. Being able to include nulls directly in the path
would eliminate unnecessary url encoding and decoding in the custom wrapper
implementation.


Test script:
---
file_get_contents("\000");

//or

file_get_contents("verbatim://\000");

Expected result:

No error.

Actual result:
--
file_get_contents() expects parameter 1 to be a valid path, string given

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

[PHP-BUG] Bug #65637 [NEW]: Using division PHP_ROUND_HALF_UP rounds DOWN when working with 2 precision

[productivepc at hotmail dot com]

From: productivepc at hotmail dot com
Operating system: Windows 7
PHP version:  5.5.3
Package:  Math related
Bug Type: Bug
Bug description:Using division PHP_ROUND_HALF_UP rounds DOWN when working with 
2 precision

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 excel then it too brings the price to 182.08 which is what makes me

believe that the PHP function PHP_ROUND_HALF_UP is actually ROUNDING DOWN 
instead of UP.  The 
expected behavior for both excel and PHP would be to leave the price at
182.13.  
When I use 3 decimals for both then both PHP and Excel agree that the 
totalProratedPrice is 182.13.  I am not sure if this is a bug however I
wanted 
to report it here before making a comment on the ROUND page with an example
of 
this.

The example below I do not have settype() in it however I have attempted
this by 
changing everything over to a float with settype before I did any math and
the 
result was still the same.

Wayne

Test script:
---
$workingDaysLeft = 16;
$totalWorkingDays = 21;
$mainPcCost = 169;
$additionalPcCost = 3.3328571428571;
$mainPcCostPerDay = round($mainPcCost/$totalWorkingDays,2,
PHP_ROUND_HALF_UP);
$additionalPcCost = $additionalPcCost/$totalWorkingDays;

// The next line is the problem area.  When I change it to 2 precision the
expected behavior is for the total prorated cost to stay at 182.13 however
it drops to 182.08.  If you change the below line to PHP_ROUND_HALF_DOWN
then you also get 182.08 which would indicate that the behavior is not
behaving as expected.
$additionalPcCostPerDay = round($additionalPcCost,3,PHP_ROUND_HALF_UP);

$mainPcProratedCost =
round($mainPcCostPerDay*$workingDaysLeft,2,PHP_ROUND_HALF_UP);
$additionalPcProratedCost =
round($additionalPcCostPerDay*$workingDaysLeft,2,PHP_ROUND_HALF_UP);
$totalProratedCost =
number_format($mainPcProratedCost+$additionalPcProratedCost,2,'.',',');
echo "mainPcCost: " . $mainPcCost . "additionalPcCost: " .
$additionalPcCost;
echo "WorkingDaysLeft: " . $workingDaysLeft . "totalWorkingDays: "
. $totalWorkingDays;
echo "mainPcCostPerDay: " . $mainPcCostPerDay .
"additionalPcCostPerDay: " . $additionalPcCostPerDay;
echo "mainPcProratedCost: " . $mainPcProratedCost .
"additionalPcProratedCost: " . $additionalPcProratedCost;
echo "totalProratedCost: " . $totalProratedCost;

Expected result:

Whether I have precision for $additionalPcCostPerDay set to 2 or 3 the 
totalProratedCost should remain the 182.13 and not change to 182.08.


-- 
Edit bug report at https://bugs.php.net/bug.php?id=65637&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=65637&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=65637&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=65637&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=65637&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=65637&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65637&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=65637&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=65637&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65637&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=65637&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65637&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65637&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=65637&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65637&r=php4
Daylight Savings: 

Req #51595 [Com]: passing ini settings via FASTCGI parameters

[moswh07 at gmail dot com]

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

 ID: 51595
 Comment by: moswh07 at gmail dot com
 Reported by:f...@php.net
 Summary:passing ini settings via FASTCGI parameters
 Status: Closed
 Type:   Feature/Change Request
 Package:FPM related
 Operating System:   any
 PHP Version:trunk
 Assigned To:fat
 Block user comment: N
 Private report: N

 New Comment:

I've been got the same problem, which I get 
$_SERVER["PHP_VALUE"] = '...'
 in php.ini when I use 
fastcgi_param PHP_ADMIN_VALUE ...
in nginx config.

I find the solution that spawn-cgi may not support this feature.
the newest updated of spawn is 1.6.3 which was published in 2009-09-23.
but we can see from this page that the feature was added in 2010-04-19 and only 
supported in php-fpm.


Previous Comments:

[2013-07-23 17:57:37] ben at indietorrent dot org

I, too, have noticed that PHP configuration directives that are defined like 
this, within an nginx "location{}" block

fastcgi_param PHP_VALUE "
error_reporting=6143
log_errors=On
";

are not effective. The values are propagated to the effective environment 
variables, though, as evidenced by the fact that the values appear in the 
$_SERVER["PHP_VALUE"] superglobal.

Will this ever work? Or is it simply not possible to achieve this with PHP's 
CGI 
executable (instead of, for example, php-fpm)?


[2011-10-24 14:06:56] info at breakdev dot com

it doesn't work with nginx anf php5-cgi spawn:

nginx version: nginx/0.7.67
PHP 5.3.8-1~dotdeb.1 with Suhosin-Patch (cli) (built: Aug 26 2011 12:46:54) 

I used this line in the nginx.conf:
fastcgi_param PHP_ADMIN_VALUE open_basedir=/home/www/docs

so there was set
$_SERVER['PHP_ADMIN_VALUE']="open_basedir=/home/www/docs"


[2011-08-21 18:06:17] f...@php.net

Yes it's been integrated into FPM since 5.3.3 I think. In all the cases, it 
works 
with php 5.3.7


[2011-08-21 17:40:43] ywarnier at beeznest dot org

Hi guys, has this been sent to any stable release of PHP? I can't find it in 
any part of http://www.php.net/ChangeLog-5.php#5.3.7


[2010-04-23 19:15:58] f...@php.net

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/.
 
Thank you for the report, and for helping us make PHP better.

It's been commited in revision 298383

In fastcgi headers, only unique values can be passed. So you have to 
concatenate 
differentes value in one and 
separate them with a new line character (\n).

For exemple in nginx, it could be done this way:

  set $php_value "pcre.backtrack_limit=424242";
  set $php_value "$php_value \n pcre.recursion_limit=9";
  fastcgi_param  PHP_VALUE $php_value;

  fastcgi_param  PHP_ADMIN_VALUE "open_basedir=/var/www/htdocs";


In lighttpd, it seems there is no options to pass custom headers :/




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


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

Bug #65637 [Opn->Fbk]: 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: Open
+Status: Feedback
 Type:   Bug
 Package:Math related
 Operating System:   Windows 7
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

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?


Previous Comments:

[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 excel then it too brings the price to 182.08 which is what makes me 
believe that the PHP function PHP_ROUND_HALF_UP is actually ROUNDING DOWN 
instead of UP.  The 
expected behavior for both excel and PHP would be to leave the price at 182.13. 
 
When I use 3 decimals for both then both PHP and Excel agree that the 
totalProratedPrice is 182.13.  I am not sure if this is a bug however I wanted 
to report it here before making a comment on the ROUND page with an example of 
this.

The example below I do not have settype() in it however I have attempted this 
by 
changing everything over to a float with settype before I did any math and the 
result was still the same.

Wayne

Test script:
---
$workingDaysLeft = 16;
$totalWorkingDays = 21;
$mainPcCost = 169;
$additionalPcCost = 3.3328571428571;
$mainPcCostPerDay = round($mainPcCost/$totalWorkingDays,2, PHP_ROUND_HALF_UP);
$additionalPcCost = $additionalPcCost/$totalWorkingDays;

// The next line is the problem area.  When I change it to 2 precision the 
expected behavior is for the total prorated cost to stay at 182.13 however it 
drops to 182.08.  If you change the below line to PHP_ROUND_HALF_DOWN then you 
also get 182.08 which would indicate that the behavior is not behaving as 
expected.
$additionalPcCostPerDay = round($additionalPcCost,3,PHP_ROUND_HALF_UP);

$mainPcProratedCost = 
round($mainPcCostPerDay*$workingDaysLeft,2,PHP_ROUND_HALF_UP);
$additionalPcProratedCost = 
round($additionalPcCostPerDay*$workingDaysLeft,2,PHP_ROUND_HALF_UP);
$totalProratedCost = 
number_format($mainPcProratedCost+$additionalPcProratedCost,2,'.',',');
echo "mainPcCost: " . $mainPcCost . "additionalPcCost: " . 
$additionalPcCost;
echo "WorkingDaysLeft: " . $workingDaysLeft . "totalWorkingDays: " . 
$totalWorkingDays;
echo "mainPcCostPerDay: " . $mainPcCostPerDay . 
"additionalPcCostPerDay: " . $additionalPcCostPerDay;
echo "mainPcProratedCost: " . $mainPcProratedCost . 
"additionalPcProratedCost: " . $additionalPcProratedCost;
echo "totalProratedCost: " . $totalProratedCost;

Expected result:

Whether I have precision for $additionalPcCostPerDay set to 2 or 3 the 
totalProratedCost should remain the 182.13 and not change to 182.08.







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

Bug #65637 [Fbk]: 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
 Type:   Bug
 Package:Math related
 Operating System:   Windows 7
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

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.


Previous Comments:

[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 excel then it too brings the price to 182.08 which is what makes me 
believe that the PHP function PHP_ROUND_HALF_UP is actually ROUNDING DOWN 
instead of UP.  The 
expected behavior for both excel and PHP would be to leave the price at 182.13. 
 
When I use 3 decimals for both then both PHP and Excel agree that the 
totalProratedPrice is 182.13.  I am not sure if this is a bug however I wanted 
to report it here before making a comment on the ROUND page with an example of 
this.

The example below I do not have settype() in it however I have attempted this 
by 
changing everything over to a float with settype before I did any math and the 
result was still the same.

Wayne

Test script:
---
$workingDaysLeft = 16;
$totalWorkingDays = 21;
$mainPcCost = 169;
$additionalPcCost = 3.3328571428571;
$mainPcCostPerDay = round($mainPcCost/$totalWorkingDays,2, PHP_ROUND_HALF_UP);
$additionalPcCost = $additionalPcCost/$totalWorkingDays;

// The next line is the problem area.  When I change it to 2 precision the 
expected behavior is for the total prorated cost to stay at 182.13 however it 
drops to 182.08.  If you change the below line to PHP_ROUND_HALF_DOWN then you 
also get 182.08 which would indicate that the behavior is not behaving as 
expected.
$additionalPcCostPerDay = round($additionalPcCost,3,PHP_ROUND_HALF_UP);

$mainPcProratedCost = 
round($mainPcCostPerDay*$workingDaysLeft,2,PHP_ROUND_HALF_UP);
$additionalPcProratedCost = 
round($additionalPcCostPerDay*$workingDaysLeft,2,PHP_ROUND_HALF_UP);
$totalProratedCost = 
number_format($mainPcProratedCost+$additionalPcProratedCost,2,'.',',');
echo "mainPcCost: " . $mainPcCost . "additionalPcCost: " . 
$additionalPcCost;
echo "WorkingDaysLeft: " . $workingDaysLeft . "totalWorkingDays: " . 
$totalWorkingDays;
echo "mainPcCostPerDay: " . $mainPcCostPerDay . 
"additionalPcCostPerDay: " . $additionalPcCostPerDay;
echo "mainPcProratedCost: " . $mainPcProratedCost . 
"additionalPcProratedCost: " . $additionalPcProratedCost;
echo "totalProratedCost: " . $totalProratedCost;

Expected result:

Whether I have precision for $additionalPcCostPerDay set to 2 or 3 the 
totalProratedCost should remain the 182.13 and not change to 182.08.







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

Bug #65630 [Opn->Nab]: filter_var() return false with german umlauts

[pajoye]

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

 ID: 65630
 Updated by: paj...@php.net
 Reported by:marvin-wegener at outlook dot com
 Summary:filter_var() return false with german umlauts
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Filter related
 Operating System:   Windows/Linux
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

You have to use http://php.net/manual/en/function.idn-to-ascii.php


Previous Comments:

[2013-09-08 21:42:03] cmbecker69 at gmx dot de

Unfortunately, the manual[1] is not explicit about that issue, 
but I assume that FILTER_VALIDATE_EMAIL validates according to
RFC 5322, which does not cater for IDNs.  If so, this might be
regarded as "documentation problem".

This bug report is related to request #65385[2].

[1] 
[2] 


[2013-09-07 16:16:08] marvin-wegener at outlook dot com

Description:

Hello,

If I use the following script, the filter_var return always false, but the 
Domain is possible.

It is possible to fix it, that Domains with ÜÖÄ are exepted?

Thanks you in advance!

Test script:
---








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

Bug #65637 [Com]: 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
 Comment 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: Feedback
 Type:   Bug
 Package:Math related
 Operating System:   Windows 7
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

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.


Previous Comments:

[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 excel then it too brings the price to 182.08 which is what makes me 
believe that the PHP function PHP_ROUND_HALF_UP is actually ROUNDING DOWN 
instead of UP.  The 
expected behavior for both excel and PHP would be to leave the price at 182.13. 
 
When I use 3 decimals for both then both PHP and Excel agree that the 
totalProratedPrice is 182.13.  I am not sure if this is a bug however I wanted 
to report it here before making a comment on the ROUND page with an example of 
this.

The example below I do not have settype() in it however I have attempted this 
by 
changing everything over to a float with settype before I did any math and the 
result was still the same.

Wayne

Test script:
---
$workingDaysLeft = 16;
$totalWorkingDays = 21;
$mainPcCost = 169;
$additionalPcCost = 3.3328571428571;
$mainPcCostPerDay = round($mainPcCost/$totalWorkingDays,2, PHP_ROUND_HALF_UP);
$additionalPcCost = $additionalPcCost/$totalWorkingDays;

// The next line is the problem area.  When I change it to 2 precision the 
expected behavior is for the total prorated cost to stay at 182.13 however it 
drops to 182.08.  If you change the below line to PHP_ROUND_HALF_DOWN then you 
also get 182.08 which would indicate that the behavior is not behaving as 
expected.
$additionalPcCostPerDay = round($additionalPcCost,3,PHP_ROUND_HALF_UP);

$mainPcProratedCost = 
round($mainPcCostPerDay*$workingDaysLeft,2,PHP_ROUND_HALF_UP);
$additionalPcProratedCost = 
round($additionalPcCostPerDay*$workingDaysLeft,2,PHP_ROUND_HALF_UP);
$totalProratedCost = 
number_format($mainPcProratedCost+$additionalPcProratedCost,2,'.',',');
echo "mainPcCost: " . $mainPcCost . "additionalPcCost: " . 
$additionalPcCost;
echo "WorkingDaysLeft: " . $workingDaysLeft . "totalWorkin

Bug #65637 [Com]: 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
 Comment 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: Feedback
 Type:   Bug
 Package:Math related
 Operating System:   Windows 7
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

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;
?>


Previous Comments:

[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 excel then it too brings the price to 182.08 which is what makes me 
believe that the PHP function PHP_ROUND_HALF_UP is actually ROUNDING DOWN 
instead of UP.  The 
expected behavior for both excel and PHP would be to leave the price at 182.13. 
 
When I use 3 decimals for both then both PHP and Excel agree that the 
totalProratedPrice is 182.13.  I am not sure if this is a bug however I wanted 
to report it here before making a comment on the ROUND page with an example of 
this.

The example below I do not have settype() in it however I have attempted this 
by 
changing everything over to a float with settype before I did