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
