Bug #53540 [Asn->Csd]: Correct Sybase 15.0 libraries not found by configure
Edit report at http://bugs.php.net/bug.php?id=53540&edit=1 ID: 53540 Updated by: the...@php.net Reported by:dputz at sybase dot com Summary:Correct Sybase 15.0 libraries not found by configure -Status: Assigned +Status: Closed Type: Bug Package:*Configuration Issues Operating System: Linux PHP Version:5.3.4 Assigned To:thekid Block user comment: N Private report: N New Comment: 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. Previous Comments: [2011-06-08 10:14:51] the...@php.net Automatic comment from SVN on behalf of thekid Revision: http://svn.php.net/viewvc/?view=revision&revision=311917 Log: - Changed output to be more verbose as to what libraries are used - Changed check for 64-bit vs 32-bit build environment to check sizeof(int) instead of assuming that if libsybct64.so exists, it must be 64-bit # Bug #53540: Correct Sybase 15.0 libraries not found by configure [2010-12-13 18:16:04] dputz at sybase dot com Description: The Makefile ends up with incorrect library names when using Sybase 15.0 or newer libraries. In the configure script, line 92631 reads: elif test -f $SYBASE_CT_INCDIR/libsybct64.so; then and should be elif test -f $SYBASE_CT_LIBDIR/libsybct64.so; then Line 93262 reads: elif test -f $SYBASE_CT_INCDIR/libsybct.so; then and should be elif test -f $SYBASE_CT_LIBDIR/libsybct.so; then I have tested the fix for the second line (32-bit version) and it worked correctly. -- Edit this bug report at http://bugs.php.net/bug.php?id=53540&edit=1
Bug #54962 [Asn]: either real_connect or ssl_set is not working properly
Edit report at http://bugs.php.net/bug.php?id=54962&edit=1 ID: 54962 Updated by: johan...@php.net Reported by:sukarna_0 at yahoo dot co dot in Summary:either real_connect or ssl_set is not working properly Status: Assigned Type: Bug Package:MySQLi related Operating System: CentOS5.5 PHP Version:5.3SVN-2011-05-31 (snap) Assigned To:mysql Block user comment: N Private report: N New Comment: What happens is the following: Your Windows version uses mysqlnd as base library. mysqlnd uses PHP's streams and openssl extension for doing the communication. These demand that the verify_peer option is set else the ssl_ca will be ignored. That is fine. An issue is that verify_peer is only set when manually setting MYSQLI_OPT_SSL_VERIFY_SERVER_CERT to true, mysqli_ssl_set won't do that. so that part has to be fixed. Need to do some research under what conditions we can do set verify_peer automatically. Previous Comments: [2011-06-08 02:23:42] johan...@php.net I think there is a feature difference between libmysql and mysqlnd. When using MySQLnd you can use stream wrappers to load certificates, with libmysql you are limited to local files. We will verify that. [2011-05-31 11:57:56] sukarna_0 at yahoo dot co dot in Description: I have a code as follows. $ssl_ca = 'https://rds.amazonaws.com/doc/mysql-ssl-ca-cert.pem'; $mysqli->ssl_set(null, null, $ssl_ca, null, null); $result = $mysqli->real_connect($location, $usr, $password, $dbname, $port, null, MYSQLI_CLIENT_SSL); This code works with PHP 5.3.5 in windowsXP sp3 and never throws any error even if $ssl_ca contains a wrong path. And this code always throws error- '(HY000/2026): SSL connection error' in CentOS 5.5 32bit(PHP 5.3.5) -- Edit this bug report at http://bugs.php.net/bug.php?id=54962&edit=1
Bug #54719 [Opn->Csd]: Serialization tests fail to set serialize_precision
Edit report at http://bugs.php.net/bug.php?id=54719&edit=1 ID: 54719 Updated by: dani...@php.net Reported by:mats dot lindh at gmail dot com Summary:Serialization tests fail to set serialize_precision -Status: Open +Status: Closed Type: Bug Package:Unknown/Other Function Operating System: Linux PHP Version:trunk-SVN-2011-05-12 (SVN) -Assigned To: +Assigned To:tyrael Block user comment: N Private report: N New Comment: Patch applied by tyrael on 2011-05-16. Previous Comments: [2011-05-12 13:23:06] mats dot lindh at gmail dot com Description: The tests for the serialization module fails to set the INI value for serialize_precision before running the tests, resulting in failed tests if the default precision is used (if the tests are run before make install and no php.ini file is available). Test script: --- make test TESTS=ext/standard/tests/serialize Expected result: Number of tests : 5150 Tests skipped :1 ( 2.0%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:0 ( 0.0%) ( 0.0%) Expected fail :0 ( 0.0%) ( 0.0%) Tests passed: 50 ( 98.0%) (100.0%) Actual result: -- Number of tests : 5150 Tests skipped :1 ( 2.0%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:5 ( 9.8%) ( 10.0%) Expected fail :0 ( 0.0%) ( 0.0%) Tests passed: 45 ( 88.2%) ( 90.0%) -- Edit this bug report at http://bugs.php.net/bug.php?id=54719&edit=1
Bug #55008 [Com]: PHP Filter email doesn't work for facebook emails
Edit report at http://bugs.php.net/bug.php?id=55008&edit=1 ID: 55008 Comment by: zedorg at gmail dot com Reported by:zedorg at gmail dot com Summary:PHP Filter email doesn't work for facebook emails Status: Bogus Type: Bug Package:Filter related Operating System: x86_64 GNU/Linux PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Just for who has the similar problem: facebook accepts these emails without the "apps+" prefix, so this can be cut from email and then its rfc compliant again. Previous Comments: [2011-06-07 17:52:08] dtajchre...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php The filter extension uses a regular expression based on RFC 5321, which like you found, says that the limit on a local-part of an e-mail is 64 octets. [1] http://lxr.php.net/xref/PHP_5_3/ext/filter/logical_filters.c#499 [2] http://tools.ietf.org/html/rfc5321#section-4.5.3.1 [2011-06-07 16:29:39] zedorg at gmail dot com Checked rfc, if this is the good one http://tools.ietf.org/html/rfc5321 , and it says "The maximum total length of a user name or other local-part is 64 octets." However facebook uses 70? [2011-06-07 16:25:07] zedorg at gmail dot com Description: Hello, it seems the filter function is not working the "new" facebook emails like: apps+xxx.xxx.x...@proxymail.facebook.com where x is an alpha numeric character. It returns false. This new feature comes from 2010 January, see: http://www.allfacebook.com/facebook-developers-prepare-to-gain-access-to-user-emails-2010-01 We got a lot of validation failures, cause of this, from facebook connected users, when we trying to use filter_var on these emails. A bit strange, cause if I change the "apps+xxx" to "apps+xx", 5 letter shorted, it accepts. However this won't help us :) Test script: --- http://bugs.php.net/bug.php?id=55008&edit=1
[PHP-BUG] Bug #55010 [NEW]: POST requests send 4 extra bytes
From: Operating system: Ubuntu 11.04 PHP version: 5.3.6 Package: HTTP related Bug Type: Bug Bug description:POST requests send 4 extra bytes Description: PHP sends 4 extra bytes with a POST request when using stream_context_create and file_get_contents. The extra bytes are CR LF CR LF. The RFC does not state that CR LF CR LF should be after message-body. This appears to be the same as Bug #43222: stream_context_create() bugs Was there a test created to detect this problem? Test script: --- $url = 'http://localhost:8001/post'; $post = 'Sample'; // 6 bytes $options = array( 'http' => array( 'method' => 'POST', 'protocol_version' => '1.1', 'content' => $post, ) ); $urlParts = parse_url($url); $headers = array(); $headers[] = 'Content-Type: application/x-www-form-urlencoded; charset=utf-8'; $headers[] = 'Content-Length: ' . strlen($post); $headers[] = 'Connection: close'; // Force servers to close the connection $headers[] = 'Host: ' . $urlParts['host']; // Required for HTTP 1.1 $options['http']['header'] = $headers; $context = stream_context_create($options); file_get_contents($url, false, $context); Expected result: The hexdump of the TCP traffic should appear like thus: 50 4f 53 54 20 2f 70 6f 73 74 20 48 54 54 50 2f |POST /post HTTP/| 0010 31 2e 31 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 |1.1..Content-Typ| 0020 65 3a 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 78 |e: application/x| 0030 2d 77 77 77 2d 66 6f 72 6d 2d 75 72 6c 65 6e 63 |-www-form-urlenc| 0040 6f 64 65 64 3b 20 63 68 61 72 73 65 74 3d 75 74 |oded; charset=ut| 0050 66 2d 38 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e |f-8..Content-Len| 0060 67 74 68 3a 20 36 0d 0a 43 6f 6e 6e 65 63 74 69 |gth: 6..Connecti| 0070 6f 6e 3a 20 63 6c 6f 73 65 0d 0a 48 6f 73 74 3a |on: close..Host:| 0080 20 6c 6f 63 61 6c 68 6f 73 74 0d 0a 0d 0a 53 61 | localhostSa| 0090 6d 70 6c 65 |mple| 0094 Actual result: -- This is what I actually capture as TCP traffic 50 4f 53 54 20 2f 70 6f 73 74 20 48 54 54 50 2f |POST /post HTTP/| 0010 31 2e 31 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 |1.1..Content-Typ| 0020 65 3a 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 78 |e: application/x| 0030 2d 77 77 77 2d 66 6f 72 6d 2d 75 72 6c 65 6e 63 |-www-form-urlenc| 0040 6f 64 65 64 3b 20 63 68 61 72 73 65 74 3d 75 74 |oded; charset=ut| 0050 66 2d 38 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e |f-8..Content-Len| 0060 67 74 68 3a 20 36 0d 0a 43 6f 6e 6e 65 63 74 69 |gth: 6..Connecti| 0070 6f 6e 3a 20 63 6c 6f 73 65 0d 0a 48 6f 73 74 3a |on: close..Host:| 0080 20 6c 6f 63 61 6c 68 6f 73 74 0d 0a 0d 0a 53 61 | localhostSa| 0090 6d 70 6c 65 0d 0a 0d 0a |mple| 0098 -- Edit bug report at http://bugs.php.net/bug.php?id=55010&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=55010&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=55010&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=55010&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=55010&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=55010&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=55010&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=55010&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=55010&r=needscript Try newer version: http://bugs.php.net/fix.php?id=55010&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=55010&r=support Expected behavior: http://bugs.php.net/fix.php?id=55010&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=55010&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=55010&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=55010&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=55010&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=55010&r=dst IIS Stability: http://bugs.php.net/fix.php?id=55010&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=55010&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=55010&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=55010&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=55010&r=mysqlcfg
Bug #55010 [Opn->Dup]: POST requests send 4 extra bytes
Edit report at http://bugs.php.net/bug.php?id=55010&edit=1 ID: 55010 Updated by: scott...@php.net Reported by:fidian at rumkin dot com Summary:POST requests send 4 extra bytes -Status: Open +Status: Duplicate Type: Bug Package:HTTP related Operating System: Ubuntu 11.04 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Was fixed in Bug #54137 Previous Comments: [2011-06-08 18:01:21] fidian at rumkin dot com Description: PHP sends 4 extra bytes with a POST request when using stream_context_create and file_get_contents. The extra bytes are CR LF CR LF. The RFC does not state that CR LF CR LF should be after message-body. This appears to be the same as Bug #43222: stream_context_create() bugs Was there a test created to detect this problem? Test script: --- $url = 'http://localhost:8001/post'; $post = 'Sample'; // 6 bytes $options = array( 'http' => array( 'method' => 'POST', 'protocol_version' => '1.1', 'content' => $post, ) ); $urlParts = parse_url($url); $headers = array(); $headers[] = 'Content-Type: application/x-www-form-urlencoded; charset=utf-8'; $headers[] = 'Content-Length: ' . strlen($post); $headers[] = 'Connection: close'; // Force servers to close the connection $headers[] = 'Host: ' . $urlParts['host']; // Required for HTTP 1.1 $options['http']['header'] = $headers; $context = stream_context_create($options); file_get_contents($url, false, $context); Expected result: The hexdump of the TCP traffic should appear like thus: 50 4f 53 54 20 2f 70 6f 73 74 20 48 54 54 50 2f |POST /post HTTP/| 0010 31 2e 31 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 |1.1..Content-Typ| 0020 65 3a 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 78 |e: application/x| 0030 2d 77 77 77 2d 66 6f 72 6d 2d 75 72 6c 65 6e 63 |-www-form-urlenc| 0040 6f 64 65 64 3b 20 63 68 61 72 73 65 74 3d 75 74 |oded; charset=ut| 0050 66 2d 38 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e |f-8..Content-Len| 0060 67 74 68 3a 20 36 0d 0a 43 6f 6e 6e 65 63 74 69 |gth: 6..Connecti| 0070 6f 6e 3a 20 63 6c 6f 73 65 0d 0a 48 6f 73 74 3a |on: close..Host:| 0080 20 6c 6f 63 61 6c 68 6f 73 74 0d 0a 0d 0a 53 61 | localhostSa| 0090 6d 70 6c 65 |mple| 0094 Actual result: -- This is what I actually capture as TCP traffic 50 4f 53 54 20 2f 70 6f 73 74 20 48 54 54 50 2f |POST /post HTTP/| 0010 31 2e 31 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 |1.1..Content-Typ| 0020 65 3a 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 78 |e: application/x| 0030 2d 77 77 77 2d 66 6f 72 6d 2d 75 72 6c 65 6e 63 |-www-form-urlenc| 0040 6f 64 65 64 3b 20 63 68 61 72 73 65 74 3d 75 74 |oded; charset=ut| 0050 66 2d 38 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e |f-8..Content-Len| 0060 67 74 68 3a 20 36 0d 0a 43 6f 6e 6e 65 63 74 69 |gth: 6..Connecti| 0070 6f 6e 3a 20 63 6c 6f 73 65 0d 0a 48 6f 73 74 3a |on: close..Host:| 0080 20 6c 6f 63 61 6c 68 6f 73 74 0d 0a 0d 0a 53 61 | localhostSa| 0090 6d 70 6c 65 0d 0a 0d 0a |mple| 0098 -- Edit this bug report at http://bugs.php.net/bug.php?id=55010&edit=1
[PHP-BUG] Bug #55011 [NEW]: serialize a private attribute give it a bad length string
From:
Operating system: Windows XP SP3
PHP version: 5.2.17
Package: Class/Object related
Bug Type: Bug
Bug description:serialize a private attribute give it a bad length string
Description:
When you serialize an object with private or protected members, their
length names are baddly calculated (maybe because of "These prepended
values [which] have null bytes on either side" like the documentation
says.
Anyway, this is a problem when you want to write your serialisation into a
file and analyse it next.
Note that I'm not using PHP 5.2.17 but 5.2.3. But I haven't read a fix of
this problem between both version.
Test script:
---
Here is an example:
class Ab {
private $_i = 0;
public function __construct() { $this->_i = 1; }
};
$oAB = new Ab();
$str = serialize($oAB);
echo $str;
Expected result:
O:2:"Ab":1:{s:4:"Ab_i";i:1;}
Actual result:
--
O:2:"Ab":1:{s:6:"Ab_i";i:1;}
Note the "s:6" instead of "s:4": this is why the unserialization from this
string is impossible.
--
Edit bug report at http://bugs.php.net/bug.php?id=55011&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=55011&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=55011&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=55011&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=55011&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=55011&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=55011&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=55011&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=55011&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=55011&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=55011&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=55011&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=55011&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=55011&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=55011&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=55011&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=55011&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=55011&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=55011&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=55011&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=55011&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=55011&r=mysqlcfg
Bug #55011 [Opn->Bgs]: serialize a private attribute give it a bad length string
Edit report at http://bugs.php.net/bug.php?id=55011&edit=1
ID: 55011
Updated by: scott...@php.net
Reported by:nicolas dot giraud at maileva dot com
Summary:serialize a private attribute give it a bad length
string
-Status: Open
+Status: Bogus
Type: Bug
Package:Class/Object related
Operating System: Windows XP SP3
PHP Version:5.2.17
Block user comment: N
Private report: N
New Comment:
The null bytes aren't shown by your browser, but they are there. You can
unserialize() this value still and everything works.
Previous Comments:
[2011-06-08 18:35:57] nicolas dot giraud at maileva dot com
Description:
When you serialize an object with private or protected members, their length
names are baddly calculated (maybe because of "These prepended values [which]
have null bytes on either side" like the documentation says.
Anyway, this is a problem when you want to write your serialisation into a file
and analyse it next.
Note that I'm not using PHP 5.2.17 but 5.2.3. But I haven't read a fix of this
problem between both version.
Test script:
---
Here is an example:
class Ab {
private $_i = 0;
public function __construct() { $this->_i = 1; }
};
$oAB = new Ab();
$str = serialize($oAB);
echo $str;
Expected result:
O:2:"Ab":1:{s:4:"Ab_i";i:1;}
Actual result:
--
O:2:"Ab":1:{s:6:"Ab_i";i:1;}
Note the "s:6" instead of "s:4": this is why the unserialization from this
string is impossible.
--
Edit this bug report at http://bugs.php.net/bug.php?id=55011&edit=1
Bug #48831 [Csd->ReO]: php -i has different output to php --ini
Edit report at http://bugs.php.net/bug.php?id=48831&edit=1 ID: 48831 Updated by: rquadl...@php.net Reported by:RQuadling at GMail dot com Summary:php -i has different output to php --ini -Status: Closed +Status: Re-Opened Type: Bug Package:CGI related Operating System: * PHP Version:5.* -Assigned To:pajoye +Assigned To: Block user comment: N Private report: N New Comment: The bug is still in effect. The changes made don't actually effect the output. The commit made only added a single extern and did not amend the code to display the php ini scan dir. The supplied patch covered all the bases. Previous Comments: [2010-09-14 12:36:28] paj...@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. [2010-09-14 12:36:23] paj...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=303357 Log: - fix #48831 php -i has different output to php --ini [2010-04-12 17:23:30] rquadl...@php.net The following patch has been added/updated: Patch Name: ScanIniDir Revision: 1271085810 URL: http://bugs.php.net/patch-display.php?bug=48831&patch=ScanIniDir&revision=1271085810 [2009-08-24 12:48:57] RQuadling at GMail dot com Missed an PHPAPI extern char *php_ini_scanned_path; [2009-07-07 11:28:46] rquadl...@php.net Typo: had => has 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 http://bugs.php.net/bug.php?id=48831 -- Edit this bug report at http://bugs.php.net/bug.php?id=48831&edit=1
Bug #55009 [Opn->Asn]: Error when compile
Edit report at http://bugs.php.net/bug.php?id=55009&edit=1 ID: 55009 Updated by: fel...@php.net Reported by:hexes at mail dot ru Summary:Error when compile -Status: Open +Status: Assigned Type: Bug Package:Sybase-ct (ctlib) related Operating System: Linux 2.6.36-gentoo-r5 PHP Version:5.3.6 -Assigned To: +Assigned To:thekid Block user comment: N Private report: N Previous Comments: [2011-06-08 08:33:34] hexes at mail dot ru Description: In file included from /var/tmp/portage/dev-lang/php-5.3.6/work/sapis- build/cli/ext/sybase_ct/php_sybase_ct.h:63, from /var/tmp/portage/dev-lang/php-5.3.6/work/sapis- build/cli/ext/sybase_ct/php_sybase_ct.c:30: /opt/sybase/OCS-15_0/include/ctpublic.h:269: error: expected declaration specifiers or â...â before âSQLDAâ /var/tmp/portage/dev-lang/php-5.3.6/work/sapis- build/cli/ext/sybase_ct/php_sybase_ct.c: In function â_client_message_handlerâ: /var/tmp/portage/dev-lang/php-5.3.6/work/sapis- build/cli/ext/sybase_ct/php_sybase_ct.c:391: warning: format â%dâ expects type âintâ, but argument 5 has type âlong intâ make: *** [ext/sybase_ct/php_sybase_ct.lo] Error 1 make: *** Waiting for unfinished jobs emake failed I think that error can be in config.m4 (str 60): elif test -f $SYBASE_CT_INCDIR/libsybct.so; then $PHP_SYBASE_CT = '/opt/sybase/OCS-15_0' $SYBASE_CT_INCDIR = $PHP_SYBASE_CT/include But libraries are located in: $SYBASE_CT_LIBDIR=$PHP_SYBASE_CT/lib ls /opt/sybase/OCS-15_0/include/ bkpublic.h cobpub.cbl csconfig.h cspublic.h cstypes.h ctpublic.h mcconfig.h mcpublic.h mctypes.h oscompat.h oserror.h ospublic.h sqlca.h sqlda.h srverror.h srv.h sybdb.h sybdbn.h syberror.h sybesql.c sybfront.h sybhesql.cbl sybhesql.h sybhstmt.h syblogin.h sybtesql.cbl sybtesql.h ls -1 /opt/sybase/OCS-15_0/lib/ libs.a libsmapp.a libsybblk.a libsybblk_r.a libsybblk_r.so libsybblk.so libsybcobct.a libsybcobct_r.a libsybcomn.a libsybcomn_r.a libsybcomn_r.so libsybcomn.so libsybcs.a libsybcs_r.a libsybcs_r.so libsybcs.so libsybct.a libsybct_r.a libsybct_r.so libsybct.so libsybdb.a libsybdb.so libsybdldap.so.15.0.0 libsybdldap.so.15.0.3 libsybfssl.so.15.0.0 libsybfssl.so.15.0.3 libsybintl.a libsybintl_r.a libsybintl_r.so libsybintl.so libsybskrb.so.15.0.0 libsybskrb.so.15.0.3 libsybtcl.a libsybtcl_r.a libsybtcl_r.so libsybtcl.so libsybunic.a libsybunic.so And also, there is no libs: PHP_ADD_LIBRARY(cs,, SYBASE_CT_SHARED_LIBADD) PHP_ADD_LIBRARY(ct,, SYBASE_CT_SHARED_LIBADD) PHP_ADD_LIBRARY(comn,, SYBASE_CT_SHARED_LIBADD) PHP_ADD_LIBRARY(intl,, SYBASE_CT_SHARED_LIBADD) -- Edit this bug report at http://bugs.php.net/bug.php?id=55009&edit=1
[PHP-BUG] Bug #55012 [NEW]: DOMConfiguration available but not linked
From: Operating system: PHP version: 5.3SVN-2011-06-09 (snap) Package: DOM XML related Bug Type: Bug Bug description:DOMConfiguration available but not linked Description: hi $document->domConfig; (readonly) should return a DOMConfiguration class the class DOMConfiguration is actually available (and instantiable) but it is not linked to DOMDocument try this: echo new \ReflectionClass(\new DOMConfiguration)); -- Edit bug report at http://bugs.php.net/bug.php?id=55012&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=55012&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=55012&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=55012&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=55012&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=55012&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=55012&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=55012&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=55012&r=needscript Try newer version: http://bugs.php.net/fix.php?id=55012&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=55012&r=support Expected behavior: http://bugs.php.net/fix.php?id=55012&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=55012&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=55012&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=55012&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=55012&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=55012&r=dst IIS Stability: http://bugs.php.net/fix.php?id=55012&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=55012&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=55012&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=55012&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=55012&r=mysqlcfg
Bug #55012 [Opn->Bgs]: DOMConfiguration available but not linked
Edit report at http://bugs.php.net/bug.php?id=55012&edit=1 ID: 55012 Updated by: dtajchre...@php.net Reported by:giorgio dot liscio at email dot it Summary:DOMConfiguration available but not linked -Status: Open +Status: Bogus Type: Bug Package:DOM XML related PHP Version:5.3SVN-2011-06-09 (snap) 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 The class isn't implemented yet. A shell of the class exists in the code base so you're able to create an instance but nothing is implemented... so a null is returned when you access $domdocument->config. Sorry. :) [1] http://lxr.php.net/opengrok/xref/PHP_5_3/ext/dom/domconfiguration.c [2] http://lxr.php.net/opengrok/xref/PHP_5_3/ext/dom/php_dom.c#669 [3] http://lxr.php.net/opengrok/xref/PHP_5_3/ext/dom/document.c#887 [david@oslo:~]$ php -r '$a = new DOMConfiguration(); $a->getParameter(); $a = new DOMDocument(); var_dump($a->config);' PHP Warning: DOMConfiguration::getParameter(): Not yet implemented in Command line code on line 1 Warning: DOMConfiguration::getParameter(): Not yet implemented in Command line code on line 1 NULL [david@oslo:~]$ Previous Comments: [2011-06-09 02:39:45] giorgio dot liscio at email dot it Description: hi $document->domConfig; (readonly) should return a DOMConfiguration class the class DOMConfiguration is actually available (and instantiable) but it is not linked to DOMDocument try this: echo new \ReflectionClass(\new DOMConfiguration)); -- Edit this bug report at http://bugs.php.net/bug.php?id=55012&edit=1
Bug #48675 [Com]: sybase_ct does not support multiple result sets returned by stored procedures
Edit report at http://bugs.php.net/bug.php?id=48675&edit=1
ID: 48675
Comment by: hexes at mail dot ru
Reported by:lo at readyon dot com
Summary:sybase_ct does not support multiple result sets
returned by stored procedures
Status: Open
Type: Bug
Package:Sybase-ct (ctlib) related
Operating System: Mac OS X 10.5.8 (9L31a)
PHP Version:5.2.10
Block user comment: N
Private report: N
New Comment:
Gentlemen developers!
When??? There is a patch, i'm not so cleaver as you, and cant use it. Can you
apply it to main branch?
Previous Comments:
[2009-09-25 17:48:18] lo at readyon dot com
I haven't looked at 5.3.0. However, the changes to php_sybase_ct.c are
relatively straightforward:
1. Disable cancelling/closing after successful result
php_sybase_finish_results()
case CS_COMPUTE_RESULT:
case CS_CURSOR_RESULT:
case CS_PARAM_RESULT:
case CS_ROW_RESULT:
/* Unexpected results, cancel them. */
php_error_docref(NULL TSRMLS_CC, E_NOTICE, "Sybase:
Unexpected results, cancelling current");
// !!!:KLS:20090624 Do not cancel when there are
additional
// rows. THe command will be cancelled upon next query
if
// sybase_next_result() is not invoked.
// {
fail = 1;
retcode = CS_END_RESULTS;
// ct_cancel(NULL, result->sybase_ptr->cmd,
CS_CANCEL_CURRENT);
// }
break;
2. Add a sybase_next_result() function and register these functions.
/* {{{ proto int sybase_next_result(int conn)
Fetch the next result set */
PHP_FUNCTION(sybase_next_result)
{
zval **db, **sybase_link_index;
int id;
char *cmdbuf;
sybase_link *sybase_ptr;
sybase_result *result;
int retcode;
int restype;
switch(ZEND_NUM_ARGS()) {
case 1:
if (zend_get_parameters_ex(1, &db) == FAILURE) {
RETURN_FALSE;
}
id =
php_sybase_get_default_link(INTERNAL_FUNCTION_PARAM_PASSTHRU);
CHECK_LINK(id);
break;
case 2:
if (zend_get_parameters_ex(2, &db, &sybase_link_index)
== FAILURE) {
RETURN_FALSE;
}
id = -1;
break;
default:
WRONG_PARAM_COUNT;
break;
}
ZEND_FETCH_RESOURCE2(sybase_ptr, sybase_link *,
sybase_link_index, id, "Sybase-Link", le_link, le_plink);
/* Check to see if a previous sybase_unbuffered_query has read
all rows */
if (sybase_ptr->active_result_index) {
zval *tmp = NULL;
php_error_docref(NULL TSRMLS_CC, E_NOTICE, "called without
first fetching all rows from a previous
unbuffered query");
if (sybase_ptr->cmd) {
ct_cancel(NULL, sybase_ptr->cmd, CS_CANCEL_ALL);
}
/* Get the resultset and free it */
ALLOC_ZVAL(tmp);
Z_LVAL_P(tmp)= sybase_ptr->active_result_index;
Z_TYPE_P(tmp)= IS_RESOURCE;
INIT_PZVAL(tmp);
ZEND_FETCH_RESOURCE(result, sybase_result *, &tmp, -1,
"Sybase result", le_result);
if (result) {
php_sybase_finish_results(result TSRMLS_CC);
}
zval_ptr_dtor(&tmp);
zend_list_delete(sybase_ptr->active_result_index);
sybase_ptr->active_result_index= 0;
}
retcode = ct_results(sybase_ptr->cmd, &restype);
switch (retcode) {
case CS_SUCCEED:
result = php_sybase_fetch_result_set(sybase_ptr, 0,
1);
if (result == NULL) {
ct_cancel(NULL, sybase_ptr->cmd, CS_CANCEL_ALL);
sybase_ptr->dead = 1;
RETURN_FALSE;
}
/* Indicate we have data in case of buffered queries
*/
id= ZEND_REGISTER_RESOURCE(return_value, result,
le_result);
sybase_ptr->active_result_index= 0 ? id : 0;
break;
case CS_END_RESULTS:
/* No more result sets */
RETURN_FALSE;
case CS_FAIL:
ct_cancel(NULL, sybase_ptr->cmd, CS_CANCEL_ALL);
sybase_ptr->dead = 1;
/* Fall through */
case CS_CANCELED:
default:
RETURN_FALSE;
}
}
/* }}} */
Req #20281 [Com]: Extend the Sybase CT module
Edit report at http://bugs.php.net/bug.php?id=20281&edit=1 ID: 20281 Comment by: hexes at mail dot ru Reported by:ddc at portalframework dot com Summary:Extend the Sybase CT module Status: Assigned Type: Feature/Change Request Package:Sybase-ct (ctlib) related Operating System: * PHP Version:* Assigned To:thekid Block user comment: N Private report: N New Comment: 9 years! NINE! Gentlemen developers! When??? In BugTrack there is a patch, i'm not so cleaver as you, and cant use it. Can you apply it to main branch? Previous Comments: [2004-02-10 17:39:46] der...@php.net PHP 4.3.x will not get any new features, they'll have to wait. [2004-02-10 17:35:54] a dot lahaye at wanadoo dot fr Do you planed the fact to retreive multi resultset on PHP 4.3.X ? [2004-01-23 21:03:01] the...@php.net This is planned for the future, its kind of hard to patch ontop of the current code. Suspended until I get around to rewriting ext/sybase_ct. [2002-11-06 08:20:03] ddc at portalframework dot com Could someone develop a function for the Sybase CT library to retrieve more than one result set, like mssql_next_result? -- Edit this bug report at http://bugs.php.net/bug.php?id=20281&edit=1
Bug #26636 [Com]: multi-result-set on Sybase
Edit report at http://bugs.php.net/bug.php?id=26636&edit=1 ID: 26636 Comment by: hexes at mail dot ru Reported by:a dot lahaye at wanadoo dot fr Summary:multi-result-set on Sybase Status: Bogus Type: Bug Package:Sybase-ct (ctlib) related Operating System: Linux RedHat 7.3 PHP Version:4.3.4 Block user comment: N Private report: N New Comment: Any movements? Previous Comments: [2004-05-25 21:27:49] alahaye at fm2i dot com Hi all, On PHP 4.3.7 in "list of change" you said : >> Fixed handling of return values from storred procedures in mssql_execute() >> with multiple result sets returned. And for Sybase ? Many people have the same pb with Sybase. Bug related to : #13763, #11475, #13475, #13735, #12074,#26363 Thx a lot. [2003-12-16 00:08:17] sni...@php.net Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. See bug #13475 [2003-12-15 18:29:09] a dot lahaye at wanadoo dot fr Description: Hi, When your run a stored procedure (under sybase) that make multi-result-set you can only have the first multi-result-set (not the other). Bug related to : #13763, #11475, #13475, #13735, #12074 for example in a stored procedure (at the end of this) SELECT LIB1, LIB2 FROM LIBELLE SELECT NAME, FNAME FROM PEOPLE You have only date from table LIBELLE Expected result: >From java you can access to the multi-result-set Actual result: -- get only the first result set -- Edit this bug report at http://bugs.php.net/bug.php?id=26636&edit=1
