Bug #64334 [Com]: bindParam() does not requre colon for parameter
Edit report at https://bugs.php.net/bug.php?id=64334edit=1 ID: 64334 Comment by: jellofishi at gmail dot com Reported by:shri dot amin at gmail dot com Summary:bindParam() does not requre colon for parameter Status: Open Type: Bug Package:PDO related Operating System: all PHP Version:5.3.22 Block user comment: N Private report: N New Comment: Why is this a bug ? if the functionality works, shouldn't the documentation be updated ? Previous Comments: [2013-03-02 00:19:39] shri dot amin at gmail dot com Description: the bindParam($param, $var) PDO function does not require the colon(:) for the param. Test script: --- $stmt = $dbh-prepare(INSERT INTO foo VALUES (:email, :password)); $stmt-bindParam('email', $_POST['email']); //this works, but shouldn't $stmt-bindParam('password', $_POST['password']); //this works, but shouldn't Expected result: obviously the first param of bindParam() should require the colon(:) Actual result: -- the first param of bindParam() does not require the colon(:) -- Edit this bug report at https://bugs.php.net/bug.php?id=64334edit=1
[PHP-BUG] Bug #64337 [NEW]: Static properties overwritten by children
From: nat at nath dot is Operating system: OSX PHP version: Irrelevant Package: *General Issues Bug Type: Bug Bug description:Static properties overwritten by children Description: If you extend a class, which has a static property, and set that static property, it will overwrite the variable in the parent, not in the child. Test script: --- ?php class One { public static $var = 'hi'; } class Two extends One { public static function set($var) { static::$var = $var; } } Two::set('bye'); var_dump(One::$var); Expected result: hi Actual result: -- bye -- Edit bug report at https://bugs.php.net/bug.php?id=64337edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64337r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64337r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64337r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64337r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64337r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64337r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64337r=needscript Try newer version: https://bugs.php.net/fix.php?id=64337r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64337r=support Expected behavior: https://bugs.php.net/fix.php?id=64337r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64337r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64337r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64337r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64337r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64337r=dst IIS Stability: https://bugs.php.net/fix.php?id=64337r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64337r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64337r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64337r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64337r=mysqlcfg
Bug #63521 [Com]: Adding 5 weekdays to Fri, Sat or Sun results in Sunday
Edit report at https://bugs.php.net/bug.php?id=63521edit=1 ID: 63521 Comment by: payden at paydensutherland dot com Reported by:linesarefuzzy at gmail dot com Summary:Adding 5 weekdays to Fri, Sat or Sun results in Sunday Status: Open Type: Bug Package:Date/time related Operating System: Mac, Linux PHP Version:5.3.18 Block user comment: N Private report: N New Comment: This has been fixed (some time ago, Jul 29, in git). It's currently in the latest 5.5-dev. It's not currently in latest 5.4, but I guess it should probably make it there sometime. Previous Comments: [2012-12-28 10:42:37] michal dot kocztorz at polcode dot pl Seems to affect DateTime::modify too. $dt = new DateTime(2013-01-04); echo $dt-modify(+5 weekdays)-format(Y-m-d H:i:s l) . br/; $dt = new DateTime(2013-01-05); echo $dt-modify(+5 weekdays)-format(Y-m-d H:i:s l) . br/; $dt = new DateTime(2013-01-06); echo $dt-modify(+5 weekdays)-format(Y-m-d H:i:s l) . br/; $dt = new DateTime(2013-01-07); echo $dt-modify(+5 weekdays)-format(Y-m-d H:i:s l) . br/; Got: 2013-01-13 00:00:00 Sunday 2013-01-13 00:00:00 Sunday 2013-01-13 00:00:00 Sunday 2013-01-14 00:00:00 Monday [2012-11-23 02:58:58] linesarefuzzy at gmail dot com Jon-- Since the bug always results in Sunday when it should be Friday, an obvious workaround would be to test the weekday of the result, and if it's Sunday, subtract two days. For example: ?php if (date('l', $timestamp) == 'Sunday') $timestamp = strtotime(date('Y-m-d', $timestamp) . ' - 2 days'); ? [2012-11-22 08:33:11] jon dot drummond at barrowsonline dot com Has anyone found a solution to this yet? We can not wait for a patch need a workaround in the mean time. [2012-11-14 19:00:22] linesarefuzzy at gmail dot com Description: Adding 5 weekdays to a Friday, Saturday or Sunday returns the following Sunday instead of Friday. Same issue when adding multiples of 5. Starting with any other weekday works as expected, as does adding any other number of weekdays. Test script: --- echo date ( 'l, F j, Y', strtotime ( 'friday + 1 weekdays' ) ) . \n; echo date ( 'l, F j, Y', strtotime ( 'friday + 2 weekdays' ) ) . \n; echo date ( 'l, F j, Y', strtotime ( 'friday + 3 weekdays' ) ) . \n; echo date ( 'l, F j, Y', strtotime ( 'friday + 4 weekdays' ) ) . \n; echo date ( 'l, F j, Y', strtotime ( 'friday + 5 weekdays' ) ) . \n; echo \n; echo date ( 'l, F j, Y', strtotime ( 'saturday + 1 weekdays' ) ) . \n; echo date ( 'l, F j, Y', strtotime ( 'saturday + 2 weekdays' ) ) . \n; echo date ( 'l, F j, Y', strtotime ( 'saturday + 3 weekdays' ) ) . \n; echo date ( 'l, F j, Y', strtotime ( 'saturday + 4 weekdays' ) ) . \n; echo date ( 'l, F j, Y', strtotime ( 'saturday + 5 weekdays' ) ) . \n; echo \n; echo date ( 'l, F j, Y', strtotime ( 'sunday + 1 weekdays' ) ) . \n; echo date ( 'l, F j, Y', strtotime ( 'sunday + 2 weekdays' ) ) . \n; echo date ( 'l, F j, Y', strtotime ( 'sunday + 3 weekdays' ) ) . \n; echo date ( 'l, F j, Y', strtotime ( 'sunday + 4 weekdays' ) ) . \n; echo date ( 'l, F j, Y', strtotime ( 'sunday + 5 weekdays' ) ) . \n; Expected result: Monday, November 19, 2012 Tuesday, November 20, 2012 Wednesday, November 21, 2012 Thursday, November 22, 2012 Friday, November 23, 2012 Monday, November 19, 2012 Tuesday, November 20, 2012 Wednesday, November 21, 2012 Thursday, November 22, 2012 Friday, November 23, 2012 Monday, November 19, 2012 Tuesday, November 20, 2012 Wednesday, November 21, 2012 Thursday, November 22, 2012 Friday, November 23, 2012 Actual result: -- Monday, November 19, 2012 Tuesday, November 20, 2012 Wednesday, November 21, 2012 Thursday, November 22, 2012 Sunday, November 25, 2012 Monday, November 19, 2012 Tuesday, November 20, 2012 Wednesday, November 21, 2012 Thursday, November 22, 2012 Sunday, November 25, 2012 Monday, November 19, 2012 Tuesday, November 20, 2012 Wednesday, November 21, 2012 Thursday, November 22, 2012 Sunday, November 25, 2012 -- Edit this bug report at https://bugs.php.net/bug.php?id=63521edit=1
Bug #64337 [Opn-Nab]: Static properties overwritten by children
Edit report at https://bugs.php.net/bug.php?id=64337edit=1 ID: 64337 Updated by: larue...@php.net Reported by:nat at nath dot is Summary:Static properties overwritten by children -Status: Open +Status: Not a bug Type: Bug Package:*General Issues Operating System: OSX PHP Version:Irrelevant 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 if you want a new copy of static variable in sub-class = redeclare it. not bug here. Previous Comments: [2013-03-02 13:02:11] nat at nath dot is Description: If you extend a class, which has a static property, and set that static property, it will overwrite the variable in the parent, not in the child. Test script: --- ?php class One { public static $var = 'hi'; } class Two extends One { public static function set($var) { static::$var = $var; } } Two::set('bye'); var_dump(One::$var); Expected result: hi Actual result: -- bye -- Edit this bug report at https://bugs.php.net/bug.php?id=64337edit=1
[PHP-BUG] Bug #64338 [NEW]: pdo_dblib can't connect to Azure SQL
From: mah at everybody dot org Operating system: any PHP version: 5.5.0alpha5 Package: MSSQL related Bug Type: Bug Bug description:pdo_dblib can't connect to Azure SQL Description: The SQL database available on Azure apparently does not have the same connection semantics as SQL Server. âuse DATABASEâ is not possible â it returns an error saying that you should open a new connection if you want a new database. This is confusing when you are using the DBLIB connector because it is the DBLIB connection code that does the âuseâ, not the developer's PHP code. The FreeTDS people recognized this a while back: About a year ago we added the DBSETLDBNAME macro as a way to set the dbname in the db-lib LOGINREC. That sets the dbname in the login packet, obviating the need for USE dbname. http://lists.ibiblio.org/pipermail/freetds/2012q4/028168.html The attached patch makes use of DBSETLDBNAME and eliminates the USE. Test script: --- ?php try { $server = SERVER.database.windows.net:1433; $username = USER@SERVER; $password = PASSWORD; $dbname = DBNAME; $mssql = new PDO(dblib:host=$server;dbname=$dbname,$username,$password); echo Success!\n; } catch ( PDOException $e ) { print( Error connecting to SQL Server. ); die(print_r($e)); } -- Edit bug report at https://bugs.php.net/bug.php?id=64338edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64338r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64338r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64338r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64338r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64338r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64338r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64338r=needscript Try newer version: https://bugs.php.net/fix.php?id=64338r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64338r=support Expected behavior: https://bugs.php.net/fix.php?id=64338r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64338r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64338r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64338r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64338r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64338r=dst IIS Stability: https://bugs.php.net/fix.php?id=64338r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64338r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64338r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64338r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64338r=mysqlcfg
Bug #64338 [Com]: pdo_dblib can't connect to Azure SQL
Edit report at https://bugs.php.net/bug.php?id=64338edit=1 ID: 64338 Comment by: mah at everybody dot org Reported by:mah at everybody dot org Summary:pdo_dblib can't connect to Azure SQL Status: Open Type: Bug Package:MSSQL related Operating System: any PHP Version:5.5.0alpha5 Block user comment: N Private report: N New Comment: Originally reported to Debian: http://bugs.debian.org/702079 Previous Comments: [2013-03-02 15:29:43] mah at everybody dot org Description: The SQL database available on Azure apparently does not have the same connection semantics as SQL Server. âuse DATABASEâ is not possible â it returns an error saying that you should open a new connection if you want a new database. This is confusing when you are using the DBLIB connector because it is the DBLIB connection code that does the âuseâ, not the developer's PHP code. The FreeTDS people recognized this a while back: About a year ago we added the DBSETLDBNAME macro as a way to set the dbname in the db-lib LOGINREC. That sets the dbname in the login packet, obviating the need for USE dbname. http://lists.ibiblio.org/pipermail/freetds/2012q4/028168.html The attached patch makes use of DBSETLDBNAME and eliminates the USE. Test script: --- ?php try { $server = SERVER.database.windows.net:1433; $username = USER@SERVER; $password = PASSWORD; $dbname = DBNAME; $mssql = new PDO(dblib:host=$server;dbname=$dbname,$username,$password); echo Success!\n; } catch ( PDOException $e ) { print( Error connecting to SQL Server. ); die(print_r($e)); } -- Edit this bug report at https://bugs.php.net/bug.php?id=64338edit=1
Bug #64338 [Opn-Fbk]: pdo_dblib can't connect to Azure SQL
Edit report at https://bugs.php.net/bug.php?id=64338edit=1 ID: 64338 Updated by: paj...@php.net Reported by:mah at everybody dot org Summary:pdo_dblib can't connect to Azure SQL -Status: Open +Status: Feedback Type: Bug Package:MSSQL related Operating System: any PHP Version:5.5.0alpha5 Block user comment: N Private report: N New Comment: I suppose you are on Linux as dblib is not supported anymore on windows since quite a while. If you are on win usw sqlsrv, works out of the box. Previous Comments: [2013-03-02 15:57:16] mah at everybody dot org Originally reported to Debian: http://bugs.debian.org/702079 [2013-03-02 15:29:43] mah at everybody dot org Description: The SQL database available on Azure apparently does not have the same connection semantics as SQL Server. âuse DATABASEâ is not possible â it returns an error saying that you should open a new connection if you want a new database. This is confusing when you are using the DBLIB connector because it is the DBLIB connection code that does the âuseâ, not the developer's PHP code. The FreeTDS people recognized this a while back: About a year ago we added the DBSETLDBNAME macro as a way to set the dbname in the db-lib LOGINREC. That sets the dbname in the login packet, obviating the need for USE dbname. http://lists.ibiblio.org/pipermail/freetds/2012q4/028168.html The attached patch makes use of DBSETLDBNAME and eliminates the USE. Test script: --- ?php try { $server = SERVER.database.windows.net:1433; $username = USER@SERVER; $password = PASSWORD; $dbname = DBNAME; $mssql = new PDO(dblib:host=$server;dbname=$dbname,$username,$password); echo Success!\n; } catch ( PDOException $e ) { print( Error connecting to SQL Server. ); die(print_r($e)); } -- Edit this bug report at https://bugs.php.net/bug.php?id=64338edit=1
Bug #64334 [Opn-Csd]: bindParam() does not requre colon for parameter
Edit report at https://bugs.php.net/bug.php?id=64334edit=1 ID: 64334 User updated by:shri dot amin at gmail dot com Reported by:shri dot amin at gmail dot com Summary:bindParam() does not requre colon for parameter -Status: Open +Status: Closed Type: Bug Package:PDO related Operating System: all PHP Version:5.3.22 Block user comment: N Private report: N New Comment: ok fine close out Previous Comments: [2013-03-02 08:35:58] jellofishi at gmail dot com Why is this a bug ? if the functionality works, shouldn't the documentation be updated ? [2013-03-02 00:19:39] shri dot amin at gmail dot com Description: the bindParam($param, $var) PDO function does not require the colon(:) for the param. Test script: --- $stmt = $dbh-prepare(INSERT INTO foo VALUES (:email, :password)); $stmt-bindParam('email', $_POST['email']); //this works, but shouldn't $stmt-bindParam('password', $_POST['password']); //this works, but shouldn't Expected result: obviously the first param of bindParam() should require the colon(:) Actual result: -- the first param of bindParam() does not require the colon(:) -- Edit this bug report at https://bugs.php.net/bug.php?id=64334edit=1
Bug #64338 [Fbk]: pdo_dblib can't connect to Azure SQL
Edit report at https://bugs.php.net/bug.php?id=64338edit=1 ID: 64338 Updated by: paj...@php.net Reported by:mah at everybody dot org Summary:pdo_dblib can't connect to Azure SQL Status: Feedback Type: Bug Package:MSSQL related Operating System: any PHP Version:5.5.0alpha5 Block user comment: N Private report: N New Comment: btw, DBSETLDBNAME could be easily added in pdo_dblib_handle_factory (ext/pdo_dblib/dblib_driver.c). Can you test it pls? if you could create a patch and test it, even better :) Previous Comments: [2013-03-02 16:56:05] paj...@php.net I suppose you are on Linux as dblib is not supported anymore on windows since quite a while. If you are on win usw sqlsrv, works out of the box. [2013-03-02 15:57:16] mah at everybody dot org Originally reported to Debian: http://bugs.debian.org/702079 [2013-03-02 15:29:43] mah at everybody dot org Description: The SQL database available on Azure apparently does not have the same connection semantics as SQL Server. âuse DATABASEâ is not possible â it returns an error saying that you should open a new connection if you want a new database. This is confusing when you are using the DBLIB connector because it is the DBLIB connection code that does the âuseâ, not the developer's PHP code. The FreeTDS people recognized this a while back: About a year ago we added the DBSETLDBNAME macro as a way to set the dbname in the db-lib LOGINREC. That sets the dbname in the login packet, obviating the need for USE dbname. http://lists.ibiblio.org/pipermail/freetds/2012q4/028168.html The attached patch makes use of DBSETLDBNAME and eliminates the USE. Test script: --- ?php try { $server = SERVER.database.windows.net:1433; $username = USER@SERVER; $password = PASSWORD; $dbname = DBNAME; $mssql = new PDO(dblib:host=$server;dbname=$dbname,$username,$password); echo Success!\n; } catch ( PDOException $e ) { print( Error connecting to SQL Server. ); die(print_r($e)); } -- Edit this bug report at https://bugs.php.net/bug.php?id=64338edit=1
Doc-Bug #64173 [Fbk-Opn]: filter_var filter_validate_url incorrect
Edit report at https://bugs.php.net/bug.php?id=64173edit=1 ID: 64173 User updated by:retze dot faber at gmail dot com Reported by:retze dot faber at gmail dot com Summary:filter_var filter_validate_url incorrect -Status: Feedback +Status: Open -Type: Documentation Problem +Type: Bug Package:Filter related Operating System: debian squeeze PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Changed to bug, cause I feel it should return false when I call it with http://http://www.google.com Previous Comments: [2013-03-02 14:30:45] sala...@php.net I don't see this as a documentation bug. This filter effectively just calls parse_url() on the value and looks to see if the resulting array makes some sense. Running http://http://www.google.com; through parse_url() gives an array like array('scheme' = 'http', 'host' = 'http', 'path' = '//www.google.com'). If you feel this is a bug in the filter, please change the Bug Type to bug. If you feel this is not a bug in the implementation, rather still a documentation problem then could you elaborate on what details you would like to be added or changed? A final option is to close off this report if you decide that this behaviour is now to be expected and there is no issue. Let us know what you think. [2013-02-08 09:03:52] retze dot faber at gmail dot com Description: --- From manual page: http://www.php.net/function.filter-var --- http://http://www.google.com passes filter_var with FILTER_VALIDATE_URL Test script: --- $url = $_REQUEST['url']; if (filter_var(http://; . $url, FILTER_VALIDATE_URL)) $filter=true; else $filter=false; echo Filter var result of concat with http is: . $filter . br; Expected result: I expect it to return false when i run the script with http://www.google.com and true when i run it with www.google.com Actual result: -- It returns true in both cases -- Edit this bug report at https://bugs.php.net/bug.php?id=64173edit=1
[PHP-BUG] Bug #64340 [NEW]: sockets tests failed
From: reeze Operating system: Mac OSX 10.8 PHP version: 5.5.0alpha5 Package: Sockets related Bug Type: Bug Bug description:sockets tests failed Description: Failed tests: Multicast support: IPv6 send options [ext/sockets/tests/mcast_ipv6_send.phpt] recvmsg(): receive SCM_CREDENTIALS messages [ext/sockets/tests/socket_cmsg_rights.phpt] recvmsg(): basic test [ext/sockets/tests/socket_recvmsg.phpt] sendmsg()/recvmsg(): test ability to receive multiple messages [ext/sockets/tests/socket_sendrecvmsg_multi_msg.phpt] Test if socket_recvfrom() receives data sent by socket_sendto() via IPv4 UDP [ext/sockets/tests/socket_sentto_recvfrom_ipv4_udp.phpt] socket_set_option() with IPV6_PKTINFO [ext/sockets/tests/socket_set_option_in6_pktinfo.phpt]\ diff: == ext/sockets/tests/mcast_ipv6_send.diff == 013+ 014+ Warning: socket_set_option(): unable to set socket option [49]: Can't assign requested address in /Users/reeze/Opensource/php-test/php-src- master/ext/sockets/tests/mcast_ipv6_send.php on line 26 015+ bool(false) 013- bool(true) == ext/sockets/tests/socket_cmsg_rights.diff == 014+ int(24) 014- int(32) 018+ [name] = Array 019+ ( 020+ [family] = 1 021+ [path] = 022+ ) 023+ 018- [name] = == ext/sockets/tests/socket_recvmsg.diff == 007+ 008+ Notice: Use of undefined constant IPV6_RECVPKTINFO - assumed 'IPV6_RECVPKTINFO' in /Users/reeze/Opensource/php- test/php-src-master/ext/sockets/tests/socket_recvmsg.php on line 18 009+ 010+ Warning: socket_set_option() expects parameter 3 to be long, string given in /Users/reeze/Opensource/php- test/php-src-master/ext/sockets/tests/socket_recvmsg.php on line 18 011+ err 007- int(14) 008- Array 009- ( 010- [name] = Array 011- ( 012- [family] = %d 013- [addr] = ::1 014- [port] = 7001 015- [flowinfo] = 0 016- [scope_id] = 0 017- ) 018- 019- [control] = Array 020- ( 021- [0] = Array 022- ( 023- [level] = %d 024- [type] = %d 025- [data] = Array 026- ( 027- [addr] = ::1 028- [ifindex] = %d 029- ) 030- 031- ) 032- 033- ) 034- 035- [iov] = Array 036- ( 037- [0] = testing packet 038- ) 039- 040- [flags] = 0 041- ) == ext/sockets/tests/socket_sendrecvmsg_multi_msg.diff == 007+ 008+ Notice: Use of undefined constant IPV6_RECVPKTINFO - assumed 'IPV6_RECVPKTINFO' in /Users/reeze/Opensource/php- test/php-src-master/ext/sockets/tests/socket_sendrecvmsg_multi_msg.php on line 18 009+ 010+ Warning: socket_set_option() expects parameter 3 to be long, string given in /Users/reeze/Opensource/php- test/php-src-master/ext/sockets/tests/socket_sendrecvmsg_multi_msg.php on line 18 011+ err 007- int(11) 008- Array 009- ( 010- [name] = Array 011- ( 012- [family] = %d 013- [addr] = ::1 014- [port] = 7001 015- [flowinfo] = 0 016- [scope_id] = 0 017- ) 018- 019- [control] = Array 020- ( 021- [0] = Array 022- ( 023- [level] = %d 024- [type] = %d 025- [data] = Array 026- ( 027- [addr] = ::1 028- [ifindex] = %d 029- ) 030- 031- ) 032- 033- [1] = Array 034- ( 035- [level] = %d 036- [type] = %d 037- [data] = 40 038- ) 039- 040- ) 041- 042- [iov] = Array 043- ( 044- [0] = test thing 045- 046- ) 047- 048- [flags] = 0 049- ) == ext/sockets/tests/socket_sentto_recvfrom_ipv4_udp.diff == 007+ bytes have been received instead of the 5 bytes expected 007- Received Ping! from remote address 127.0.0.1 and remote port 1223 == ext/sockets/tests/socket_set_option_in6_pktinfo.diff == 001+ Notice: Use of undefined constant IPV6_PKTINFO - assumed 'IPV6_PKTINFO' in /Users/reeze/Opensource/php-test/php- src-master/ext/sockets/tests/socket_set_option_in6_pktinfo.php on line 4 002+ 003+ Warning: socket_set_option() expects parameter 3 to be long, string given in /Users/reeze/Opensource/php- test/php-src-master/ext/sockets/tests/socket_set_option_in6_pktinfo.php on line 4 001- Warning: socket_set_option(): error converting user data (path: in6_pktinfo): The key 'addr' is required in %s on line %d 002- bool(false) 003- bool(true) 004+ NULL 005+ 006+ Notice: Use of undefined constant IPV6_PKTINFO - assumed 'IPV6_PKTINFO' in /Users/reeze/Opensource/php-test/php-
Bug #64340 [PATCH]: sockets tests failed
Edit report at https://bugs.php.net/bug.php?id=64340edit=1 ID: 64340 Patch added by: re...@php.net Reported by:re...@php.net Summary:sockets tests failed Status: Open Type: Bug Package:Sockets related Operating System: Mac OSX 10.8 PHP Version:5.5.0alpha5 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: ipv6-pktinfo-and-tiny-test-fix Revision: 1362247530 URL: https://bugs.php.net/patch-display.php?bug=64340patch=ipv6-pktinfo-and-tiny-test-fixrevision=1362247530 Previous Comments: [2013-03-02 18:05:22] re...@php.net Description: Failed tests: Multicast support: IPv6 send options [ext/sockets/tests/mcast_ipv6_send.phpt] recvmsg(): receive SCM_CREDENTIALS messages [ext/sockets/tests/socket_cmsg_rights.phpt] recvmsg(): basic test [ext/sockets/tests/socket_recvmsg.phpt] sendmsg()/recvmsg(): test ability to receive multiple messages [ext/sockets/tests/socket_sendrecvmsg_multi_msg.phpt] Test if socket_recvfrom() receives data sent by socket_sendto() via IPv4 UDP [ext/sockets/tests/socket_sentto_recvfrom_ipv4_udp.phpt] socket_set_option() with IPV6_PKTINFO [ext/sockets/tests/socket_set_option_in6_pktinfo.phpt]\ diff: == ext/sockets/tests/mcast_ipv6_send.diff == 013+ 014+ Warning: socket_set_option(): unable to set socket option [49]: Can't assign requested address in /Users/reeze/Opensource/php-test/php-src- master/ext/sockets/tests/mcast_ipv6_send.php on line 26 015+ bool(false) 013- bool(true) == ext/sockets/tests/socket_cmsg_rights.diff == 014+ int(24) 014- int(32) 018+ [name] = Array 019+ ( 020+ [family] = 1 021+ [path] = 022+ ) 023+ 018- [name] = == ext/sockets/tests/socket_recvmsg.diff == 007+ 008+ Notice: Use of undefined constant IPV6_RECVPKTINFO - assumed 'IPV6_RECVPKTINFO' in /Users/reeze/Opensource/php- test/php-src-master/ext/sockets/tests/socket_recvmsg.php on line 18 009+ 010+ Warning: socket_set_option() expects parameter 3 to be long, string given in /Users/reeze/Opensource/php- test/php-src-master/ext/sockets/tests/socket_recvmsg.php on line 18 011+ err 007- int(14) 008- Array 009- ( 010- [name] = Array 011- ( 012- [family] = %d 013- [addr] = ::1 014- [port] = 7001 015- [flowinfo] = 0 016- [scope_id] = 0 017- ) 018- 019- [control] = Array 020- ( 021- [0] = Array 022- ( 023- [level] = %d 024- [type] = %d 025- [data] = Array 026- ( 027- [addr] = ::1 028- [ifindex] = %d 029- ) 030- 031- ) 032- 033- ) 034- 035- [iov] = Array 036- ( 037- [0] = testing packet 038- ) 039- 040- [flags] = 0 041- ) == ext/sockets/tests/socket_sendrecvmsg_multi_msg.diff == 007+ 008+ Notice: Use of undefined constant IPV6_RECVPKTINFO - assumed 'IPV6_RECVPKTINFO' in /Users/reeze/Opensource/php- test/php-src-master/ext/sockets/tests/socket_sendrecvmsg_multi_msg.php on line 18 009+ 010+ Warning: socket_set_option() expects parameter 3 to be long, string given in /Users/reeze/Opensource/php- test/php-src-master/ext/sockets/tests/socket_sendrecvmsg_multi_msg.php on line 18 011+ err 007- int(11) 008- Array 009- ( 010- [name] = Array 011- ( 012- [family] = %d 013- [addr] = ::1 014- [port] = 7001 015- [flowinfo] = 0 016- [scope_id] = 0 017- ) 018- 019- [control] = Array 020- ( 021- [0] = Array 022- ( 023- [level] = %d 024- [type] = %d 025- [data] = Array 026- ( 027- [addr] = ::1 028- [ifindex] = %d 029- ) 030- 031- ) 032- 033- [1] = Array 034- ( 035- [level] = %d 036- [type] = %d 037- [data] = 40 038- ) 039- 040- ) 041- 042- [iov] = Array 043- ( 044- [0] = test thing 045- 046- ) 047- 048- [flags] = 0 049- ) == ext/sockets/tests/socket_sentto_recvfrom_ipv4_udp.diff == 007+ bytes have been received instead of the 5 bytes expected 007- Received Ping! from remote address 127.0.0.1 and remote port 1223 == ext/sockets/tests/socket_set_option_in6_pktinfo.diff == 001+ Notice: Use of undefined constant IPV6_PKTINFO - assumed 'IPV6_PKTINFO' in /Users/reeze/Opensource/php-test/php-
Bug-Req #54147 [Opn-Csd]: debug_backtrace increases memory usage
Edit report at https://bugs.php.net/bug.php?id=54147edit=1 ID: 54147 Updated by: dlsni...@php.net Reported by:jacob at jacobweber dot com Summary:debug_backtrace increases memory usage -Status: Open +Status: Closed -Type: Bug +Type: Feature/Change Request Package:Unknown/Other Function Operating System: Red Hat Linux PHP Version:5.2.17 -Assigned To: +Assigned To:dlsniper Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ This has been fixed as of PHP 5.3.6 Previous Comments: [2012-11-12 09:41:26] twin at nightmail dot ru As you suppose, in PHP 5.3.6 option for skip args was added. And for function debug_print_backtrace() too. [2011-03-03 03:58:43] jacob at jacobweber dot com Description: Calling debug_backtrace(false) can lead to a huge increase in memory usage, if it's called from within a function that was passed a huge string as an argument. This is because the string will be duplicated in the args field of the result. It would be nice to have another boolean argument to debug_backtrace, that would tell it to skip the args field. This would be similar to the one that skips the object field. Or could the arguments be returned as references, so they don't increase memory usage? Test script: --- function test($str) { echo before: .round(memory_get_usage()/1024/1024, 2). MB\n; debug_backtrace(false); echo after: .round(memory_get_usage()/1024/1024, 2). MB\n; } test(str_repeat('a', 1000)); Expected result: before: 9.59 MB after: 9.59 MB (This is what I get if I remove the debug_backtrace() call.) Actual result: -- before: 9.59 MB after: 19.12 MB -- Edit this bug report at https://bugs.php.net/bug.php?id=54147edit=1
Req #49526 [Com]: C# style property get/set syntax
Edit report at https://bugs.php.net/bug.php?id=49526edit=1 ID: 49526 Comment by: re...@php.net Reported by:president at basnetworks dot net Summary:C# style property get/set syntax Status: Open Type: Feature/Change Request Package:Scripting Engine problem Operating System: * PHP Version:* Block user comment: N Private report: N New Comment: @see https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 this RFC failed to win the vote sadly. Previous Comments: [2013-01-09 01:36:22] anka17pinky at yahoo dot com I wish this request was implemented in PHP 5.5 :( There are so many questions on SO asking for ways to implement readonly properties in PHP... [2012-01-28 01:45:53] phpdev at zerocue dot com An as implemented document has been created here: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented Only thing remaining to be implemented is static accessors. [2010-10-28 00:48:47] rayro at gmx dot de I also recommend this but i have a little idea too: 1. Most of the time i use getVariableName() syntax and I have to write new functions for that (or using __call or __set), because i protect the properties with private or protected to protect for writing them. 2. Most of all the code is ugly or has limitations using readonly/writeonly properties with __get($v) or __set($v,$c) by reference. 3. It is not perfectly clean to write less code with __get or getter/setter if only want to protecting them... And less code matters! I would like to see a new, or 2 new keywords, e.g. readonly and writonly, because the code will look smoother and i dont have to make the use of magic methods... Or some own designed errors for that... Now an simple example: == ?php class A { /** the following syntax is just invented **/ static readable protected $foo = 1; static writable protected $bar = 2; } A::$foo++; // raises error variable is not writeable from this context echo(A::$foo); // will simple echo $foo A::$bar++; // will increment $bar to 3 echo(A::$bar); // raises error variable is not readable from this context ? ( what about is_readable() or is_writable() for that? ) I dont think that these functions will be used, so only Reflection should be extended... and now, instead of the current syntax: == ?php class A { static protected $foo = 1; static protected $bar = 1; function __get($v) { if ($v == 'bar') { trigger_error('$bar is not readble from this context',E_USER_ERROR); } return $this-$v; } function __set($v, $c) { if ($v == 'foo') { trigger_error('$foo is not writable from this context',E_USER_ERROR); } $this-$v = $c; return true; } } ? get/set syntax will be nice but also nasty if only read/writablity is desired... this can be confusing as this: == ?php class A { /** the following syntax is just invented **/ static protected $foo { function __get() { return $this-foo; } function __set() { trigger_error('$foo is not writable from this context',E_USER_ERROR); } } = 1; static protected $bar { function __get() { trigger_error('$bar is not readable from this context',E_USER_ERROR); } function __set() { $this-bar = 1; return true; } } = 2; } ? think about it... many developers will waive the old way or functions like getVarname and setVarname... and for all other, getter/setter will be nice as described in the rfc... [2009-09-13 19:56:24] president at basnetworks dot net For reference, the RFC for this feature request now exists at this URL: http://wiki.php.net/rfc/propertygetsetsyntax [2009-09-13 04:24:08] president at basnetworks dot net Hi Kalle, Thanks for the information. I will follow your instructions and start working on the RFC over the next week(s). Also, thanks for the link about the Developer Summit, but it does not show the outcome of the discussion, am I able to find that anywhere? 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=49526 -- Edit this bug report at https://bugs.php.net/bug.php?id=49526edit=1
Req #38379 [Opn-Csd]: mail() returns false when using 5th parameter in safe mode (even when empty)
Edit report at https://bugs.php.net/bug.php?id=38379edit=1 ID: 38379 Updated by: re...@php.net Reported by:marekm at apnet dot pl Summary:mail() returns false when using 5th parameter in safe mode (even when empty) -Status: Open +Status: Closed Type: Feature/Change Request Package:Mail related Operating System: All PHP Version:4.4.3 -Assigned To: +Assigned To:reeze Block user comment: N Private report: N New Comment: Safe mode was gone. Previous Comments: [2006-08-08 10:37:26] marekm at apnet dot pl Description: I think, mail() function with 5 parameters should work in safe mode when additional_parameters is an empty string. Reproduce code: --- mail(someb...@somewhere.com,subject,body,,); Expected result: The functions should work in safe mode. Actual result: -- The function returns false in safe mode. -- Edit this bug report at https://bugs.php.net/bug.php?id=38379edit=1
Req #32701 [Opn-Csd]: Safe-mode popen(): escaping problem
Edit report at https://bugs.php.net/bug.php?id=32701edit=1 ID: 32701 Updated by: re...@php.net Reported by:kosmo at miechow dot com Summary:Safe-mode popen(): escaping problem -Status: Open +Status: Closed Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: Linux PHP Version:5.0.4 -Assigned To: +Assigned To:reeze Block user comment: N Private report: N New Comment: Safe mode was gone. Previous Comments: [2005-11-13 02:31:42] 5Wupdd51ogZj7Lm8B at anime dot net Is there any link to more detailed info about safe_mode going away, and how php is handling security in the next release? [2005-11-09 12:57:50] sni...@php.net It's still not bug but a change request. Reclassified. You can provide a patch if you wish. The fact is that we're going to remove the whole safe-mode anyway, so you're basically wasting your time. This is not the only thing that goes wrong with it.. [2005-11-09 12:09:52] vr...@php.net It works bad. There's no way to echo '-= Test =-' in safe_mode. No characters inside single quotes should be escaped by php_escape_shell_cmd() as they have no special meaning. I can prepare a patch for it if it will be accepted. [2005-04-14 09:51:57] sni...@php.net This is how it works. No bug here. [2005-04-14 09:22:15] kosmo at miechow dot com Description: In safe-mode popen() is escaping command line by calling php_escape_shell_cmd(). This funcion escaping command line, and changing valid command arguments. IMHO there should be any way to disable this escaping and run in safe-mode. Reproduce code: --- ?php $r = popen(echo '-= Test =-', r); print(stream_get_contents($r)); pclose($r); ? Expected result: -= Test =- Actual result: -- -=\ Test \=- -- Edit this bug report at https://bugs.php.net/bug.php?id=32701edit=1
Req #18332 [Opn-Csd]: is_readable/is_writable/is_executable support under safe mode
Edit report at https://bugs.php.net/bug.php?id=18332edit=1 ID: 18332 Updated by: re...@php.net Reported by:ilia at prohost dot org Summary:is_readable/is_writable/is_executable support under safe mode -Status: Open +Status: Closed Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: any PHP Version:4.2.1 -Assigned To: +Assigned To:reeze Block user comment: N Private report: N New Comment: Safe mode was gone. Previous Comments: [2002-09-24 21:55:46] ekilf...@php.net I recently ran into this same problem. With the open_basedir config option set, is_readable() can report unexpected results. Perhaps a solution may be to run through all of the security checks that fopen goes through and find out if the file is readable. Another solution would be to actually just flat out open the file with php_fopen() for read or append (for is_writable()) and see what is returned. Perhaps an argument can be added such as: is_readable(STRICT) where STRICT checks everything is_readable(STRICT | ATTEMPT) would actually attempt the open. I'm just throwing out ideas. My problem is that I would like a way to guarantee that no errors or warnings are returned by a call to fopen() with the E_ALL error level set. I was using: file_exists() is_readable() I can't think of any check to perform other than writing a function in my script that does a safe open such as: function is_truly_readable() { $e = error_reporting(0); if ($f = fopen($file, r)) { fclose($f); error_reporting($e); return(TRUE); } error_reporting($e); return(FALSE); } [2002-09-22 16:37:38] il...@php.net In the current release of the manual is_readable/is_writable now mention the fact that they will not check safe_mode limitation. The is_executable however, still needs to be documented. [2002-07-15 21:52:19] yohg...@php.net I think stat function can be used to know actual permissions. is_* function supposed to return if current process can do something or not. IMO. We may need to change doc a bit. - Documentation Problem [2002-07-13 18:31:32] ilia at prohost dot org It would be very useful if is_readable/is_writable/is_executable series of functions would work with safe mode. Currently is_writable() will report a file that in reality cannot be accessed undersafe mode is writeable, which is clearly misleading. At least, could the manual be modified in such a way as to document that those functions will not work properly under safe_mode. -- Edit this bug report at https://bugs.php.net/bug.php?id=18332edit=1
Req #51507 [Opn-Csd]: Setting filename for @... multipart uploads
Edit report at https://bugs.php.net/bug.php?id=51507edit=1 ID: 51507 Updated by: re...@php.net Reported by:david at frankieandshadow dot com Summary:Setting filename for @... multipart uploads -Status: Open +Status: Closed Type: Feature/Change Request Package:cURL related Operating System: n/a PHP Version:5.2.13 -Assigned To: +Assigned To:reeze Block user comment: N Private report: N New Comment: As pierrick said, implemented. close Previous Comments: [2011-11-22 09:20:01] pierr...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. This functionality is implemented but you need to remove the space beetween the ; and the filename. You can even put the type : curl_setopt(CURLOPT_POSTFIELDS, array('myfile'=@{$pathname};type=image/jpeg; filename=name.jpg)); [2010-04-08 11:47:10] david at frankieandshadow dot com Description: Using curl_setopt, you can make a multipart POST by passing an array of parameters, and if preceded by an @, a file upload is created from the path following the @. curl_setopt(CURLOPT_POSTFIELDS, array('myfile'=@{$pathname})); However, I haven't been able to find a way to set the filename part of the multipart description, so that it generates e.g. Content-disposition: form-data; name=myfile; filename=desiredfilename Content-Type: text/plain That is, there isn't a way to get desiredfilename in there. The only option seems to be for the filename part appears to come from the name of the file within the path. The cURL command line interface seems to support explicitly setting the filename different from the name of the source file with '-F @path ; filename=whatever' so presumably it is possible in the library, but not exposed through the PHP binding. In case it was merely passing on the string to the cURL library verbatim, I tried: curl_setopt(CURLOPT_POSTFIELDS, array('myfile'=@{$pathname}; filename=\desiredfilename\)); but that gives an error. The problem is that the files I have are stored with simple numeric names and the file names which an external user would know them by are in the database that indexes the disk files. I have a workround which is to make a temporary hard link to the file by its user name and give that to cURL, but I don't think I should really need to do that. Test script: --- $now = time(); $tmpdirpath = /tmp/enspub-{$now}-{$version-id}; mkdir($tmpdirpath); $tmpfilepath = {$tmpdirpath}/ . mb_ereg_replace('[/?%*:|@~=+]', '_', $version-name); // replace disallowed characters link($version-pathname(), $tmpfilepath); $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE); curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE); /* tell me, not echo */ curl_setopt($ch, CURLOPT_POST, TRUE); $post['file'] = @{$tmpfilepath}; /* ... and other $post settings ... */ curl_setopt($ch, CURLOPT_POSTFIELDS, $post); $data = curl_exec($ch); /* ... error checking ... */ curl_close($ch); @unlink($tmpfilepath); @rmdir($tmpdirpath); Expected result: It works, but I'd like to be able to set the filename explicitly without copying the file. Actual result: -- n/a -- Edit this bug report at https://bugs.php.net/bug.php?id=51507edit=1
Bug #55867 [Opn-Fbk]: segfault while declaring function
Edit report at https://bugs.php.net/bug.php?id=55867edit=1 ID: 55867 Updated by: re...@php.net Reported by:savetheinternet at omegasdg dot com Summary:segfault while declaring function -Status: Open +Status: Feedback Type: Bug Package:Unknown/Other Function Operating System: Debian 2.6.26-26lenny3 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2012-04-20 10:19:48] vnsavage at gmail dot com Do you still get this? What is your PHP setup? Configuration parameters and modules? Do you use APC? [2011-10-10 18:16:38] goingbackayear at hotmail dot com I'll tell you what's wrong with the code STI when you ban Lazare and all the other Paulberg spammers. [2011-10-08 08:33:35] savetheinternet at omegasdg dot com Well, the file that short extract is from is quite a large file. It is a configuration file for https://github.com/savetheinternet/Tinyboard. Aside from the fhash function, all the file does is modify an associative array which is originally defined elsewhere. --- ?php $config['something'] = false; $config['something_else']['foo'] = 'bar'; // [...] if(!function_exists('fhash')) { --- As I said, I'm not able to reproduce this bug manually so I'm not sure where exactly it goes wrong, but I don't think anything else in the file is relevant. When it happens, my syslog is filled up with the below, and I am forced to restart fastcgi. Oct 8 10:32:30 kernel: [9364589.325832] php-cgi[28124]: segfault at 0 ip b6f67d5c sp bf844b6c error 4 in libc-2.7.so[b6ef+155000] Oct 8 10:32:30 kernel: [9364589.330222] php-cgi[28125]: segfault at 0 ip b6f67d5c sp bf844b6c error 4 in libc-2.7.so[b6ef+155000] Oct 8 10:32:30 kernel: [9364589.335009] php-cgi[28126]: segfault at 0 ip b6f67d5c sp bf844b6c error 4 in libc-2.7.so[b6ef+155000] Oct 8 10:32:30 kernel: [9364589.337822] php-cgi[28127]: segfault at 0 ip b6f67d5c sp bf844b6c error 4 in libc-2.7.so[b6ef+155000] [2011-10-08 06:19:41] paj...@php.net Can you paste the short example please? As in not only the place where it occurs. [2011-10-07 17:21:10] savetheinternet at omegasdg dot com Description: Although I do have a short code sample, I'm not sure where exactly or what conditions causes the segfault; I am unable to reproduce it myself. The backtrace indicates that this is indeed where the bug occurs. The code sample below is an extract from a file that is included various times throughout a much larger application. fhash is not defined anywhere else. Test script: --- if(!function_exists('fhash')) { function fhash($file) { system('optipng ' . escapeshellarg(preg_replace('/src\/(\d+)\.(.+)$/', 'thumb/$1.png', $file)) . ' /dev/null'); return sha1_file($file); } } Expected result: To ensure that fhash() is not declared multiple times as this file may be included multiple times. Actual result: -- (gdb) bt #0 0xb6f2ed5c in memcpy () from /lib/i686/cmov/libc.so.6 #0 0xb6f2ed5c in memcpy () from /lib/i686/cmov/libc.so.6 #1 0x084e9e17 in _zend_hash_add_or_update (ht=0x9bb7498, arKey=0xb49e3c98 fhash, nKeyLength=6, pData=0x0, nDataSize=144, pDest=0x0, flag=2, __zend_filename=0x88aa40c /home/user/php-5.3.8/Zend/zend_compile.c, __zend_lineno=2956) at /home/user/php-5.3.8/Zend/zend_hash.c:256 #2 0x084c3d48 in do_bind_function (opline=0xb49e88fc, function_table=0x9bb7498, compile_time=0 '\0') at /home/user/php-5.3.8/Zend/zend_compile.c:2956 #3 0x0850aa49 in ZEND_DECLARE_FUNCTION_SPEC_HANDLER (execute_data=0x9d79da8) at /home/user/php-5.3.8/Zend/zend_vm_execute.h:586 #4 0x08508506 in execute (op_array=0x9d5ceac) at /home/user/php- 5.3.8/Zend/zend_vm_execute.h:107 #5 0x084dcf8d in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/user/php-5.3.8/Zend/zend.c:1236 #6 0x08472037 in php_execute_script (primary_file=0xbfc62428) at /home/user/php-5.3.8/main/main.c:2284 #7 0x085a504e in main (argc=3, argv=0xbfc62594) at /home/user/php- 5.3.8/sapi/cgi/cgi_main.c:2112 (gdb) print (char *)executor_globals.active_op_array-filename $2 = 0xb49e34d0 /var/www/inc/instance-config.php (gdb) frame 4 #4 0x08508506 in execute (op_array=0x9d5ceac) at /home/user/php- 5.3.8/Zend/zend_vm_execute.h:107 107 if ((ret =
Bug #64340 [Asn]: sockets tests failed
Edit report at https://bugs.php.net/bug.php?id=64340edit=1 ID: 64340 Updated by: cataphr...@php.net Reported by:re...@php.net Summary:sockets tests failed Status: Assigned Type: Bug Package:Sockets related Operating System: Mac OSX 10.8 PHP Version:5.5.0alpha5 Assigned To:cataphract Block user comment: N Private report: N New Comment: What's the deal with having changed the header includes order? I don't really like having headers that must be included in a specific order, that usually means one header depends on another, but fails to include it; if there's something that requires the headers to be in a specific order that should be fixed instead. As to rest (the skip and the define for __APPLE_USE_RFC_3542), I see no problem with it; you can commit it yourself. Previous Comments: [2013-03-02 18:05:30] re...@php.net The following patch has been added/updated: Patch Name: ipv6-pktinfo-and-tiny-test-fix Revision: 1362247530 URL: https://bugs.php.net/patch-display.php?bug=64340patch=ipv6-pktinfo-and-tiny-test-fixrevision=1362247530 [2013-03-02 18:05:22] re...@php.net Description: Failed tests: Multicast support: IPv6 send options [ext/sockets/tests/mcast_ipv6_send.phpt] recvmsg(): receive SCM_CREDENTIALS messages [ext/sockets/tests/socket_cmsg_rights.phpt] recvmsg(): basic test [ext/sockets/tests/socket_recvmsg.phpt] sendmsg()/recvmsg(): test ability to receive multiple messages [ext/sockets/tests/socket_sendrecvmsg_multi_msg.phpt] Test if socket_recvfrom() receives data sent by socket_sendto() via IPv4 UDP [ext/sockets/tests/socket_sentto_recvfrom_ipv4_udp.phpt] socket_set_option() with IPV6_PKTINFO [ext/sockets/tests/socket_set_option_in6_pktinfo.phpt]\ diff: == ext/sockets/tests/mcast_ipv6_send.diff == 013+ 014+ Warning: socket_set_option(): unable to set socket option [49]: Can't assign requested address in /Users/reeze/Opensource/php-test/php-src- master/ext/sockets/tests/mcast_ipv6_send.php on line 26 015+ bool(false) 013- bool(true) == ext/sockets/tests/socket_cmsg_rights.diff == 014+ int(24) 014- int(32) 018+ [name] = Array 019+ ( 020+ [family] = 1 021+ [path] = 022+ ) 023+ 018- [name] = == ext/sockets/tests/socket_recvmsg.diff == 007+ 008+ Notice: Use of undefined constant IPV6_RECVPKTINFO - assumed 'IPV6_RECVPKTINFO' in /Users/reeze/Opensource/php- test/php-src-master/ext/sockets/tests/socket_recvmsg.php on line 18 009+ 010+ Warning: socket_set_option() expects parameter 3 to be long, string given in /Users/reeze/Opensource/php- test/php-src-master/ext/sockets/tests/socket_recvmsg.php on line 18 011+ err 007- int(14) 008- Array 009- ( 010- [name] = Array 011- ( 012- [family] = %d 013- [addr] = ::1 014- [port] = 7001 015- [flowinfo] = 0 016- [scope_id] = 0 017- ) 018- 019- [control] = Array 020- ( 021- [0] = Array 022- ( 023- [level] = %d 024- [type] = %d 025- [data] = Array 026- ( 027- [addr] = ::1 028- [ifindex] = %d 029- ) 030- 031- ) 032- 033- ) 034- 035- [iov] = Array 036- ( 037- [0] = testing packet 038- ) 039- 040- [flags] = 0 041- ) == ext/sockets/tests/socket_sendrecvmsg_multi_msg.diff == 007+ 008+ Notice: Use of undefined constant IPV6_RECVPKTINFO - assumed 'IPV6_RECVPKTINFO' in /Users/reeze/Opensource/php- test/php-src-master/ext/sockets/tests/socket_sendrecvmsg_multi_msg.php on line 18 009+ 010+ Warning: socket_set_option() expects parameter 3 to be long, string given in /Users/reeze/Opensource/php- test/php-src-master/ext/sockets/tests/socket_sendrecvmsg_multi_msg.php on line 18 011+ err 007- int(11) 008- Array 009- ( 010- [name] = Array 011- ( 012- [family] = %d 013- [addr] = ::1 014- [port] = 7001 015- [flowinfo] = 0 016- [scope_id] = 0 017- ) 018- 019- [control] = Array 020- ( 021- [0] = Array 022- ( 023- [level] = %d 024- [type] = %d 025- [data] = Array 026- ( 027- [addr] = ::1 028- [ifindex] = %d 029- ) 030- 031- ) 032- 033- [1] = Array 034- ( 035- [level] = %d 036- [type] = %d 037-
Bug #64338 [Fbk-Opn]: pdo_dblib can't connect to Azure SQL
Edit report at https://bugs.php.net/bug.php?id=64338edit=1 ID: 64338 User updated by:mah at everybody dot org Reported by:mah at everybody dot org Summary:pdo_dblib can't connect to Azure SQL -Status: Feedback +Status: Open Type: Bug Package:MSSQL related Operating System: any PHP Version:5.5.0alpha5 Block user comment: N Private report: N New Comment: Yes, this is on Linux. If you're using Azure to host your Linux machine (which I am), it makes sense to use the Azure-hosted SQL database if you can. I've already attached a patch and tested the patch that does exactly what you suggest. Previous Comments: [2013-03-02 17:30:56] paj...@php.net btw, DBSETLDBNAME could be easily added in pdo_dblib_handle_factory (ext/pdo_dblib/dblib_driver.c). Can you test it pls? if you could create a patch and test it, even better :) [2013-03-02 16:56:05] paj...@php.net I suppose you are on Linux as dblib is not supported anymore on windows since quite a while. If you are on win usw sqlsrv, works out of the box. [2013-03-02 15:57:16] mah at everybody dot org Originally reported to Debian: http://bugs.debian.org/702079 [2013-03-02 15:29:43] mah at everybody dot org Description: The SQL database available on Azure apparently does not have the same connection semantics as SQL Server. âuse DATABASEâ is not possible â it returns an error saying that you should open a new connection if you want a new database. This is confusing when you are using the DBLIB connector because it is the DBLIB connection code that does the âuseâ, not the developer's PHP code. The FreeTDS people recognized this a while back: About a year ago we added the DBSETLDBNAME macro as a way to set the dbname in the db-lib LOGINREC. That sets the dbname in the login packet, obviating the need for USE dbname. http://lists.ibiblio.org/pipermail/freetds/2012q4/028168.html The attached patch makes use of DBSETLDBNAME and eliminates the USE. Test script: --- ?php try { $server = SERVER.database.windows.net:1433; $username = USER@SERVER; $password = PASSWORD; $dbname = DBNAME; $mssql = new PDO(dblib:host=$server;dbname=$dbname,$username,$password); echo Success!\n; } catch ( PDOException $e ) { print( Error connecting to SQL Server. ); die(print_r($e)); } -- Edit this bug report at https://bugs.php.net/bug.php?id=64338edit=1
Req #63298 [Opn-Nab]: Nothing resolves upwards in PHP
Edit report at https://bugs.php.net/bug.php?id=63298edit=1 ID: 63298 Updated by: bj...@php.net Reported by:nat at nath dot is Summary:Nothing resolves upwards in PHP -Status: Open +Status: Not a bug Type: Feature/Change Request Package:*General Issues Operating System: Unix PHP Version:5.4.7 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 Previous Comments: [2012-10-26 18:51:52] dagguh at gmail dot com your Animal class is not in global namespace, but in MyProject. You gotta import it via: use MyProject\Animal; This request is invalid BTW. Namespaces should be all in lowercase. [2012-10-17 22:25:08] nat at nath dot is Description: --- From manual page: http://www.php.net/language.namespaces.global --- I would love to use namespaces, but it seems kind of silly that nothing in PHP resolves upwards (be that variables, classes, constants or functions). Test script: --- https://gist.github.com/3908714/c7639b02a8a4fc2c13ebfbcb35e41d17ab1b8d44 Expected result: whoof Actual result: -- Fatal error: Class 'MyProject\Animal\Animal' not found in /Users/Nathaniel/Projects/test/animal/dog.php on line 5 -- Edit this bug report at https://bugs.php.net/bug.php?id=63298edit=1
Bug #53829 [Opn]: Compiling PHP with large file support will replace function gzopen by gzopen64
Edit report at https://bugs.php.net/bug.php?id=53829edit=1 ID: 53829 Updated by: bj...@php.net Reported by:rilatonal at hotmail dot de Summary:Compiling PHP with large file support will replace function gzopen by gzopen64 Status: Open Type: Bug Package:Zlib related Operating System: Linux PHP Version:5.3.5 -Assigned To: +Assigned To:skettler Block user comment: N Private report: N New Comment: skettler: Any need for that ifdef? Can't we always use the RAW macro? And what about the other functions he mentioned in this report? Previous Comments: [2013-02-08 12:26:10] skett...@php.net Added patch zlib-largefile-function-renaming that fixes the gzopen, gzseek and gztell PHP function renaming. [2013-02-08 12:24:51] skett...@php.net The following patch has been added/updated: Patch Name: zlib-largefile-function-renaming Revision: 1360326291 URL: https://bugs.php.net/patch-display.php?bug=53829patch=zlib-largefile-function-renamingrevision=1360326291 [2012-08-26 11:07:08] comments at sentfrom dot com I encountered the same problem with a 64-bit build of PHP on OpenIndiana b151. The symptom I saw was Wordpress automatic updates were failing silently, because the class-pclzip.php module tests for the presence of gzopen. Patching that file is not a viable option since any WP update can overwrite it again. The gzopen patch attached fixes this at the PHP level by using lower-level ZEND macros that are not affected by zlib.h's #define gzopen gzopen64. It is preferable to using an undocumented zlib compilation flag ZLIB_INTERNAL, which may go away at some point in the future. I had to use ZEND_RAW_FENTRY as it does not have a PHP_ equivalent, and we have to pass the first argument gzopen as a string, since cpp would replace gzopen with gzopen64 if passed as a C identifier. [2011-09-07 07:09:20] tx-7-12 at tuxad dot com Hi, I also got this bug with the latest zlib 1.2.5 as system lib and -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE=1. Dirty solution: Define ZLIB_INTERNAL. # /usr/local/php/bin/php -r 'var_dump(function_exists(gzopen));' bool(false) # export CFLAGS=... -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE=1 -DZLIB_INTERNAL=1 configure make # sapi/cli/php -r 'var_dump(function_exists(gzopen));' bool(true) Matching lines in zlib.h: #if !defined(ZLIB_INTERNAL) _FILE_OFFSET_BITS-0 == 64 _LFS64_LARGEFILE-0 # define gzopen gzopen64 # define gzseek gzseek64 # define gztell gztell64 # define gzoffset gzoffset64 # define adler32_combine adler32_combine64 # define crc32_combine crc32_combine64 # ifdef _LARGEFILE64_SOURCE ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *)); ZEXTERN z_off_t ZEXPORT gzseek64 OF((gzFile, z_off_t, int)); ZEXTERN z_off_t ZEXPORT gztell64 OF((gzFile)); ZEXTERN z_off_t ZEXPORT gzoffset64 OF((gzFile)); ZEXTERN uLong ZEXPORT adler32_combine64 OF((uLong, uLong, z_off_t)); ZEXTERN uLong ZEXPORT crc32_combine64 OF((uLong, uLong, z_off_t)); # endif #else ZEXTERN gzFile ZEXPORT gzopen OF((const char *, const char *)); ZEXTERN z_off_t ZEXPORT gzseek OF((gzFile, z_off_t, int)); ZEXTERN z_off_t ZEXPORT gztell OF((gzFile)); ZEXTERN z_off_t ZEXPORT gzoffset OF((gzFile)); ZEXTERN uLong ZEXPORT adler32_combine OF((uLong, uLong, z_off_t)); ZEXTERN uLong ZEXPORT crc32_combine OF((uLong, uLong, z_off_t)); #endif Frank [2011-05-27 17:06:42] j dot henge-ernst at interexa dot de I also encountered that problem compiling php on solaris x86_64 with zlib 1.2.5. I used the following configure commmand: #! /bin/sh # # Created by configure CFLAGS='-xmodel=small -m64 -Kpic -O4' \ CXXFLAGS='-xmodel=small -m64 -Kpic -O4' \ LDFLAGS='-m64' \ CC='cc' \ './configure' \ '--prefix=/opt/IXAGib64' \ '--with-config-file-path=/opt/IXAGib64/etc' \ '--with-config-file-scan-dir=/opt/IXAGib64/etc/php.ini.d' \ '--disable-debug' \ '--enable-inline-optimization' \ '--disable-all' \ '--enable-ctype' \ '--enable-dom' \ '--enable-libxml' \ '--with-libxml-dir=/opt/IXAGib64' \ '--with-openssl=/opt/IXAGib64' \ '--with-pcre-regex' \ '--enable-session' \ '--enable-simplexml' \ '--enable-wddx' \ '--enable-xml' \ '--enable-hash' \ '--enable-json' \ '--enable-filter' \ '--with-zlib=/opt/IXAGib64' \ '--with-apxs2=/opt/IXAGib64/bin/apxs' \ '--with-pear' \ '--with-layout=GNU' \ $@ The remainder of the comments for this report are too long. To view the rest of the
Bug #64229 [Opn-Fbk]: Streams do not recognize SSL contexts
Edit report at https://bugs.php.net/bug.php?id=64229edit=1 ID: 64229 Updated by: bj...@php.net Reported by:andrew dot heebner at gmail dot com Summary:Streams do not recognize SSL contexts -Status: Open +Status: Feedback Type: Bug Package:Streams related Operating System: Win7, Linux PHP Version:5.4.11 Block user comment: N Private report: N Previous Comments: [2013-03-02 01:42:49] payden at paydensutherland dot com This seems to work fine for me on Ubuntu 12.10 32-bit with php-5.4.11 and php- 5.4.12. payden@arwen:~$ php test.php Running on 5.4.11 Linux arwen 3.5.0-23-generic #35-Ubuntu SMP Thu Jan 24 13:05:29 UTC 2013 i686 payden@arwen:~$ Something wrong with your cert? [2013-02-17 14:49:03] andrew dot heebner at gmail dot com Description: stream_socket_server does not accept nor use SSL contexts properly. The same bug and reproduction has existed since 2008 without any valid workaround or fix Test script: --- Please see this old bug post, as it is relevant and still throws the same warnings and errors. https://bugs.php.net/bug.php?id=46127 Expected result: An actual functioning SSL stream server Actual result: -- See https://bugs.php.net/bug.php?id=46127 for errors thrown -- Edit this bug report at https://bugs.php.net/bug.php?id=64229edit=1
Bug #64340 [Asn-Csd]: sockets tests failed
Edit report at https://bugs.php.net/bug.php?id=64340edit=1 ID: 64340 Updated by: larue...@php.net Reported by:re...@php.net Summary:sockets tests failed -Status: Assigned +Status: Closed Type: Bug Package:Sockets related Operating System: Mac OSX 10.8 PHP Version:5.5.0alpha5 Assigned To:cataphract Block user comment: N Private report: N New Comment: Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=f2246f352fc01295c370728d68a9bcd2bb546652 Log: Fixed Bug #64340 (sockets tests failed) Patch by Reeze Previous Comments: [2013-03-02 19:19:57] cataphr...@php.net What's the deal with having changed the header includes order? I don't really like having headers that must be included in a specific order, that usually means one header depends on another, but fails to include it; if there's something that requires the headers to be in a specific order that should be fixed instead. As to rest (the skip and the define for __APPLE_USE_RFC_3542), I see no problem with it; you can commit it yourself. [2013-03-02 18:05:30] re...@php.net The following patch has been added/updated: Patch Name: ipv6-pktinfo-and-tiny-test-fix Revision: 1362247530 URL: https://bugs.php.net/patch-display.php?bug=64340patch=ipv6-pktinfo-and-tiny-test-fixrevision=1362247530 [2013-03-02 18:05:22] re...@php.net Description: Failed tests: Multicast support: IPv6 send options [ext/sockets/tests/mcast_ipv6_send.phpt] recvmsg(): receive SCM_CREDENTIALS messages [ext/sockets/tests/socket_cmsg_rights.phpt] recvmsg(): basic test [ext/sockets/tests/socket_recvmsg.phpt] sendmsg()/recvmsg(): test ability to receive multiple messages [ext/sockets/tests/socket_sendrecvmsg_multi_msg.phpt] Test if socket_recvfrom() receives data sent by socket_sendto() via IPv4 UDP [ext/sockets/tests/socket_sentto_recvfrom_ipv4_udp.phpt] socket_set_option() with IPV6_PKTINFO [ext/sockets/tests/socket_set_option_in6_pktinfo.phpt]\ diff: == ext/sockets/tests/mcast_ipv6_send.diff == 013+ 014+ Warning: socket_set_option(): unable to set socket option [49]: Can't assign requested address in /Users/reeze/Opensource/php-test/php-src- master/ext/sockets/tests/mcast_ipv6_send.php on line 26 015+ bool(false) 013- bool(true) == ext/sockets/tests/socket_cmsg_rights.diff == 014+ int(24) 014- int(32) 018+ [name] = Array 019+ ( 020+ [family] = 1 021+ [path] = 022+ ) 023+ 018- [name] = == ext/sockets/tests/socket_recvmsg.diff == 007+ 008+ Notice: Use of undefined constant IPV6_RECVPKTINFO - assumed 'IPV6_RECVPKTINFO' in /Users/reeze/Opensource/php- test/php-src-master/ext/sockets/tests/socket_recvmsg.php on line 18 009+ 010+ Warning: socket_set_option() expects parameter 3 to be long, string given in /Users/reeze/Opensource/php- test/php-src-master/ext/sockets/tests/socket_recvmsg.php on line 18 011+ err 007- int(14) 008- Array 009- ( 010- [name] = Array 011- ( 012- [family] = %d 013- [addr] = ::1 014- [port] = 7001 015- [flowinfo] = 0 016- [scope_id] = 0 017- ) 018- 019- [control] = Array 020- ( 021- [0] = Array 022- ( 023- [level] = %d 024- [type] = %d 025- [data] = Array 026- ( 027- [addr] = ::1 028- [ifindex] = %d 029- ) 030- 031- ) 032- 033- ) 034- 035- [iov] = Array 036- ( 037- [0] = testing packet 038- ) 039- 040- [flags] = 0 041- ) == ext/sockets/tests/socket_sendrecvmsg_multi_msg.diff == 007+ 008+ Notice: Use of undefined constant IPV6_RECVPKTINFO - assumed 'IPV6_RECVPKTINFO' in /Users/reeze/Opensource/php- test/php-src-master/ext/sockets/tests/socket_sendrecvmsg_multi_msg.php on line 18 009+ 010+ Warning: socket_set_option() expects parameter 3 to be long, string given in /Users/reeze/Opensource/php- test/php-src-master/ext/sockets/tests/socket_sendrecvmsg_multi_msg.php on line 18 011+ err 007- int(11) 008- Array 009- ( 010- [name] = Array 011- ( 012- [family] = %d 013- [addr] = ::1 014- [port] = 7001 015- [flowinfo] = 0 016- [scope_id] = 0 017- ) 018- 019- [control] = Array 020- ( 021- [0] = Array 022- ( 023- [level] = %d 024- [type] = %d 025- [data] = Array 026-
Bug #64340 [Csd-Asn]: sockets tests failed
Edit report at https://bugs.php.net/bug.php?id=64340edit=1 ID: 64340 Updated by: larue...@php.net Reported by:re...@php.net Summary:sockets tests failed -Status: Closed +Status: Assigned Type: Bug Package:Sockets related Operating System: Mac OSX 10.8 PHP Version:5.5.0alpha5 -Assigned To:cataphract +Assigned To:laruence Block user comment: N Private report: N New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php I commmitted, since reeze doesn't has PHP karma. please verify the fix. Previous Comments: [2013-03-03 02:53:54] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=f2246f352fc01295c370728d68a9bcd2bb546652 Log: Fixed Bug #64340 (sockets tests failed) Patch by Reeze [2013-03-03 02:53:30] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=f2246f352fc01295c370728d68a9bcd2bb546652 Log: Fixed Bug #64340 (sockets tests failed) Patch by Reeze [2013-03-02 19:19:57] cataphr...@php.net What's the deal with having changed the header includes order? I don't really like having headers that must be included in a specific order, that usually means one header depends on another, but fails to include it; if there's something that requires the headers to be in a specific order that should be fixed instead. As to rest (the skip and the define for __APPLE_USE_RFC_3542), I see no problem with it; you can commit it yourself. [2013-03-02 18:05:30] re...@php.net The following patch has been added/updated: Patch Name: ipv6-pktinfo-and-tiny-test-fix Revision: 1362247530 URL: https://bugs.php.net/patch-display.php?bug=64340patch=ipv6-pktinfo-and-tiny-test-fixrevision=1362247530 [2013-03-02 18:05:22] re...@php.net Description: Failed tests: Multicast support: IPv6 send options [ext/sockets/tests/mcast_ipv6_send.phpt] recvmsg(): receive SCM_CREDENTIALS messages [ext/sockets/tests/socket_cmsg_rights.phpt] recvmsg(): basic test [ext/sockets/tests/socket_recvmsg.phpt] sendmsg()/recvmsg(): test ability to receive multiple messages [ext/sockets/tests/socket_sendrecvmsg_multi_msg.phpt] Test if socket_recvfrom() receives data sent by socket_sendto() via IPv4 UDP [ext/sockets/tests/socket_sentto_recvfrom_ipv4_udp.phpt] socket_set_option() with IPV6_PKTINFO [ext/sockets/tests/socket_set_option_in6_pktinfo.phpt]\ diff: == ext/sockets/tests/mcast_ipv6_send.diff == 013+ 014+ Warning: socket_set_option(): unable to set socket option [49]: Can't assign requested address in /Users/reeze/Opensource/php-test/php-src- master/ext/sockets/tests/mcast_ipv6_send.php on line 26 015+ bool(false) 013- bool(true) == ext/sockets/tests/socket_cmsg_rights.diff == 014+ int(24) 014- int(32) 018+ [name] = Array 019+ ( 020+ [family] = 1 021+ [path] = 022+ ) 023+ 018- [name] = == ext/sockets/tests/socket_recvmsg.diff == 007+ 008+ Notice: Use of undefined constant IPV6_RECVPKTINFO - assumed 'IPV6_RECVPKTINFO' in /Users/reeze/Opensource/php- test/php-src-master/ext/sockets/tests/socket_recvmsg.php on line 18 009+ 010+ Warning: socket_set_option() expects parameter 3 to be long, string given in /Users/reeze/Opensource/php- test/php-src-master/ext/sockets/tests/socket_recvmsg.php on line 18 011+ err 007- int(14) 008- Array 009- ( 010- [name] = Array 011- ( 012- [family] = %d 013- [addr] = ::1 014- [port] = 7001 015- [flowinfo] = 0 016- [scope_id] = 0 017- ) 018- 019- [control] = Array 020- ( 021- [0] = Array 022- ( 023- [level] = %d 024- [type] = %d 025- [data] = Array 026- ( 027- [addr] = ::1 028- [ifindex] = %d 029- ) 030- 031- ) 032- 033- ) 034- 035- [iov] = Array 036- ( 037- [0] = testing packet 038- ) 039- 040- [flags] = 0 041- ) == ext/sockets/tests/socket_sendrecvmsg_multi_msg.diff == 007+ 008+ Notice: Use of undefined constant IPV6_RECVPKTINFO - assumed 'IPV6_RECVPKTINFO' in /Users/reeze/Opensource/php-
Bug #64340 [Asn-Fbk]: sockets tests failed
Edit report at https://bugs.php.net/bug.php?id=64340edit=1 ID: 64340 Updated by: larue...@php.net Reported by:re...@php.net Summary:sockets tests failed -Status: Assigned +Status: Feedback Type: Bug Package:Sockets related Operating System: Mac OSX 10.8 PHP Version:5.5.0alpha5 Assigned To:laruence Block user comment: N Private report: N Previous Comments: [2013-03-03 02:55:50] larue...@php.net Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php I commmitted, since reeze doesn't has PHP karma. please verify the fix. [2013-03-03 02:53:54] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=f2246f352fc01295c370728d68a9bcd2bb546652 Log: Fixed Bug #64340 (sockets tests failed) Patch by Reeze [2013-03-03 02:53:30] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=f2246f352fc01295c370728d68a9bcd2bb546652 Log: Fixed Bug #64340 (sockets tests failed) Patch by Reeze [2013-03-02 19:19:57] cataphr...@php.net What's the deal with having changed the header includes order? I don't really like having headers that must be included in a specific order, that usually means one header depends on another, but fails to include it; if there's something that requires the headers to be in a specific order that should be fixed instead. As to rest (the skip and the define for __APPLE_USE_RFC_3542), I see no problem with it; you can commit it yourself. [2013-03-02 18:05:30] re...@php.net The following patch has been added/updated: Patch Name: ipv6-pktinfo-and-tiny-test-fix Revision: 1362247530 URL: https://bugs.php.net/patch-display.php?bug=64340patch=ipv6-pktinfo-and-tiny-test-fixrevision=1362247530 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=64340 -- Edit this bug report at https://bugs.php.net/bug.php?id=64340edit=1
Bug #64290 [Asn-Csd]: behavior change of converting to long
Edit report at https://bugs.php.net/bug.php?id=64290edit=1 ID: 64290 Updated by: larue...@php.net Reported by:larue...@php.net Summary:behavior change of converting to long -Status: Assigned +Status: Closed Type: Bug Package:*General Issues PHP Version:master-Git-2013-02-24 (Git) Assigned To:cataphract Block user comment: N Private report: N New Comment: Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=505c6ca486aa8edbc3a42ae0f4ba7eb01d02721c Log: Fixed bug #64290 (behavior change of converting to long) Previous Comments: [2013-02-24 06:38:26] larue...@php.net hmm, wrong assign [2013-02-24 06:31:54] larue...@php.net a more simple example: ?php var_dump(intval(10E20)); ? php 5.3, 5.4, output int(0); php 5.5, master , output: int(3875820019684212736) [2013-02-24 06:14:23] larue...@php.net glopes could you please look at this? should due the recently changes you did to zend_operators.h if the change is okey, please correct the test script. thanks [2013-02-24 06:11:25] larue...@php.net hmm, after I re-configure , php 5.5 start to failed either... [2013-02-24 05:59:03] larue...@php.net Description: ext/ereg/tests/split_variation_004.phpt failed (centOS 64 bits) in 5.5 10E20 give the count of zif_split 0 but in master give the count 1864712049423024128 something changed to convert_to_long from 5.5 to master Test script: --- diff is: 013+ array(5) { 013- array(1) { 015+ string(1) 1 016+ [1]= 017+ string(1) 2 018+ [2]= 019+ string(1) 3 020+ [3]= 021+ string(1) 4 022+ [4]= 023+ string(1) 5 015- string(9) 1 2 3 4 5 -- Edit this bug report at https://bugs.php.net/bug.php?id=64290edit=1
Bug #64290 [Csd]: behavior change of converting to long
Edit report at https://bugs.php.net/bug.php?id=64290edit=1 ID: 64290 Updated by: larue...@php.net Reported by:larue...@php.net Summary:behavior change of converting to long Status: Closed Type: Bug Package:*General Issues PHP Version:master-Git-2013-02-24 (Git) Assigned To:cataphract Block user comment: N Private report: N New Comment: okey, I commit the fix for this test. remove the 10e20 one Previous Comments: [2013-03-03 03:00:39] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=505c6ca486aa8edbc3a42ae0f4ba7eb01d02721c Log: Fixed bug #64290 (behavior change of converting to long) [2013-03-03 03:00:04] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=505c6ca486aa8edbc3a42ae0f4ba7eb01d02721c Log: Fixed bug #64290 (behavior change of converting to long) [2013-02-24 06:38:26] larue...@php.net hmm, wrong assign [2013-02-24 06:31:54] larue...@php.net a more simple example: ?php var_dump(intval(10E20)); ? php 5.3, 5.4, output int(0); php 5.5, master , output: int(3875820019684212736) [2013-02-24 06:14:23] larue...@php.net glopes could you please look at this? should due the recently changes you did to zend_operators.h if the change is okey, please correct the test script. thanks 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=64290 -- Edit this bug report at https://bugs.php.net/bug.php?id=64290edit=1
Req #38917 [NoF-Opn]: OpenSSL: signing function for spkac
Edit report at https://bugs.php.net/bug.php?id=38917edit=1 ID: 38917 Updated by: s...@php.net Reported by:zeph at purotesto dot it Summary:OpenSSL: signing function for spkac -Status: No Feedback +Status: Open Type: Feature/Change Request Package:OpenSSL related Operating System: Irrilevant PHP Version:trunk Block user comment: N Private report: N Previous Comments: [2013-02-18 00:33:52] php-bugs at lists dot php dot net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2012-12-19 15:14:04] queenzeal at gmail dot com If you want SPKAC support in PHP without having to recompile it, try the latest Git version of phpseclib (http://phpseclib.sourceforge.net/). An example of how to use it: http://www.frostjedi.com/phpbb3/viewtopic.php?p=389618#p389618 [2012-01-10 10:38:37] jason dot gerfen at gmail dot com I have added the requested test case and it is included in the patch as 026.phpt. I have also performed the required testing against the Openssl 0.9.8x and 1.0.0x. It is attached to the original bug report #38917. In addition to attaching the proposed patch I have created a github repo to make maintenance on the patch simple for myself. The URL is https://github.com/jas-/SPKAC-PHP-OpenSSL. [2011-12-21 10:49:08] jason dot gerfen at gmail dot com Once again, please disregard the last message. After researching the documentation I found that where I had been using NULL with the openssl_csr_sign() function allows for a CA option as well as the SPKAC addition to the configargs optional array. The patch was updated last night to include the 026.phpt test script, as well as the five new functions to work with the SPKI provided by keygen tags. How do patch inclusions work besides posting them to the php internals list? [2011-12-14 22:10:52] jason dot gerfen at gmail dot com Please disregard my previous comment. I did a little more digging and am under the impression that adding the following to php_openssl_make_REQ() function should allow me to create a self signed certificate using the SPKAC NID like so? if (strcmp(strindex, SPKAC) == 0) { if (!X509_NAME_add_entry_by_txt(subj, strindex, MBSTRING_ASC, (unsigned char*)Z_STRVAL_PP(item), -1, -1, 0)){ php_error_docref(NULL TSRMLS_CC, E_WARNING, dn: add_entry_by_txt %s - %s (failed), strindex, Z_STRVAL_PP(item)); return FAILURE; } } Would you recommend another method? Please advise. 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=38917 -- Edit this bug report at https://bugs.php.net/bug.php?id=38917edit=1