Bug #60756 [Opn]: Unable to upgrade
Edit report at https://bugs.php.net/bug.php?id=60756edit=1 ID: 60756 User updated by:lucien_sabre at yahoo dot it Reported by:lucien_sabre at yahoo dot it Summary:Unable to upgrade Status: Open Type: Bug Package:*General Issues Operating System: Windows7 32Bit PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Microsoft Installers don't have the right-click --- Run as Administrator option, it just says INSTALL. And I have no idea of what is windows UAC Previous Comments: [2012-01-25 17:41:18] carloschilazo at gmail dot com Try installing as an administrator (right click the installer, run as administrator) or disable windows UAC [2012-01-18 07:53:41] lucien_sabre at yahoo dot it So, what do I do? [2012-01-17 19:59:46] anon at anon dot anon It's not moronic to be a beginner, it's moronic to not just try it and learn by experimentation. [2012-01-16 15:29:13] lucien_sabre at yahoo dot it Once I back up the original files, what do I do? I'm a complete beginner ***moron*** in these cases [2012-01-16 14:53:38] anon at anon dot anon So back up the install folder first then. But I doubt it can be too strangely laid out because I've never had a problem just running copies of PHP arbitrarily from extracted zips. 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=60756 -- Edit this bug report at https://bugs.php.net/bug.php?id=60756edit=1
Bug #47584 [Com]: WSDL error in soapClient causes Fatal Error
Edit report at https://bugs.php.net/bug.php?id=47584edit=1
ID: 47584
Comment by: zpon dot dk at gmail dot com
Reported by:gem at rellim dot com
Summary:WSDL error in soapClient causes Fatal Error
Status: Bogus
Type: Bug
Package:SOAP related
Operating System: Linux
PHP Version:5.2.9
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
I had to surround my SoapClient call with xdebug_disable(); and
xdebug_enable();
(@ was not enough) to work around this problem.
Previous Comments:
[2010-09-02 21:10:09] gem at rellim dot com
I was a confirmed bug in earlier versions. So it should be 'Fixed' not Bogus'.
[2010-09-02 19:37:13] ras...@php.net
Right, so this is not a PHP bug. Perhaps a feature request to downgrade that
particular error to a Warning instead of a catchable fatal, but that is all I
see.
[2010-09-02 19:34:19] gem at rellim dot com
I do see it catchable now without XDebug.
# php tmp.php
SOAP-ERROR: Parsing WSDL: Couldn't load from 'non-existent.wsdl' : failed to
load
external entity non-existent.wsdl
ok
#
[2010-09-02 19:33:05] gem at rellim dot com
Not catchable for me with XDebug and your example:
# cat tmp.php
?php
try {
$x = @new SoapClient(non-existent.wsdl,array(exceptions = 1));
} catch (SoapFault $E) {
echo $E-faultstring;
}
echo ok\n;
?
# php tmp.php
#
[2010-09-02 19:22:02] ras...@php.net
It is a catchable fatal though.
eg.
?php
try {
$x = @new SoapClient(non-existent.wsdl,array(exceptions = 1));
} catch (SoapFault $E) {
echo $E-faultstring;
}
echo ok\n;
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=47584
--
Edit this bug report at https://bugs.php.net/bug.php?id=47584edit=1
Bug #60756 [Opn-Bgs]: Unable to upgrade
Edit report at https://bugs.php.net/bug.php?id=60756edit=1 ID: 60756 Updated by: paj...@php.net Reported by:lucien_sabre at yahoo dot it Summary:Unable to upgrade -Status: Open +Status: Bogus Type: Bug Package:*General Issues Operating System: Windows7 32Bit PHP Version:Irrelevant Block user comment: N Private report: N New Comment: This is not a support channel. Please use the php-install or the php-windows mailing list to ask further support. Previous Comments: [2012-01-26 08:00:55] lucien_sabre at yahoo dot it Microsoft Installers don't have the right-click --- Run as Administrator option, it just says INSTALL. And I have no idea of what is windows UAC [2012-01-25 17:41:18] carloschilazo at gmail dot com Try installing as an administrator (right click the installer, run as administrator) or disable windows UAC [2012-01-18 07:53:41] lucien_sabre at yahoo dot it So, what do I do? [2012-01-17 19:59:46] anon at anon dot anon It's not moronic to be a beginner, it's moronic to not just try it and learn by experimentation. [2012-01-16 15:29:13] lucien_sabre at yahoo dot it Once I back up the original files, what do I do? I'm a complete beginner ***moron*** in these cases 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=60756 -- Edit this bug report at https://bugs.php.net/bug.php?id=60756edit=1
Bug #60884 [Bgs]: htmlentities() behaves differently and thus breaks existing code
Edit report at https://bugs.php.net/bug.php?id=60884edit=1 ID: 60884 User updated by:t dot nickl at exse dot de Reported by:t dot nickl at exse dot de Summary:htmlentities() behaves differently and thus breaks existing code Status: Bogus Type: Bug Package:*General Issues Operating System: CentOS 4.4 PHP Version:5.4.0RC6 Block user comment: N Private report: N New Comment: @johan...@php.net: Setting default_charset to latin1 does not work. Empty string is still outputted when calling htmlentities with only one argument. Your copypaste preamble does not help, changing the meaning of the written code is a bug, don't worry. @ras...@php.net: Thank you, I sadly will change every htmlentities($a) to htmlentities($a,NULL,'') before deploying php5.4. Previous Comments: [2012-01-25 22:52:52] ras...@php.net I know it hurts, but we really need to move away from ISO-8859-1 and towards UTF-8 as the default charset of the Web. We have chosen to take the hit in 5.4. The documentation has carried a warning about this impending change for quite a while urging people to specify a charset. For PHP 5.4 compatibility Typo3 should either hardcode iso-8859-1 or they should change their calls to: htmlentities($a,NULL,'') to pick up the default script-encoding charset. [2012-01-25 18:01:23] johan...@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 In PHP 5.4 the default_charset php.ini option was set to utf-8. You can override this in php.ini or .htaccess or such. [2012-01-25 15:29:09] t dot nickl at exse dot de Description: //This code must be run via web: //This is a string from e.g. some database containing a german umlaut 'ä'. Note the encoding really is iso8859-1 . It's just assigned here literally to be concise. $a = Rechnungsadresse ändern; //this output works: (An empty string activates some autodetection) var_dump(htmlentities($a, ENT_COMPAT | ENT_HTML401, '')); //this works too (the same output is generated): var_dump(htmlentities($a, ENT_COMPAT | ENT_HTML401, 'ISO-8859-1')); //this does NOT work (outputs empty string) var_dump(htmlentities($a)); // Reason: php changed the charset htmlentities uses when you NOT give anything (90% of the code out there): //determine_charset() : /// // php-5.2.1/ext/standard/html.c : ///* Guarantee default behaviour for backwards compatibility */ //if (charset_hint == NULL) //return cs_8859_1; / // php-5.4.0RC4/ext/standard/html.c : // /* Default is now UTF-8 */ // if (charset_hint == NULL) //return cs_utf_8; // This breaks the meaning of existing german code. For example, typo3 outputs empty string if end users used german umlauts in rich text editor in backend. // Please change determine_charset() back to using cs_8859_1 if the third parameter of htmlentities() is omitted. Test script: --- See description. Expected result: See description. Actual result: -- See description. -- Edit this bug report at https://bugs.php.net/bug.php?id=60884edit=1
Bug #60149 [Com]: SPL autoloader not called in error handler triggered by private __call
Edit report at https://bugs.php.net/bug.php?id=60149edit=1
ID: 60149
Comment by: phil at propcom dot co dot uk
Reported by:gedrox at gmail dot com
Summary:SPL autoloader not called in error handler triggered
by private __call
Status: Open
Type: Bug
Package:SPL related
Operating System: Ubuntu 11.10
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
This is similar to https://bugs.php.net/bug.php?id=54054. The two may be
related.
Previous Comments:
[2011-10-27 15:18:57] gedrox at gmail dot com
Description:
No SPL registered autoloader is called inside custom error handler if it has
been
triggered by private __call() magic function what should be public instead.
Test script:
---
http://gedrox.eu/php_spl_autoloader_error_handler_private_call.tar
Run run.php file.
Expected result:
Tried to load class 'DoesNotExist_1'
Caught error 'The magic method __call() must have public visibility and cannot
be
static'
Tried to load class 'DoesNotExist_2'
Done
Actual result:
--
Tried to load class 'DoesNotExist_1'
Caught error 'The magic method __call() must have public visibility and cannot
be static'
Fatal error: Uncaught exception 'RuntimeException' with message 'Assertion
failed on line '66' in LoaderTest.php on line 45
RuntimeException: Assertion failed on line '66'
in LoaderTest.php on line 45
Call Stack:
0.0001 635080 1. {main}() run.php:0
0.0003 665536 2. LoaderTest-testFailure() run.php:6
0.0004 670584 3. assert() LoaderTest.php:66
0.0004 671144 4. LoaderTest-assertionFail() LoaderTest.php:0
--
Edit this bug report at https://bugs.php.net/bug.php?id=60149edit=1
Bug #60765 [Asn-Bgs]: mysqli_real_escape_string not parse multibyte word safe while use mysqlnd
Edit report at https://bugs.php.net/bug.php?id=60765edit=1 ID: 60765 Updated by: johan...@php.net Reported by:xiaqii at gmail dot com Summary:mysqli_real_escape_string not parse multibyte word safe while use mysqlnd -Status: Assigned +Status: Bogus Type: Bug Package:MySQLi related Operating System: ubuntu 10 PHP Version:5.3.9 Assigned To:uw 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 You have to call mysqli_set_charset() to set the correct encoding so PHP and the MySQL server know hat data to expect and how to interpret it. Previous Comments: [2012-01-26 02:48:46] xiaqii at gmail dot com my site's charset is GBK [2012-01-16 06:19:58] xiaqii at gmail dot com i recomplie my php with old style --with-mysqli=/usr/local/mysql/bin/mysql_config' the sql is safe and execute ok. so the bug is : mysqlnd not parse some multibyte word. this can be sql injection problem. i hope my english is enough to explain this bug clearly.. -_-! [2012-01-16 05:50:24] xiaqii at gmail dot com Description: some Multibyte word contain \ ASCII code didn't been escaped. Test script: --- $link=mysqli_connect(); $var=æµ·è³; $var=mysqli_real_escape_string($link,$var); mysqli_query($link,INSERT INTO table SET manga_name='$var'); /// Expected result: sql injection Actual result: -- it is dangerous. my reply table has been update to all one word because this.. -- Edit this bug report at https://bugs.php.net/bug.php?id=60765edit=1
Req #60872 [Opn-Wfx]: server-side comment tag
Edit report at https://bugs.php.net/bug.php?id=60872edit=1 ID: 60872 Updated by: johan...@php.net Reported by:mantoxpub at people dot it Summary:server-side comment tag -Status: Open +Status: Wont fix Type: Feature/Change Request Package:Scripting Engine problem Operating System: Linux PHP Version:Irrelevant Block user comment: N Private report: N New Comment: As said you can duse // or /* */ comments. Extending the grammar by this forces people to learn more things without much benefit. Previous Comments: [2012-01-26 03:57:45] carloschilazo at gmail dot com Why not use /* comment */ or // comment ? [2012-01-24 19:16:02] mantoxpub at people dot it Description: --- From manual page: http://www.php.net/language.basic-syntax.comments --- what about supporting server-side comment tag? Test script: --- %-- this is a server-side comment. --% Expected result: (nothing :) Actual result: -- %-- this is a server-side comment. --% -- Edit this bug report at https://bugs.php.net/bug.php?id=60872edit=1
Bug #60879 [Opn-Fbk]: unserialize() Does not invoke __wakeup() on object
Edit report at https://bugs.php.net/bug.php?id=60879edit=1
ID: 60879
Updated by: johan...@php.net
Reported by:thijsputman at gmail dot com
Summary:unserialize() Does not invoke __wakeup() on object
-Status: Open
+Status: Feedback
Type: Bug
Package:Class/Object related
Operating System: Windows 7
PHP Version:5.4.0RC6
Block user comment: N
Private report: N
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.4-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Works for me with latest svn. Do you have any special extension loaded or some
special configuration?
Previous Comments:
[2012-01-25 13:24:57] thijsputman at gmail dot com
Description:
When serializing/unserializing an object that contains both a __sleep() and
__wakeup() method, serialize() invokes the __sleep() method, but unserialize()
does *not* invoke the __wakeup() method.
Using PHP 5.4.0RC6 (x86 NTS) on Windows 7, previously used 5.4.0RC5 which did
not exhibit this problem. See the below test script for an example (which works
as expected in RC5, but not in RC6).
Test script:
---
class Woei{
public function __sleep(){
echo 'sleep' . PHP_EOL;
return array();
}
public function __wakeup(){
echo 'wakeup' . PHP_EOL;
}
}
$Woei = new Woei();
$s1 = serialize($Woei);
$Woei2 = unserialize($s1);
$s2 = serialize($Woei2);
$Woei3 = unserialize($s2);
Expected result:
sleep
wakeup
sleep
wakeup
Actual result:
--
sleep
sleep
--
Edit this bug report at https://bugs.php.net/bug.php?id=60879edit=1
Bug #60788 [Com]: Curl file upload send bogus data to lighttpd web server
Edit report at https://bugs.php.net/bug.php?id=60788edit=1 ID: 60788 Comment by: valentin_grigoras at yahoo dot com Reported by:valentin_grigoras at yahoo dot com Summary:Curl file upload send bogus data to lighttpd web server Status: Bogus Type: Bug Package:cURL related Operating System: Linux/Windows PHP Version:5.3.9 Block user comment: N Private report: N New Comment: I don't see how it is a curl issue, since if I do the upload from command line, it works as expected, including from the servers with PHP 5.3.9: curl -F myfile=@/tmp/test_remote.txt http://xx.xx.xx.xx/cgi-bin/test.sh; --header Expect: /tmp/response.txt When I try attached code from PHP 5.3.x the file is sent to Lighttpd server so upload actually works (I assume this is correct part from your answer) but the server variables are not correct and filename is not received properly. it is wrong in the sense that a receiver should not assume otherwise I'm not sure how to interpret this, since I attached environment variables to see that POST_myfile_name=/tmp/test_remote.txt (sender full path) instead of POST_myfile_name=test_remote.txt (the name of uploaded file). Previous Comments: [2012-01-18 17:11:36] paj...@php.net It is not something PHP is responsible for, but here is the comment from the cURL project lead: it is correct in the sense that libcurl will use the path name specified to it. it is wrong in the sense that a receiver should not assume otherwise If you still consider that this should be different, please discuss this issue in the cURL tracker or on their mailing list. [2012-01-18 11:48:12] valentin_grigoras at yahoo dot com Description: Curl file upload fail when destination server was Lighttpd because received data is altered (POST variable FORM_file_name is set to original path of the uploaded file instead of actual file name). Destination server has lighttpd/1.4.29 Test servers had PHP 5.2.4, 5.3.2 (ubuntu 5.14) and 5.3.8 (Windows). Last one was updated to 5.3.9 Following code works on PHP 5.2.x and worked on older versions of PHP, but does not work on any 5.3.x versions. Same code was tested against Apache web server and it worked. Test script: --- ?php $url_post['myfile']='@/tmp/test_remote.txt'; $myHeaders=array( Expect: ); $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, http://xx.xx.xx.xx/cgi-bin/test.sh;); curl_setopt($ch, CURLOPT_PORT, 80); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_HTTPHEADER, $myHeaders); curl_setopt($ch, CURLOPT_HEADER, 0); curl_setopt($ch, CURLOPT_POSTFIELDS, $url_post); $curl_reponse=curl_exec($ch); echo 'Response: '.$curl_reponse; ? Expected result: CONTENT_TYPE=multipart/form-data; boundary=0de142dacc53 GATEWAY_INTERFACE=CGI/1.1 HASERL_SHELL=/bin/sh HASERLVER=0.9.27 REMOTE_ADDR=xx.xx.xx.xx POST_myfile=/tmp/m1fafJ HASERL_UPLOAD_DIR=/tmp DOCUMENT_ROOT=/www/ REMOTE_PORT=47209 HTTP_ACCEPT=*/* CONTENT_LENGTH=195 POST_myfile_name=test_remote.txt HASERL_UPLOAD_LIMIT=1000 SCRIPT_FILENAME=/www/cgi-bin/test.sh HTTP_HOST=xx.xx.xx.xx REQUEST_URI=/cgi-bin/test.sh HASERL_myfile_path=/tmp/m1fafJ SERVER_SOFTWARE=lighttpd/1.4.29 HASERL_ACCEPT_ALL=0 FORM_myfile=/tmp/m1fafJ SERVER_PROTOCOL=HTTP/1.1 SESSIONID=6c004f16ab26 REDIRECT_STATUS=200 FORM_myfile_name=test_remote.txt REQUEST_METHOD=POST SERVER_ADDR=0.0.0.0 PWD=/www/cgi-bin/cmh SERVER_PORT=80 SCRIPT_NAME=/cgi-bin/test.sh HTTP_CONTENT_LENGTH=195 SERVER_NAME=xx.xx.xx.xx Actual result: -- CONTENT_TYPE=multipart/form-data; boundary=bc7136747ad5 GATEWAY_INTERFACE=CGI/1.1 HASERL_SHELL=/bin/sh HASERLVER=0.9.27 REMOTE_ADDR=xx.xx.xx.xx POST_myfile=/tmp/Y9JqDF HASERL_UPLOAD_DIR=/tmp DOCUMENT_ROOT=/www/ REMOTE_PORT=52983 HTTP_ACCEPT=*/* CONTENT_LENGTH=10790 POST_myfile_name=/tmp/test_remote.txt HASERL_UPLOAD_LIMIT=1000 SCRIPT_FILENAME=/www/cgi-bin/test.sh HTTP_HOST=xx.xx.xx.xx REQUEST_URI=/cgi-bin/test.sh HASERL_myfile_path=/tmp/Y9JqDF SERVER_SOFTWARE=lighttpd/1.4.29 HASERL_ACCEPT_ALL=0 FORM_myfile=/tmp/Y9JqDF SERVER_PROTOCOL=HTTP/1.1 SESSIONID=6aa54f16ab0a REDIRECT_STATUS=200 FORM_myfile_name=/tmp/test_remote.txt REQUEST_METHOD=POST SERVER_ADDR=0.0.0.0 PWD=/www/cgi-bin SERVER_PORT=80 SCRIPT_NAME=/cgi-bin/test.sh HTTP_CONTENT_LENGTH=10790 SERVER_NAME=192.168.8.30 -- Edit this bug report at https://bugs.php.net/bug.php?id=60788edit=1
Bug #60879 [Fbk-Opn]: unserialize() Does not invoke __wakeup() on object
Edit report at https://bugs.php.net/bug.php?id=60879edit=1
ID: 60879
User updated by:thijsputman at gmail dot com
Reported by:thijsputman at gmail dot com
Summary:unserialize() Does not invoke __wakeup() on object
-Status: Feedback
+Status: Open
Type: Bug
Package:Class/Object related
Operating System: Windows 7
PHP Version:5.4.0RC6
Block user comment: N
Private report: N
New Comment:
Just tried with revision 322785 and it indeed works as expected.
To assert my sanity I re-downloaded 5.4.0RC6 (VC9 x86 Non Thread Safe,
2012-Jan-19 23:40:07) from the QA website and in that release the problem does
exist.
Previous Comments:
[2012-01-26 10:14:20] johan...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.4-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Works for me with latest svn. Do you have any special extension loaded or some
special configuration?
[2012-01-25 13:24:57] thijsputman at gmail dot com
Description:
When serializing/unserializing an object that contains both a __sleep() and
__wakeup() method, serialize() invokes the __sleep() method, but unserialize()
does *not* invoke the __wakeup() method.
Using PHP 5.4.0RC6 (x86 NTS) on Windows 7, previously used 5.4.0RC5 which did
not exhibit this problem. See the below test script for an example (which works
as expected in RC5, but not in RC6).
Test script:
---
class Woei{
public function __sleep(){
echo 'sleep' . PHP_EOL;
return array();
}
public function __wakeup(){
echo 'wakeup' . PHP_EOL;
}
}
$Woei = new Woei();
$s1 = serialize($Woei);
$Woei2 = unserialize($s1);
$s2 = serialize($Woei2);
$Woei3 = unserialize($s2);
Expected result:
sleep
wakeup
sleep
wakeup
Actual result:
--
sleep
sleep
--
Edit this bug report at https://bugs.php.net/bug.php?id=60879edit=1
Bug #60879 [Opn-Csd]: unserialize() Does not invoke __wakeup() on object
Edit report at https://bugs.php.net/bug.php?id=60879edit=1
ID: 60879
Updated by: johan...@php.net
Reported by:thijsputman at gmail dot com
Summary:unserialize() Does not invoke __wakeup() on object
-Status: Open
+Status: Closed
Type: Bug
Package:Class/Object related
Operating System: Windows 7
PHP Version:5.4.0RC6
-Assigned To:
+Assigned To:johannes
Block user comment: N
Private report: N
New Comment:
So let's assume this was fixed. I can't see a relevant change for this, though.
There will be another RC soon, an you check that, too, to be safe? Thanks :-)
Previous Comments:
[2012-01-26 10:56:17] thijsputman at gmail dot com
Just tried with revision 322785 and it indeed works as expected.
To assert my sanity I re-downloaded 5.4.0RC6 (VC9 x86 Non Thread Safe,
2012-Jan-19 23:40:07) from the QA website and in that release the problem does
exist.
[2012-01-26 10:14:20] johan...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.4-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Works for me with latest svn. Do you have any special extension loaded or some
special configuration?
[2012-01-25 13:24:57] thijsputman at gmail dot com
Description:
When serializing/unserializing an object that contains both a __sleep() and
__wakeup() method, serialize() invokes the __sleep() method, but unserialize()
does *not* invoke the __wakeup() method.
Using PHP 5.4.0RC6 (x86 NTS) on Windows 7, previously used 5.4.0RC5 which did
not exhibit this problem. See the below test script for an example (which works
as expected in RC5, but not in RC6).
Test script:
---
class Woei{
public function __sleep(){
echo 'sleep' . PHP_EOL;
return array();
}
public function __wakeup(){
echo 'wakeup' . PHP_EOL;
}
}
$Woei = new Woei();
$s1 = serialize($Woei);
$Woei2 = unserialize($s1);
$s2 = serialize($Woei2);
$Woei3 = unserialize($s2);
Expected result:
sleep
wakeup
sleep
wakeup
Actual result:
--
sleep
sleep
--
Edit this bug report at https://bugs.php.net/bug.php?id=60879edit=1
[PHP-BUG] Bug #60890 [NEW]: Can not read tgz file through Phar class, but related path works
From: Operating system: Mac OS 10.6 PHP version: 5.3.9 Package: PHAR related Bug Type: Bug Bug description:Can not read tgz file through Phar class, but related path works Description: Can not read tgz file with realpath, offsetGet works, offsetSet doesnt work. $p['file'] = 'content'; will fail. See: https://gist.github.com/1682446 Test script: --- https://gist.github.com/1682446 Actual result: -- See: https://gist.github.com/1682446 -- Edit bug report at https://bugs.php.net/bug.php?id=60890edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60890r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60890r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60890r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60890r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60890r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60890r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60890r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60890r=needscript Try newer version: https://bugs.php.net/fix.php?id=60890r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60890r=support Expected behavior: https://bugs.php.net/fix.php?id=60890r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60890r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60890r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60890r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60890r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60890r=dst IIS Stability: https://bugs.php.net/fix.php?id=60890r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60890r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60890r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60890r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60890r=mysqlcfg
[PHP-BUG] Bug #60891 [NEW]: FPM status serving should be moved to the master process
From: Operating system: Any PHP version: 5.3.9 Package: FPM related Bug Type: Bug Bug description:FPM status serving should be moved to the master process Description: When the server is overloaded, you cant query the FPM status page, however it should be its primary goal: being able to check whats going on. This way this cool feature is pointless. Test script: --- fpm conf: pm = dynamic pm.max_children = 1 pm.start_servers = 1 pm.min_spare_servers = 1 pm.max_spare_servers = 1 test script: ? sleep(60); ? And while the only worker process is sleeping, send a query to the status page. It wont be served. Expected result: Status page. Actual result: -- Hanging -- Edit bug report at https://bugs.php.net/bug.php?id=60891edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60891r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60891r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60891r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60891r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60891r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60891r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60891r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60891r=needscript Try newer version: https://bugs.php.net/fix.php?id=60891r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60891r=support Expected behavior: https://bugs.php.net/fix.php?id=60891r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60891r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60891r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60891r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60891r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60891r=dst IIS Stability: https://bugs.php.net/fix.php?id=60891r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60891r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60891r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60891r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60891r=mysqlcfg
Req #47051 [Com]: pg_fetch_object does not convert to literal PHP booleans
Edit report at https://bugs.php.net/bug.php?id=47051edit=1
ID: 47051
Comment by: morphunreal at gmail dot com
Reported by:germ dot van dot eck at gmail dot com
Summary:pg_fetch_object does not convert to literal PHP
booleans
Status: Open
Type: Feature/Change Request
Package:PostgreSQL related
Operating System: Linux, Ubuntu 8.04
PHP Version:5.2.8
Block user comment: N
Private report: N
New Comment:
I have created submitted a patch that allows pgsql to return booleans and
integers for all fetches.
to test / use-
- get current source for php/ext/pgsql
- apply patch
- phpize
- ./configure --with-pgsql=/path/to/pgsql/c-api
- make
- stop web server
- copy modules/pgsql.so over existing one
- add to /etc/php.d/pgsql.conf
pgsql.convert_boolean_type = 1
pgsql.convert_integer_type = 1
- start web server
Previous Comments:
[2009-01-11 01:05:09] fel...@php.net
This isn't a bug, it's only as pgsql works.
Moved to Feature/Change request.
[2009-01-09 13:30:24] germ dot van dot eck at gmail dot com
I did not complete my sentence...
This causes that postgresql.
should be
This causes that postgresql's booleans are not very usable in PHP.
[2009-01-09 13:24:51] germ dot van dot eck at gmail dot com
Description:
Postgresql booleans are internally stored as either 'f' or 't' (False or True).
On retrieval using pg_fetch_object, they are simply retrieved as PHP strings,
rather than either 0 or 1, or even better, false or true.
This causes that postgresql.
I am not sure, but I think in the data returned by the server, there is
metadata explaining the field types and so they could be automatically
converted to PHP bools.
This is from a bugreport and related forum topic that was made for the
CodeIgniter framework.
Bugreport (slighly unrelated CI bug, but this issue was discussed in the
comments):
http://codeigniter.com/bug_tracker/bug/6303/
Forum topic:
http://codeigniter.com/forums/viewthread/101001/
Reproduce code:
---
?php
$conn_string = host=testserver dbname=testdb user=foo password=bar;
$dbconn = pg_connect($conn_string);
pg_query('CREATE TABLE test(test boolean)');
pg_query('INSERT INTO test(test) VALUES(TRUE)');
$res = pg_query('SELECT * FROM test');
$obj = pg_fetch_object($res);
echo \n.$obj-test.\n;
pg_query('DROP TABLE test');
?
Expected result:
1
Actual result:
--
t
--
Edit this bug report at https://bugs.php.net/bug.php?id=47051edit=1
Bug #60867 [Com]: frensh part of function's list is down
Edit report at https://bugs.php.net/bug.php?id=60867edit=1 ID: 60867 Comment by: crashouille at gmail dot com Reported by:franc01s at ymail dot com Summary:frensh part of function's list is down Status: Open Type: Bug Package:*General Issues PHP Version:5.4.0RC6 Block user comment: N Private report: N New Comment: FYI, it's good now. All langage are available today. Previous Comments: [2012-01-24 10:50:32] franc01s at ymail dot com Description: /* Dear, I thought it was due to server maintenance but the english part of 'php's function list' is working fine. You can try it by yourself with this URL: http://fr.php.net/manual/fr/funcref.php Thanks for this web site. François. */ -- Edit this bug report at https://bugs.php.net/bug.php?id=60867edit=1
Bug #60490 [Com]: PHP 5.3.x will not compile gcc3.3.4
Edit report at https://bugs.php.net/bug.php?id=60490edit=1 ID: 60490 Comment by: andrew dot nimmo at gmail dot com Reported by:jeepee at gids dot nl Summary:PHP 5.3.x will not compile gcc3.3.4 Status: Open Type: Bug Package:*Compile Issues Operating System: Linux (Slackware 10) PHP Version:5.3.8 Block user comment: N Private report: N New Comment: I can duplicate this on Linux, Debian 5 (lenny). There appears to be a conflict with reassignment of #define's for, for example, DNS_T_A when libdjbdns is installed and /usr/include/dns.c contains non-integer defines. On Debian 5, removing the package libdjbdns-dev resolves the issue. Previous Comments: [2011-12-10 00:40:14] jeepee at gids dot nl Description: Tried a few versions in the 5.3.x range but all fail on: dns.c resides in /php-5.3.8/ext/standard/ dns.c: In function `php_parserr': dns.c:453: error: case label does not reduce to an integer constant dns.c:459: error: case label does not reduce to an integer constant dns.c:464: error: case label does not reduce to an integer constant dns.c:465: warning: comparison between pointer and integer dns.c:469: error: case label does not reduce to an integer constant dns.c:470: warning: comparison between pointer and integer dns.c:474: error: case label does not reduce to an integer constant dns.c:475: warning: comparison between pointer and integer dns.c:485: error: case label does not reduce to an integer constant dns.c:497: error: case label does not reduce to an integer constant dns.c:521: error: case label does not reduce to an integer constant dns.c:546: error: case label does not reduce to an integer constant Also tried the 5.3.9rc All 5.2.x versions compiled fine On slackware 13.xx compilation goes fine. Issue appears by simply running ./configure and make (no extra options provided) -- Edit this bug report at https://bugs.php.net/bug.php?id=60490edit=1
[PHP-BUG] Bug #60892 [NEW]: money_format returning inconsistent results
From: Operating system: OSX PHP version: 5.3.9 Package: Math related Bug Type: Bug Bug description:money_format returning inconsistent results Description: php -r '$a = 70687.465 + 8.930;$b = 70696.395;$c = 70687.464 + 8.936;printf(A: %s %s %.9f\n, $a, money_format(%.2n, $a), $a);printf(B: %s %s %.9f\n, $b, money_format(%.2n, $b), $b);printf(C: %s %s %.9f\n, $c, money_format(%.2n, $c), $c);' Output: A: 70696.395 70696.39 70696.39500 B: 70696.395 70696.40 70696.39500 C: 70696.4 70696.40 70696.4 Why is A not getting rounded up to 70696.40? Test script: --- php -r '$a = 70687.465 + 8.930;$b = 70696.395;$c = 70687.464 + 8.936;printf(A: %s %s %.9f\n, $a, money_format(%.2n, $a), $a);printf(B: %s %s %.9f\n, $b, money_format(%.2n, $b), $b);printf(C: %s %s %.9f\n, $c, money_format(%.2n, $c), $c);' Expected result: A: 70696.395 70696.40 70696.39500 B: 70696.395 70696.40 70696.39500 C: 70696.4 70696.40 70696.4 Actual result: -- A: 70696.395 70696.39 70696.39500 B: 70696.395 70696.40 70696.39500 C: 70696.4 70696.40 70696.4 -- Edit bug report at https://bugs.php.net/bug.php?id=60892edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60892r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60892r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60892r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60892r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60892r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60892r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60892r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60892r=needscript Try newer version: https://bugs.php.net/fix.php?id=60892r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60892r=support Expected behavior: https://bugs.php.net/fix.php?id=60892r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60892r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60892r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60892r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60892r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60892r=dst IIS Stability: https://bugs.php.net/fix.php?id=60892r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60892r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60892r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60892r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60892r=mysqlcfg
Bug #60892 [Opn]: money_format returning inconsistent results
Edit report at https://bugs.php.net/bug.php?id=60892edit=1 ID: 60892 User updated by:gregs at net-virtual dot com Reported by:gregs at net-virtual dot com Summary:money_format returning inconsistent results Status: Open Type: Bug Package:Math related Operating System: OSX PHP Version:5.3.9 Block user comment: N Private report: N New Comment: Here is a easier to read version of the test code (I also added one more): $a = 70687.465 + 8.930; $b = 70696.395; $c = 70687.464 + 8.936; $d = 70687.464 + 8.931; printf(A: %s %s %.9f\n, $a, money_format(%.2n, $a), $a); printf(B: %s %s %.9f\n, $b, money_format(%.2n, $b), $b); printf(C: %s %s %.9f\n, $c, money_format(%.2n, $c), $c); printf(D: %s %s %.9f\n, $d, money_format(%.2n, $d), $d); Output: A: 70696.395 70696.39 70696.39500 B: 70696.395 70696.40 70696.39500 C: 70696.4 70696.40 70696.4 D: 70696.395 70696.40 70696.39500 Previous Comments: [2012-01-26 14:47:43] gregs at net-virtual dot com Description: php -r '$a = 70687.465 + 8.930;$b = 70696.395;$c = 70687.464 + 8.936;printf(A: %s %s %.9f\n, $a, money_format(%.2n, $a), $a);printf(B: %s %s %.9f\n, $b, money_format(%.2n, $b), $b);printf(C: %s %s %.9f\n, $c, money_format(%.2n, $c), $c);' Output: A: 70696.395 70696.39 70696.39500 B: 70696.395 70696.40 70696.39500 C: 70696.4 70696.40 70696.4 Why is A not getting rounded up to 70696.40? Test script: --- php -r '$a = 70687.465 + 8.930;$b = 70696.395;$c = 70687.464 + 8.936;printf(A: %s %s %.9f\n, $a, money_format(%.2n, $a), $a);printf(B: %s %s %.9f\n, $b, money_format(%.2n, $b), $b);printf(C: %s %s %.9f\n, $c, money_format(%.2n, $c), $c);' Expected result: A: 70696.395 70696.40 70696.39500 B: 70696.395 70696.40 70696.39500 C: 70696.4 70696.40 70696.4 Actual result: -- A: 70696.395 70696.39 70696.39500 B: 70696.395 70696.40 70696.39500 C: 70696.4 70696.40 70696.4 -- Edit this bug report at https://bugs.php.net/bug.php?id=60892edit=1
Bug #60891 [Com]: FPM status serving should be moved to the master process
Edit report at https://bugs.php.net/bug.php?id=60891edit=1 ID: 60891 Comment by: ml at fatbsd dot com Reported by:erno dot kovacs at freemail dot hu Summary:FPM status serving should be moved to the master process Status: Open Type: Bug Package:FPM related Operating System: Any PHP Version:5.3.9 Block user comment: N Private report: N New Comment: for security reason and by design it's not possible to make the master process to listen to those requests. The only possibility is to fork another process only to handle this. And this is quite a a big change. It's on my todo list but no ETA yet. ++ fat Previous Comments: [2012-01-26 13:08:01] erno dot kovacs at freemail dot hu Description: When the server is overloaded, you cant query the FPM status page, however it should be its primary goal: being able to check whats going on. This way this cool feature is pointless. Test script: --- fpm conf: pm = dynamic pm.max_children = 1 pm.start_servers = 1 pm.min_spare_servers = 1 pm.max_spare_servers = 1 test script: ? sleep(60); ? And while the only worker process is sleeping, send a query to the status page. It wont be served. Expected result: Status page. Actual result: -- Hanging -- Edit this bug report at https://bugs.php.net/bug.php?id=60891edit=1
[PHP-BUG] Bug #60894 [NEW]: php-gd missing dependencies
From: Operating system: RHEL Server 6.2 (Santiago) PHP version: 5.3.9 Package: GD related Bug Type: Bug Bug description:php-gd missing dependencies Description: --- From manual page: http://www.php.net/book.image --- when installing php-gd via yum (remi6-x86_64 repo) it doesn't install libpng, or libXau as required to load correctly. This has been tested with version 5.3.9 from the remi6 repo, and with version 5.3.3 via the rhel-x86_64-server-6 repo. This bug only occurs with RHEL 6.2 from what I can test. (5.3.9 on RHEL 5 installs just fine) I apologize if this report needs to be filed with the repos. Thank You, Dann -- Edit bug report at https://bugs.php.net/bug.php?id=60894edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60894r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60894r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60894r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60894r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60894r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60894r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60894r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60894r=needscript Try newer version: https://bugs.php.net/fix.php?id=60894r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60894r=support Expected behavior: https://bugs.php.net/fix.php?id=60894r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60894r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60894r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60894r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60894r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60894r=dst IIS Stability: https://bugs.php.net/fix.php?id=60894r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60894r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60894r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60894r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60894r=mysqlcfg
Bug #60892 [Com]: money_format returning inconsistent results
Edit report at https://bugs.php.net/bug.php?id=60892edit=1 ID: 60892 Comment by: gregs at net-virtual dot com Reported by:gregs at net-virtual dot com Summary:money_format returning inconsistent results Status: Open Type: Bug Package:Math related Operating System: OSX PHP Version:5.3.9 Block user comment: N Private report: N New Comment: Also I should add that if I do this: $a = 8.930 + 70687.465; instead of this: $a = 70687.465 + 8.930; It works. The round() function seems to behave correctly in either case. I cannot tell from this behavior if the problem is in number_format (which may not be calling round(), but doing its own flawed rounding) or if it something deeper in how PHP is storing floats/doubles. Previous Comments: [2012-01-26 14:54:08] gregs at net-virtual dot com Here is a easier to read version of the test code (I also added one more): $a = 70687.465 + 8.930; $b = 70696.395; $c = 70687.464 + 8.936; $d = 70687.464 + 8.931; printf(A: %s %s %.9f\n, $a, money_format(%.2n, $a), $a); printf(B: %s %s %.9f\n, $b, money_format(%.2n, $b), $b); printf(C: %s %s %.9f\n, $c, money_format(%.2n, $c), $c); printf(D: %s %s %.9f\n, $d, money_format(%.2n, $d), $d); Output: A: 70696.395 70696.39 70696.39500 B: 70696.395 70696.40 70696.39500 C: 70696.4 70696.40 70696.4 D: 70696.395 70696.40 70696.39500 [2012-01-26 14:47:43] gregs at net-virtual dot com Description: php -r '$a = 70687.465 + 8.930;$b = 70696.395;$c = 70687.464 + 8.936;printf(A: %s %s %.9f\n, $a, money_format(%.2n, $a), $a);printf(B: %s %s %.9f\n, $b, money_format(%.2n, $b), $b);printf(C: %s %s %.9f\n, $c, money_format(%.2n, $c), $c);' Output: A: 70696.395 70696.39 70696.39500 B: 70696.395 70696.40 70696.39500 C: 70696.4 70696.40 70696.4 Why is A not getting rounded up to 70696.40? Test script: --- php -r '$a = 70687.465 + 8.930;$b = 70696.395;$c = 70687.464 + 8.936;printf(A: %s %s %.9f\n, $a, money_format(%.2n, $a), $a);printf(B: %s %s %.9f\n, $b, money_format(%.2n, $b), $b);printf(C: %s %s %.9f\n, $c, money_format(%.2n, $c), $c);' Expected result: A: 70696.395 70696.40 70696.39500 B: 70696.395 70696.40 70696.39500 C: 70696.4 70696.40 70696.4 Actual result: -- A: 70696.395 70696.39 70696.39500 B: 70696.395 70696.40 70696.39500 C: 70696.4 70696.40 70696.4 -- Edit this bug report at https://bugs.php.net/bug.php?id=60892edit=1
[PHP-BUG] Bug #60895 [NEW]: null pointer dereference in php_win32_free_rng_lock()
From: Operating system: Windows Server 2008 R2 x64 PHP version: 5.3.9 Package: Unknown/Other Function Bug Type: Bug Bug description:null pointer dereference in php_win32_free_rng_lock() Description: If php_win32_get_random_bytes() has never been called, then this line of code: + CryptReleaseContext(hCryptProv, 0); passes a null pointer, resulting in a C005 exception in CryptReleaseContext(). This line should be preceded by: if (has_crypto_ctx) This was specifically tested with the windows.php.net 32-bit TS build running on 64-bit Windows. I do not know how it behaves in other configurations. Test script: --- I do not have a short test case, but the bug is pretty obvious. -- Edit bug report at https://bugs.php.net/bug.php?id=60895edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60895r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60895r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60895r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60895r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60895r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60895r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60895r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60895r=needscript Try newer version: https://bugs.php.net/fix.php?id=60895r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60895r=support Expected behavior: https://bugs.php.net/fix.php?id=60895r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60895r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60895r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60895r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60895r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60895r=dst IIS Stability: https://bugs.php.net/fix.php?id=60895r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60895r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60895r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60895r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60895r=mysqlcfg
Bug #60895 [Com]: null pointer dereference in php_win32_free_rng_lock()
Edit report at https://bugs.php.net/bug.php?id=60895edit=1 ID: 60895 Comment by: root at ihack dot net Reported by:root at ihack dot net Summary:null pointer dereference in php_win32_free_rng_lock() Status: Open Type: Bug Package:Unknown/Other Function Operating System: Windows Server 2008 R2 x64 PHP Version:5.3.9 Block user comment: N Private report: N New Comment: BTW, this bug was introduced in revision 312201, during the 5.3.7 release cycle. Previous Comments: [2012-01-26 19:45:21] root at ihack dot net Description: If php_win32_get_random_bytes() has never been called, then this line of code: + CryptReleaseContext(hCryptProv, 0); passes a null pointer, resulting in a C005 exception in CryptReleaseContext(). This line should be preceded by: if (has_crypto_ctx) This was specifically tested with the windows.php.net 32-bit TS build running on 64-bit Windows. I do not know how it behaves in other configurations. Test script: --- I do not have a short test case, but the bug is pretty obvious. -- Edit this bug report at https://bugs.php.net/bug.php?id=60895edit=1
Bug #48507 [Com]: fgetcsv() ignoring special characters
Edit report at https://bugs.php.net/bug.php?id=48507edit=1
ID: 48507
Comment by: eswald at middil dot com
Reported by:krynble at yahoo dot com dot br
Summary:fgetcsv() ignoring special characters
Status: Bogus
Type: Bug
Package:Filesystem function related
Operating System: Unix
PHP Version:5.*
Block user comment: N
Private report: N
New Comment:
Confirmed with php5 (5.3.6-13ubuntu3.2 on Oneiric Ocelot); can be worked around
by quoting the value with quotation marks. For example, the line
a,a,é,é,óú,óú,óú,óú
yields
array (
0 = 'a',
1 = 'a',
2 = '',
3 = 'é',
4 = '',
5 = 'óú',
6 = 'ú',
7 = 'óú',
)
Note the corruption in elements 2, 4, and 6, but not in their quoted
counterparts 3, 5, and 7.
Previous Comments:
[2012-01-18 11:53:48] tero dot tasanen at gmail dot com
I can also confirm that this is an actual bug. File encoding UTF-8, locale
settings are set correctly and characters like äöå are dropped from the
beginning
of the csv column.
Tested with php versions 5.2.6, 5.2.10, 5.3.6
[2011-10-28 08:33:25] peter dot e dot lind at gmail dot com
This is definitely still a bug - my locale is set to da_DK.utf8, the file I'm
trying to read is in UTF8 (confirmed with a hex-editor but in fact does not
matter - the behaviour is the same, UTF8 or ISO-8859-1) yet special characters
are still thrown away when they are first in a field
[2011-10-18 13:59:30] me at monicag dot it
Quoting my fellows above: how comes this is not a bug?
[2011-10-10 10:03:58] ghosh at q-one dot com
Sorry. I don't understand why this isn't a bug either. Could someone please
elaborate? I tried setting all different kinds of locale to no avail. The first
letter of a string starting with a UTF-8 character is always missing. IMHO,
fgetcsv should work as a simple string operation (or - whatever weird things it
does right now - at least have a parameter to do so - count this as a feature
request if you wish). I think, the current behavior is totally confusing. For
instance, I don't understand why only the first character is missing but the
problem doesnt appear if a character is in the middle of a string.
[2011-07-17 16:19:28] max dot wildgrube at web dot de
The problem does also appears if the special char is preceded by a blank. This
blank also disappears.
I use this ugly workaround:
1. first reading the complete csv file into a variable: $import
2. $import = preg_replace ({(^|\t)([â¬-ÿ ])}m, $1~~$2, $import);
3. after fgetcsv; for each $field of the row array: $field = str_replace ('~~',
'', $field);
This means: before using fgetcsv inserting a magic sequence (e.g. ~~) on the
beginning of a field which begins with a blank or a special char; after parsing
with fgetcsv removing it from each field.
Max.
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=48507
--
Edit this bug report at https://bugs.php.net/bug.php?id=48507edit=1
Bug #48507 [Com]: fgetcsv() ignoring special characters
Edit report at https://bugs.php.net/bug.php?id=48507edit=1 ID: 48507 Comment by: eswald at middil dot com Reported by:krynble at yahoo dot com dot br Summary:fgetcsv() ignoring special characters Status: Bogus Type: Bug Package:Filesystem function related Operating System: Unix PHP Version:5.* Block user comment: N Private report: N New Comment: Tested with LANG=C, input file encoding of UTF-8. Also tested with LANG=C, input file encoding of cp1252, with identical results, except that the output characters (what was left of them) were also cp1252. Previous Comments: [2012-01-26 19:50:26] eswald at middil dot com Confirmed with php5 (5.3.6-13ubuntu3.2 on Oneiric Ocelot); can be worked around by quoting the value with quotation marks. For example, the line a,a,é,é,óú,óú,óú,óú yields array ( 0 = 'a', 1 = 'a', 2 = '', 3 = 'é', 4 = '', 5 = 'óú', 6 = 'ú', 7 = 'óú', ) Note the corruption in elements 2, 4, and 6, but not in their quoted counterparts 3, 5, and 7. [2012-01-18 11:53:48] tero dot tasanen at gmail dot com I can also confirm that this is an actual bug. File encoding UTF-8, locale settings are set correctly and characters like äöå are dropped from the beginning of the csv column. Tested with php versions 5.2.6, 5.2.10, 5.3.6 [2011-10-28 08:33:25] peter dot e dot lind at gmail dot com This is definitely still a bug - my locale is set to da_DK.utf8, the file I'm trying to read is in UTF8 (confirmed with a hex-editor but in fact does not matter - the behaviour is the same, UTF8 or ISO-8859-1) yet special characters are still thrown away when they are first in a field [2011-10-18 13:59:30] me at monicag dot it Quoting my fellows above: how comes this is not a bug? [2011-10-10 10:03:58] ghosh at q-one dot com Sorry. I don't understand why this isn't a bug either. Could someone please elaborate? I tried setting all different kinds of locale to no avail. The first letter of a string starting with a UTF-8 character is always missing. IMHO, fgetcsv should work as a simple string operation (or - whatever weird things it does right now - at least have a parameter to do so - count this as a feature request if you wish). I think, the current behavior is totally confusing. For instance, I don't understand why only the first character is missing but the problem doesnt appear if a character is in the middle of a string. 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=48507 -- Edit this bug report at https://bugs.php.net/bug.php?id=48507edit=1
Bug #60892 [Opn]: money_format returning inconsistent results
Edit report at https://bugs.php.net/bug.php?id=60892edit=1
ID: 60892
User updated by:gregs at net-virtual dot com
Reported by:gregs at net-virtual dot com
Summary:money_format returning inconsistent results
Status: Open
Type: Bug
Package:Math related
Operating System: OSX
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
This problem (if it is one) seems to extend to *printf* functions too:
$a = 8.930 + 70687.465;
$b = 70687.465 + 8.930;
$c = 70696.395000;
printf(A: %f, %.2f\n, $a, $a);
printf(B: %f %.2f\n, $b, $b);
printf(C: %f %.2f\n, $c , $c);'
Output:
A: 70696.395000, 70696.39
B: 70696.395000 70696.39
C: 70696.395000 70696.40
C version:
#include stdio.h
int main(void) {
float a, b, c, d;
a = 8.930 + 70687.465;
b = 70687.465 + 8.930;
c = 70696.395000;
printf(A: %f %.2f\n, a, a);
printf(B: %f %.2f\n, b, b);
printf(C: %f %.2f\n, c, c);
}
Output:
A: 70696.398438 70696.40
B: 70696.398438 70696.40
C: 70696.398438 70696.40
Previous Comments:
[2012-01-26 19:24:24] gregs at net-virtual dot com
Also I should add that if I do this:
$a = 8.930 + 70687.465;
instead of this:
$a = 70687.465 + 8.930;
It works. The round() function seems to behave correctly in either case. I
cannot tell from this behavior if the problem is in number_format (which may
not
be calling round(), but doing its own flawed rounding) or if it something
deeper
in how PHP is storing floats/doubles.
[2012-01-26 14:54:08] gregs at net-virtual dot com
Here is a easier to read version of the test code (I also added one more):
$a = 70687.465 + 8.930;
$b = 70696.395;
$c = 70687.464 + 8.936;
$d = 70687.464 + 8.931;
printf(A: %s %s %.9f\n, $a, money_format(%.2n, $a), $a);
printf(B: %s %s %.9f\n, $b, money_format(%.2n, $b), $b);
printf(C: %s %s %.9f\n, $c, money_format(%.2n, $c), $c);
printf(D: %s %s %.9f\n, $d, money_format(%.2n, $d), $d);
Output:
A: 70696.395 70696.39 70696.39500
B: 70696.395 70696.40 70696.39500
C: 70696.4 70696.40 70696.4
D: 70696.395 70696.40 70696.39500
[2012-01-26 14:47:43] gregs at net-virtual dot com
Description:
php -r '$a = 70687.465 + 8.930;$b = 70696.395;$c = 70687.464 + 8.936;printf(A:
%s
%s %.9f\n, $a, money_format(%.2n, $a), $a);printf(B: %s %s %.9f\n, $b,
money_format(%.2n, $b), $b);printf(C: %s %s %.9f\n, $c,
money_format(%.2n,
$c), $c);'
Output:
A: 70696.395 70696.39 70696.39500
B: 70696.395 70696.40 70696.39500
C: 70696.4 70696.40 70696.4
Why is A not getting rounded up to 70696.40?
Test script:
---
php -r '$a = 70687.465 + 8.930;$b = 70696.395;$c = 70687.464 + 8.936;printf(A:
%s %s %.9f\n, $a, money_format(%.2n, $a), $a);printf(B: %s %s %.9f\n, $b,
money_format(%.2n, $b), $b);printf(C: %s %s %.9f\n, $c,
money_format(%.2n, $c), $c);'
Expected result:
A: 70696.395 70696.40 70696.39500
B: 70696.395 70696.40 70696.39500
C: 70696.4 70696.40 70696.4
Actual result:
--
A: 70696.395 70696.39 70696.39500
B: 70696.395 70696.40 70696.39500
C: 70696.4 70696.40 70696.4
--
Edit this bug report at https://bugs.php.net/bug.php?id=60892edit=1
Bug #60892 [Opn-Bgs]: money_format returning inconsistent results
Edit report at https://bugs.php.net/bug.php?id=60892edit=1
ID: 60892
Updated by: johan...@php.net
Reported by:gregs at net-virtual dot com
Summary:money_format returning inconsistent results
-Status: Open
+Status: Bogus
Type: Bug
Package:Math related
Operating System: OSX
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
Floating point values have a limited precision. Hence a value might
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly
printing it without any mathematical operations.
If you would like to know more about floats and what IEEE
754 is, read this:
http://www.floating-point-gui.de/
Thank you for your interest in PHP.
As you said - it's related to the way PHP (and almost all computers) store
floating point numbers.
Previous Comments:
[2012-01-26 22:09:40] gregs at net-virtual dot com
This problem (if it is one) seems to extend to *printf* functions too:
$a = 8.930 + 70687.465;
$b = 70687.465 + 8.930;
$c = 70696.395000;
printf(A: %f, %.2f\n, $a, $a);
printf(B: %f %.2f\n, $b, $b);
printf(C: %f %.2f\n, $c , $c);'
Output:
A: 70696.395000, 70696.39
B: 70696.395000 70696.39
C: 70696.395000 70696.40
C version:
#include stdio.h
int main(void) {
float a, b, c, d;
a = 8.930 + 70687.465;
b = 70687.465 + 8.930;
c = 70696.395000;
printf(A: %f %.2f\n, a, a);
printf(B: %f %.2f\n, b, b);
printf(C: %f %.2f\n, c, c);
}
Output:
A: 70696.398438 70696.40
B: 70696.398438 70696.40
C: 70696.398438 70696.40
[2012-01-26 19:24:24] gregs at net-virtual dot com
Also I should add that if I do this:
$a = 8.930 + 70687.465;
instead of this:
$a = 70687.465 + 8.930;
It works. The round() function seems to behave correctly in either case. I
cannot tell from this behavior if the problem is in number_format (which may
not
be calling round(), but doing its own flawed rounding) or if it something
deeper
in how PHP is storing floats/doubles.
[2012-01-26 14:54:08] gregs at net-virtual dot com
Here is a easier to read version of the test code (I also added one more):
$a = 70687.465 + 8.930;
$b = 70696.395;
$c = 70687.464 + 8.936;
$d = 70687.464 + 8.931;
printf(A: %s %s %.9f\n, $a, money_format(%.2n, $a), $a);
printf(B: %s %s %.9f\n, $b, money_format(%.2n, $b), $b);
printf(C: %s %s %.9f\n, $c, money_format(%.2n, $c), $c);
printf(D: %s %s %.9f\n, $d, money_format(%.2n, $d), $d);
Output:
A: 70696.395 70696.39 70696.39500
B: 70696.395 70696.40 70696.39500
C: 70696.4 70696.40 70696.4
D: 70696.395 70696.40 70696.39500
[2012-01-26 14:47:43] gregs at net-virtual dot com
Description:
php -r '$a = 70687.465 + 8.930;$b = 70696.395;$c = 70687.464 + 8.936;printf(A:
%s
%s %.9f\n, $a, money_format(%.2n, $a), $a);printf(B: %s %s %.9f\n, $b,
money_format(%.2n, $b), $b);printf(C: %s %s %.9f\n, $c,
money_format(%.2n,
$c), $c);'
Output:
A: 70696.395 70696.39 70696.39500
B: 70696.395 70696.40 70696.39500
C: 70696.4 70696.40 70696.4
Why is A not getting rounded up to 70696.40?
Test script:
---
php -r '$a = 70687.465 + 8.930;$b = 70696.395;$c = 70687.464 + 8.936;printf(A:
%s %s %.9f\n, $a, money_format(%.2n, $a), $a);printf(B: %s %s %.9f\n, $b,
money_format(%.2n, $b), $b);printf(C: %s %s %.9f\n, $c,
money_format(%.2n, $c), $c);'
Expected result:
A: 70696.395 70696.40 70696.39500
B: 70696.395 70696.40 70696.39500
C: 70696.4 70696.40 70696.4
Actual result:
--
A: 70696.395 70696.39 70696.39500
B: 70696.395 70696.40 70696.39500
C: 70696.4 70696.40 70696.4
--
Edit this bug report at https://bugs.php.net/bug.php?id=60892edit=1
Bug #60894 [Opn-Bgs]: php-gd missing dependencies
Edit report at https://bugs.php.net/bug.php?id=60894edit=1 ID: 60894 Updated by: johan...@php.net Reported by:dannbohn at gmail dot com Summary:php-gd missing dependencies -Status: Open +Status: Bogus Type: Bug Package:GD related Operating System: RHEL Server 6.2 (Santiago) PHP Version:5.3.9 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. Yes, this is dependent on your packager. Previous Comments: [2012-01-26 18:51:39] dannbohn at gmail dot com Description: --- From manual page: http://www.php.net/book.image --- when installing php-gd via yum (remi6-x86_64 repo) it doesn't install libpng, or libXau as required to load correctly. This has been tested with version 5.3.9 from the remi6 repo, and with version 5.3.3 via the rhel-x86_64-server-6 repo. This bug only occurs with RHEL 6.2 from what I can test. (5.3.9 on RHEL 5 installs just fine) I apologize if this report needs to be filed with the repos. Thank You, Dann -- Edit this bug report at https://bugs.php.net/bug.php?id=60894edit=1
[PHP-BUG] Req #60896 [NEW]: Provide a wrapper for pipe(2)
From: Operating system: Unix PHP version: Irrelevant Package: POSIX related Bug Type: Feature/Change Request Bug description:Provide a wrapper for pipe(2) Description: Currently, there does not seem to be a way to create an anonymous pipe (which is particularily) via the pipe(2) system call. There should be a wrapper for pipe and optionally pipe2 in php. See http://pubs.opengroup.org/onlinepubs/009695399/functions/pipe.html for the POSIX spec. Test script: --- ? list($readfd, $writefd) = posix_pipe(); -- Edit bug report at https://bugs.php.net/bug.php?id=60896edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60896r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60896r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60896r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60896r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60896r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60896r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60896r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60896r=needscript Try newer version: https://bugs.php.net/fix.php?id=60896r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60896r=support Expected behavior: https://bugs.php.net/fix.php?id=60896r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60896r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60896r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60896r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60896r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60896r=dst IIS Stability: https://bugs.php.net/fix.php?id=60896r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60896r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60896r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60896r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60896r=mysqlcfg
Bug #60624 [Opn-Fbk]: Incorrect Invalid variable used for bind error
Edit report at https://bugs.php.net/bug.php?id=60624edit=1
ID: 60624
Updated by: s...@php.net
Reported by:935c at itsynergy dot co dot uk
Summary:Incorrect Invalid variable used for bind error
-Status: Open
+Status: Feedback
Type: Bug
Package:OCI8 related
Operating System: Scientific Linux 6.1
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Can you give a concrete example of a failing $p_tkn token? Also what is the
fs_pkg signature? Do the oci_bind_by_name calls return errors?
Previous Comments:
[2011-12-29 13:47:27] 935c at itsynergy dot co dot uk
update php version
[2011-12-29 11:37:52] 935c at itsynergy dot co dot uk
OCI8 Supportenabled
Version 1.4.6
Revision$Revision: 313688 $
Active Persistent Connections 0
Active Connections 0
Oracle Run-time Client Library Version 11.2.0.2.0
Oracle Version 11.2
Compile-time ORACLE_HOME/u01/app/oracle/product/11.2.0/xe
Libraries Used -Wl,-rpath,/u01/app/oracle/product/11.2.0/xe/lib -
L/u01/app/oracle/product/11.2.0/xe/lib -lclntsh
Temporary Lob support enabled
Collections support enabled
Directive Local Value Master Value
oci8.connection_class no valueno value
oci8.default_prefetch 100 100
oci8.events Off Off
oci8.max_persistent -1 -1
oci8.old_oci_close_semanticsOff Off
oci8.persistent_timeout -1 -1
oci8.ping_interval 60 60
oci8.privileged_connect Off Off
oci8.statement_cache_size 20 20
[2011-12-29 11:35:30] 935c at itsynergy dot co dot uk
Description:
I am seeing the following errors generated for no apparent reason when a
function
is used as a string source:
PHP Warning: oci_bind_by_name(): Invalid variable used for bind
PHP Warning: oci_execute(): ORA-01008: not all variables bound
If I replace the $sim_token parameter in my FS_ORA_NEW_SIMTOKEN call with a
static string, e.g. 2, then it all works fine.
Test script:
---
-- The OCI8 Call --
function FS_ORA_NEW_SIMTOKEN($p_sess,$p_tkn) {
$c = FS_ORA_CONNECT();
$s = oci_parse($c, begin fs_pkg_X.new_auth(:p_sess,:p_sim);end;);
oci_bind_by_name($s,:p_sess,$p_sess,-1,SQLT_CHR);
oci_bind_by_name($s,:p_sim,$p_tkn,-1,SQLT_CHR);
$exec_status=oci_execute($s);
oci_free_statement($s);
return $exec_status;
}
-- The Token Generator--
function FS_SIMAPI_GETTOKEN() {
$valid_time=time()+FS_SIM_TOKLEN;
$sesskey=htmlspecialchars(sha1(X));
$qry_array=array(
'mode' = 'AUTH',
'user' = FS_SIM_UNA,
'clientip'=FS_SIM_SRCIP,
'expiry' = $valid_time,
'key' = $sesskey
);
$tokres=FS_SIMAPI_SIMPLEPOST(XXX AUTH,$qry_array);
if ($tokres==false) {
return false;
}
libxml_use_internal_errors(true);
try {
$xmlp=new SimpleXMLElement($tokres);
} catch (Exception $e) {
foreach(libxml_get_errors() as $error_line) {
$error_msg = SimpleXML: .$error_line-message;
FS_APPTOOL_LOGERR($error_msg);
}
return false;
}
return $xmlp-results-token;
}
-- The Application Call--
// 4 XX Token
$sim_token=FS_SIMAPI_GETTOKEN();
if($sim_token!=false) {
$sim_to_db=FS_ORA_NEW_SIMTOKEN($_COOKIE['fs_cookie'],$sim_token);
if($sim_to_db==false) {
header(Location: . FS_APP_HOME_URI . ?autherr= .
urlencode(FS_ERR_SIMFAIL));
exit;
}
} else {
header(Location: . FS_APP_HOME_URI . ?autherr= .
urlencode($sim_token));
exit;
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60624edit=1
Bug #60187 [Com]: pgsql module returns strings from SELECT queries for each unempty field
Edit report at https://bugs.php.net/bug.php?id=60187edit=1
ID: 60187
Comment by: morphunreal at gmail dot com
Reported by:gatekeeper dot mail at gmail dot com
Summary:pgsql module returns strings from SELECT queries for
each unempty field
Status: Open
Type: Bug
Package:PostgreSQL related
Operating System: SuSE Linux 11 SP1
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
same patch that I have created for bug #47051 (except that issue was from 2009).
for backwards compatibility i have had to add the options
pgsql.convert_boolean_type pgsql.convert_integer_type
to test / use-
- get current source for php/ext/pgsql
- apply patch
- phpize
- ./configure --with-pgsql=/path/to/pgsql/c-api
- make
- stop web server
- copy modules/pgsql.so over existing one
- add to /etc/php.d/pgsql.conf
pgsql.convert_boolean_type = 1
pgsql.convert_integer_type = 1
- start web server
Previous Comments:
[2011-11-01 10:47:13] gatekeeper dot mail at gmail dot com
Description:
pgsql modules returns all non-null values as String type data instead of
corresponding php datatype when applicable. PDO is not affected though.
Test script:
---
# CREATE TABLE netusers (id bigserial NOT NULL, firstname character varying NOT
NULL, middlename character varying NOT NULL DEFAULT ''::character varying,
lastname character varying NOT NULL DEFAULT ''::character varying, company_id
integer NOT NULL DEFAULT 0, department_id integer NOT NULL DEFAULT 0,
connect_date date NOT NULL DEFAULT now(), disconnect_date date, login character
varying NOT NULL DEFAULT ''::character varying, password character varying NOT
NULL DEFAULT ''::character varying, email text NOT NULL DEFAULT ''::character
varying, email_alias text NOT NULL DEFAULT ''::character varying, computer
character varying NOT NULL DEFAULT ''::character varying, ipaddr bigint NOT
NULL DEFAULT 0, macaddr bigint NOT NULL DEFAULT 0, inet_date date, phone_local
text NOT NULL DEFAULT ''::text, phone_global text NOT NULL DEFAULT ''::text,
comment text, cable_id bigint NOT NULL DEFAULT 0, CONSTRAINT netusers_pk
PRIMARY KEY (id )) WITH (OIDS=FALSE);
# Put a row into that table with some random (but according to columns'
datatype) data
?php
$dsn = 'pgsql:host=host;port=5432;dbname=testdb';
$username = 'test';
$password = 'testpw';
$conn = new PDO($dsn, $username, $password);
$stmt = $conn-query('select * from netusers');
$o = $stmt-fetchObject();
//This gets appropriate datatypes for all non-null fields (int for int, string
for string etc... Except (hell yeah!) arrays)
var_dump($o);
//*
$conn2 = pg_connect(host=host port=5432 dbname=testdb user=test
password=testpw);
$stmt2 = pg_query($conn2, SELECT * FROM netusers);
$o2 = pg_fetch_object($stmt2);
//This gets an object with every non-null property having datatype string
var_dump($o2);
Expected result:
# This is the PDO output part of the test script
object(stdClass)#3 (20) {
[id]=
int(0)
[firstname]=
string(3) asd
[middlename]=
string(7) dasfsdf
[lastname]=
string(8) sdafdsdf
[company_id]=
int(0)
[department_id]=
int(0)
[connect_date]=
string(10) 2011-10-28
[disconnect_date]=
NULL
[login]=
string(6) asfdfg
[password]=
string(6) dfsdfg
[email]=
string(22) cvbcvb...@xcvxcvxcv.as
[email_alias]=
string(0)
[computer]=
string(5) sdasd
[ipaddr]=
int(0)
[macaddr]=
int(0)
[inet_date]=
NULL
[phone_local]=
string(6) 234234
[phone_global]=
string(0)
[comment]=
string(14) svsdfgsdfgsdfg
[cable_id]=
int(0)
}
Actual result:
--
# This is the PGSQL output part of the test script
object(stdClass)#4 (20) {
[id]=
string(1) 0
[firstname]=
string(3) asd
[middlename]=
string(7) dasfsdf
[lastname]=
string(8) sdafdsdf
[company_id]=
string(1) 0
[department_id]=
string(1) 0
[connect_date]=
string(10) 2011-10-28
[disconnect_date]=
NULL
[login]=
string(6) asfdfg
[password]=
string(6) dfsdfg
[email]=
string(22) cvbcvb...@xcvxcvxcv.as
[email_alias]=
string(0)
[computer]=
string(5) sdasd
[ipaddr]=
string(1) 0
[macaddr]=
string(1) 0
[inet_date]=
NULL
[phone_local]=
string(6) 234234
[phone_global]=
string(0)
[comment]=
string(14) svsdfgsdfgsdfg
[cable_id]=
string(1) 0
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60187edit=1
[PHP-BUG] Bug #60898 [NEW]: Failed to upload files when content-type contain charset
From: Operating system: Linux PHP version: 5.3.9 Package: *General Issues Bug Type: Bug Bug description:Failed to upload files when content-type contain charset Description: When I try to upload files using HTTP post with header Content-Type: multipart/form-data; boundary=-NPRequestBoundary- everything works as expected but trying to use Content-Type: multipart/form-data; boundary=- NPRequestBoundary-; charset=UTF-8 cause completely blank $_FILES array. Expected result: Full $_FILES array Actual result: -- Empty $_FILES array -- Edit bug report at https://bugs.php.net/bug.php?id=60898edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60898r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60898r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60898r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60898r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60898r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60898r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60898r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60898r=needscript Try newer version: https://bugs.php.net/fix.php?id=60898r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60898r=support Expected behavior: https://bugs.php.net/fix.php?id=60898r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60898r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60898r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60898r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60898r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60898r=dst IIS Stability: https://bugs.php.net/fix.php?id=60898r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60898r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60898r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60898r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60898r=mysqlcfg
Bug #60892 [Com]: money_format returning inconsistent results
Edit report at https://bugs.php.net/bug.php?id=60892edit=1
ID: 60892
Comment by: gregs at net-virtual dot com
Reported by:gregs at net-virtual dot com
Summary:money_format returning inconsistent results
Status: Bogus
Type: Bug
Package:Math related
Operating System: OSX
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
With all due respect, you are not reading this.
sprintf('%.2f', $float);
number_format('%.2n', $float);
should *ROUND* these numbers, the behavior is incorrect
Previous Comments:
[2012-01-26 22:13:57] johan...@php.net
Floating point values have a limited precision. Hence a value might
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly
printing it without any mathematical operations.
If you would like to know more about floats and what IEEE
754 is, read this:
http://www.floating-point-gui.de/
Thank you for your interest in PHP.
As you said - it's related to the way PHP (and almost all computers) store
floating point numbers.
[2012-01-26 22:09:40] gregs at net-virtual dot com
This problem (if it is one) seems to extend to *printf* functions too:
$a = 8.930 + 70687.465;
$b = 70687.465 + 8.930;
$c = 70696.395000;
printf(A: %f, %.2f\n, $a, $a);
printf(B: %f %.2f\n, $b, $b);
printf(C: %f %.2f\n, $c , $c);'
Output:
A: 70696.395000, 70696.39
B: 70696.395000 70696.39
C: 70696.395000 70696.40
C version:
#include stdio.h
int main(void) {
float a, b, c, d;
a = 8.930 + 70687.465;
b = 70687.465 + 8.930;
c = 70696.395000;
printf(A: %f %.2f\n, a, a);
printf(B: %f %.2f\n, b, b);
printf(C: %f %.2f\n, c, c);
}
Output:
A: 70696.398438 70696.40
B: 70696.398438 70696.40
C: 70696.398438 70696.40
[2012-01-26 19:24:24] gregs at net-virtual dot com
Also I should add that if I do this:
$a = 8.930 + 70687.465;
instead of this:
$a = 70687.465 + 8.930;
It works. The round() function seems to behave correctly in either case. I
cannot tell from this behavior if the problem is in number_format (which may
not
be calling round(), but doing its own flawed rounding) or if it something
deeper
in how PHP is storing floats/doubles.
[2012-01-26 14:54:08] gregs at net-virtual dot com
Here is a easier to read version of the test code (I also added one more):
$a = 70687.465 + 8.930;
$b = 70696.395;
$c = 70687.464 + 8.936;
$d = 70687.464 + 8.931;
printf(A: %s %s %.9f\n, $a, money_format(%.2n, $a), $a);
printf(B: %s %s %.9f\n, $b, money_format(%.2n, $b), $b);
printf(C: %s %s %.9f\n, $c, money_format(%.2n, $c), $c);
printf(D: %s %s %.9f\n, $d, money_format(%.2n, $d), $d);
Output:
A: 70696.395 70696.39 70696.39500
B: 70696.395 70696.40 70696.39500
C: 70696.4 70696.40 70696.4
D: 70696.395 70696.40 70696.39500
[2012-01-26 14:47:43] gregs at net-virtual dot com
Description:
php -r '$a = 70687.465 + 8.930;$b = 70696.395;$c = 70687.464 + 8.936;printf(A:
%s
%s %.9f\n, $a, money_format(%.2n, $a), $a);printf(B: %s %s %.9f\n, $b,
money_format(%.2n, $b), $b);printf(C: %s %s %.9f\n, $c,
money_format(%.2n,
$c), $c);'
Output:
A: 70696.395 70696.39 70696.39500
B: 70696.395 70696.40 70696.39500
C: 70696.4 70696.40 70696.4
Why is A not getting rounded up to 70696.40?
Test script:
---
php -r '$a = 70687.465 + 8.930;$b = 70696.395;$c = 70687.464 + 8.936;printf(A:
%s %s %.9f\n, $a, money_format(%.2n, $a), $a);printf(B: %s %s %.9f\n, $b,
money_format(%.2n, $b), $b);printf(C: %s %s %.9f\n, $c,
money_format(%.2n, $c), $c);'
Expected result:
A: 70696.395 70696.40 70696.39500
B: 70696.395 70696.40 70696.39500
C: 70696.4 70696.40 70696.4
Actual result:
--
A: 70696.395 70696.39 70696.39500
B: 70696.395 70696.40 70696.39500
C: 70696.4 70696.40 70696.4
--
Edit this bug report at https://bugs.php.net/bug.php?id=60892edit=1
Bug #60892 [Com]: money_format returning inconsistent results
Edit report at https://bugs.php.net/bug.php?id=60892edit=1
ID: 60892
Comment by: gregs at net-virtual dot com
Reported by:gregs at net-virtual dot com
Summary:money_format returning inconsistent results
Status: Bogus
Type: Bug
Package:Math related
Operating System: OSX
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
Sorry, I meant money_format('%.2n', $float);
In all of these cases the number should be rounded to 70696.40.
Previous Comments:
[2012-01-27 03:43:37] gregs at net-virtual dot com
With all due respect, you are not reading this.
sprintf('%.2f', $float);
number_format('%.2n', $float);
should *ROUND* these numbers, the behavior is incorrect
[2012-01-26 22:13:57] johan...@php.net
Floating point values have a limited precision. Hence a value might
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly
printing it without any mathematical operations.
If you would like to know more about floats and what IEEE
754 is, read this:
http://www.floating-point-gui.de/
Thank you for your interest in PHP.
As you said - it's related to the way PHP (and almost all computers) store
floating point numbers.
[2012-01-26 22:09:40] gregs at net-virtual dot com
This problem (if it is one) seems to extend to *printf* functions too:
$a = 8.930 + 70687.465;
$b = 70687.465 + 8.930;
$c = 70696.395000;
printf(A: %f, %.2f\n, $a, $a);
printf(B: %f %.2f\n, $b, $b);
printf(C: %f %.2f\n, $c , $c);'
Output:
A: 70696.395000, 70696.39
B: 70696.395000 70696.39
C: 70696.395000 70696.40
C version:
#include stdio.h
int main(void) {
float a, b, c, d;
a = 8.930 + 70687.465;
b = 70687.465 + 8.930;
c = 70696.395000;
printf(A: %f %.2f\n, a, a);
printf(B: %f %.2f\n, b, b);
printf(C: %f %.2f\n, c, c);
}
Output:
A: 70696.398438 70696.40
B: 70696.398438 70696.40
C: 70696.398438 70696.40
[2012-01-26 19:24:24] gregs at net-virtual dot com
Also I should add that if I do this:
$a = 8.930 + 70687.465;
instead of this:
$a = 70687.465 + 8.930;
It works. The round() function seems to behave correctly in either case. I
cannot tell from this behavior if the problem is in number_format (which may
not
be calling round(), but doing its own flawed rounding) or if it something
deeper
in how PHP is storing floats/doubles.
[2012-01-26 14:54:08] gregs at net-virtual dot com
Here is a easier to read version of the test code (I also added one more):
$a = 70687.465 + 8.930;
$b = 70696.395;
$c = 70687.464 + 8.936;
$d = 70687.464 + 8.931;
printf(A: %s %s %.9f\n, $a, money_format(%.2n, $a), $a);
printf(B: %s %s %.9f\n, $b, money_format(%.2n, $b), $b);
printf(C: %s %s %.9f\n, $c, money_format(%.2n, $c), $c);
printf(D: %s %s %.9f\n, $d, money_format(%.2n, $d), $d);
Output:
A: 70696.395 70696.39 70696.39500
B: 70696.395 70696.40 70696.39500
C: 70696.4 70696.40 70696.4
D: 70696.395 70696.40 70696.39500
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=60892
--
Edit this bug report at https://bugs.php.net/bug.php?id=60892edit=1
Req #60836 [Com]: Improve array_intersect_key performance
Edit report at https://bugs.php.net/bug.php?id=60836edit=1
ID: 60836
Comment by: carloschilazo at gmail dot com
Reported by:oliver at hofff dot com
Summary:Improve array_intersect_key performance
Status: Open
Type: Feature/Change Request
Package:Arrays related
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
we cant start walking the shortest array given, because we first need to know
which elements we need to look in the other arrays, and those are the ones
presesnt in the first array
returns an array containing all the entries of array1 which have keys that
are
present in all the arguments.
Previous Comments:
[2012-01-22 00:34:49] oliver at hofff dot com
Description:
The trivial test script below runs longer than the extpected instant
execution (lot longer).
This is because the algorithm walks the first argument and looks up the key in
every other array supplied as an argument.
Instead it should walk the shortest array given, and look up the keys in every
other array.
Maybe this issue or similar ones also apply to other array functions, which
perform set operations, but I have not checked the code of them.
Of course the optimization could be done in userland, but that feels not right.
Test script:
---
$arr = array_fill(0, 100, '...');
$i = 1000;
while($i--) {
array_intersect_key($arr, array());
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60836edit=1
Bug #60892 [Bgs]: money_format returning inconsistent results
Edit report at https://bugs.php.net/bug.php?id=60892edit=1
ID: 60892
User updated by:gregs at net-virtual dot com
Reported by:gregs at net-virtual dot com
Summary:money_format returning inconsistent results
Status: Bogus
Type: Bug
Package:Math related
Operating System: OSX
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
If anyone else runs across this, there is a good write-up here of the problem
(with some proposals to fix it):
https://wiki.php.net/rfc/rounding
My take-away is that when using %f in any of the *printf* functions (which I
presume money_format uses - what others I can only imagine), the only way to
get
true correctly rounded numbers is to explicitly round() the float before using
it.
Previous Comments:
[2012-01-27 03:45:28] gregs at net-virtual dot com
Sorry, I meant money_format('%.2n', $float);
In all of these cases the number should be rounded to 70696.40.
[2012-01-27 03:43:37] gregs at net-virtual dot com
With all due respect, you are not reading this.
sprintf('%.2f', $float);
number_format('%.2n', $float);
should *ROUND* these numbers, the behavior is incorrect
[2012-01-26 22:13:57] johan...@php.net
Floating point values have a limited precision. Hence a value might
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly
printing it without any mathematical operations.
If you would like to know more about floats and what IEEE
754 is, read this:
http://www.floating-point-gui.de/
Thank you for your interest in PHP.
As you said - it's related to the way PHP (and almost all computers) store
floating point numbers.
[2012-01-26 22:09:40] gregs at net-virtual dot com
This problem (if it is one) seems to extend to *printf* functions too:
$a = 8.930 + 70687.465;
$b = 70687.465 + 8.930;
$c = 70696.395000;
printf(A: %f, %.2f\n, $a, $a);
printf(B: %f %.2f\n, $b, $b);
printf(C: %f %.2f\n, $c , $c);'
Output:
A: 70696.395000, 70696.39
B: 70696.395000 70696.39
C: 70696.395000 70696.40
C version:
#include stdio.h
int main(void) {
float a, b, c, d;
a = 8.930 + 70687.465;
b = 70687.465 + 8.930;
c = 70696.395000;
printf(A: %f %.2f\n, a, a);
printf(B: %f %.2f\n, b, b);
printf(C: %f %.2f\n, c, c);
}
Output:
A: 70696.398438 70696.40
B: 70696.398438 70696.40
C: 70696.398438 70696.40
[2012-01-26 19:24:24] gregs at net-virtual dot com
Also I should add that if I do this:
$a = 8.930 + 70687.465;
instead of this:
$a = 70687.465 + 8.930;
It works. The round() function seems to behave correctly in either case. I
cannot tell from this behavior if the problem is in number_format (which may
not
be calling round(), but doing its own flawed rounding) or if it something
deeper
in how PHP is storing floats/doubles.
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=60892
--
Edit this bug report at https://bugs.php.net/bug.php?id=60892edit=1
[PHP-BUG] Bug #60899 [NEW]: don´t compile
From: Operating system: linux PHP version: 5.3.9 Package: *General Issues Bug Type: Bug Bug description:don´t compile Description: hi guys php-perl don´t compile on php 5.3.9 at x86-64 computer any help? i wget the package, tar -zxf it, phpize, ./configure, make and it give a error /var/abs/local/php-perl/perl-1.0.0/php_perl.c: At top level: /var/abs/local/php-perl/perl-1.0.0/php_perl.c:1946:3: error: 'PHP_PERL_VERSION' undeclared here (not in a function) Test script: --- ? no script, it´s at compile time of extension Expected result: just compile it, maybe old code didn´t allow php 5.3 api Actual result: -- no compile :( no extensio :'( -- Edit bug report at https://bugs.php.net/bug.php?id=60899edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60899r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60899r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60899r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60899r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60899r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60899r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60899r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60899r=needscript Try newer version: https://bugs.php.net/fix.php?id=60899r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60899r=support Expected behavior: https://bugs.php.net/fix.php?id=60899r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60899r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60899r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60899r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60899r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60899r=dst IIS Stability: https://bugs.php.net/fix.php?id=60899r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60899r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60899r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60899r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60899r=mysqlcfg
Bug #60887 [Com]: SoapClient ignores user_agent option and sends no User-Agent header
Edit report at https://bugs.php.net/bug.php?id=60887edit=1
ID: 60887
Comment by: carloschilazo at gmail dot com
Reported by:mail at tomsommer dot dk
Summary:SoapClient ignores user_agent option and sends no
User-Agent header
Status: Open
Type: Bug
Package:SOAP related
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
I could not reproduce your problem, using PHP 5.3.9 (linux) was able to send a
request with user_agent header set
I captured with WireShark could you please try to:
a) capture with another program (maybe)
b) make sure that on the other end , the user_agent is not being stripped
or provide more info
Previous Comments:
[2012-01-26 07:16:20] mail at tomsommer dot dk
Workaround is:
$opts = array(
'http'=array(
'user_agent' = 'foo'
)
);
$context = stream_context_create($opts);
$client = new SoapClient('http://www.example.com/', array('stream_context' =
$context));
[2012-01-25 20:55:06] mail at tomsommer dot dk
The receiving server only receive the following headers:
GET / HTTP/1.1
Host: www.example.com
Connection: close
Checked with tcpdump
[2012-01-25 20:45:55] mail at tomsommer dot dk
Description:
The SoapClient ignores the user_agent option, and sends no User-Agent at all.
Test script:
---
$client = new SoapClient('http://www.example.com/', array('user_agent' =
'foo'));
Expected result:
User-Agent header on the remote server
Actual result:
--
No User-Agent header on the remote server
--
Edit this bug report at https://bugs.php.net/bug.php?id=60887edit=1
Bug #60887 [Com]: SoapClient ignores user_agent option and sends no User-Agent header
Edit report at https://bugs.php.net/bug.php?id=60887edit=1
ID: 60887
Comment by: carloschilazo at gmail dot com
Reported by:mail at tomsommer dot dk
Summary:SoapClient ignores user_agent option and sends no
User-Agent header
Status: Open
Type: Bug
Package:SOAP related
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
Forgot to mention, I tested with 5.3.9 realeased version, and also with the
current snapshot
Previous Comments:
[2012-01-27 05:05:53] carloschilazo at gmail dot com
I could not reproduce your problem, using PHP 5.3.9 (linux) was able to send a
request with user_agent header set
I captured with WireShark could you please try to:
a) capture with another program (maybe)
b) make sure that on the other end , the user_agent is not being stripped
or provide more info
[2012-01-26 07:16:20] mail at tomsommer dot dk
Workaround is:
$opts = array(
'http'=array(
'user_agent' = 'foo'
)
);
$context = stream_context_create($opts);
$client = new SoapClient('http://www.example.com/', array('stream_context' =
$context));
[2012-01-25 20:55:06] mail at tomsommer dot dk
The receiving server only receive the following headers:
GET / HTTP/1.1
Host: www.example.com
Connection: close
Checked with tcpdump
[2012-01-25 20:45:55] mail at tomsommer dot dk
Description:
The SoapClient ignores the user_agent option, and sends no User-Agent at all.
Test script:
---
$client = new SoapClient('http://www.example.com/', array('user_agent' =
'foo'));
Expected result:
User-Agent header on the remote server
Actual result:
--
No User-Agent header on the remote server
--
Edit this bug report at https://bugs.php.net/bug.php?id=60887edit=1
Bug #60704 [Com]: unlink() bug with some files path
Edit report at https://bugs.php.net/bug.php?id=60704edit=1
ID: 60704
Comment by: carloschilazo at gmail dot com
Reported by:dean at dacunha dot net
Summary:unlink() bug with some files path
Status: Open
Type: Bug
Package:Filesystem function related
Operating System: Linux 3.0.0-14-generic #23-Ubunt
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Does this happen also in 5.3.9 ?
Please confirm so I can look into it
Thanks
Previous Comments:
[2012-01-10 19:58:07] dean at dacunha dot net
Description:
unlink() function truncates the file path name argument in some cases.
This bug appears also with the rename() function in the same cases.
The given source code use link() to duplicate a file, then unlink() to remove
the
source file. link() function works and unlink() bugs.
Test script:
---
#!/usr/local/bin/php
?php
$Target=/mnt/M://BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot
List.mp3;
$Link=/mnt/M:/NEWBASE/BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot
List.1.2.mp3;
link($Target,$Link);
unlink($Target);
?
Expected result:
unlink() should remove the /mnt/M://BRASIL/Carlinhos Brown/Alfagamabetizado -
Angel's Robot List.mp3 file
Actual result:
--
root@djavanubu:/# ./b.php
Warning: unlink(BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot
List.mp3): No such file or directory in /b.php on line 8
###
below trace shows the truncated file path given to unlink() syscall:
[...]
lstat(/mnt/M://BRASIL, {st_mode=S_IFDIR|0755, st_size=69632, ...}) = 0
link(/mnt/M://BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot
List.mp3, /mnt/M:/NEWBASE/BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's
Robot List.1.2.mp3) = 0
unlink(BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot List.mp3) = -1
ENOENT (No such file or directory)
write(1, \nWarning: unlink(BRASIL/Carlinho..., 130
Warning: unlink(BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot
List.mp3): No such file or directory in /b.php on line 8
) = 130
[...]
--
Edit this bug report at https://bugs.php.net/bug.php?id=60704edit=1
Bug #60756 [Bgs]: Unable to upgrade
Edit report at https://bugs.php.net/bug.php?id=60756edit=1 ID: 60756 User updated by:lucien_sabre at yahoo dot it Reported by:lucien_sabre at yahoo dot it Summary:Unable to upgrade Status: Bogus Type: Bug Package:*General Issues Operating System: Windows7 32Bit PHP Version:Irrelevant Block user comment: N Private report: N New Comment: I'll be sure not to disturb you, pajoye, as you woke up on the wrong side of the bed. Previous Comments: [2012-01-26 08:58:14] paj...@php.net This is not a support channel. Please use the php-install or the php-windows mailing list to ask further support. [2012-01-26 08:00:55] lucien_sabre at yahoo dot it Microsoft Installers don't have the right-click --- Run as Administrator option, it just says INSTALL. And I have no idea of what is windows UAC [2012-01-25 17:41:18] carloschilazo at gmail dot com Try installing as an administrator (right click the installer, run as administrator) or disable windows UAC [2012-01-18 07:53:41] lucien_sabre at yahoo dot it So, what do I do? [2012-01-17 19:59:46] anon at anon dot anon It's not moronic to be a beginner, it's moronic to not just try it and learn by experimentation. 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=60756 -- Edit this bug report at https://bugs.php.net/bug.php?id=60756edit=1
