Bug #59916 [Com]: Can't use module on Fedora 15
Edit report at https://bugs.php.net/bug.php?id=59916&edit=1 ID: 59916 Comment by: peter at ptm dot pp dot ru Reported by:mark dot frost at lightningsource dot com Summary:Can't use module on Fedora 15 Status: Open Type: Bug Package:expect Operating System: Fedora 15 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Have the same problem in CentOS 6. # rpm -q expect expect-devel tcl tcl-devel php php-devel expect-5.44.1.15-2.el6.x86_64 expect-devel-5.44.1.15-2.el6.x86_64 tcl-8.5.7-6.el6.x86_64 tcl-devel-8.5.7-6.el6.x86_64 php-5.3.8-5.el6.remi.x86_64 php-devel-5.3.8-5.el6.remi.x86_64 # php -m | grep expect PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/expect.so' - /usr/lib64/php/modules/expect.so: undefined symbol: Tcl_GetStringResult in Unknown on line 0 Previous Comments: [2011-08-30 16:21:16] mark dot frost at lightningsource dot com It looks like I dont get this issue with version 0.2.7 of the code, but I do get the Segmentation Fault issue. I thought that piece of information might be helpful. [2011-08-30 12:44:05] mark dot frost at lightningsource dot com Description: I've been trying to install this package on Fedora 15, but have been unsuccessful thus far. With the most recent version, after either a PECL install or manually installing it from source, I receive the following: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/expect.so' - /usr/lib64/php/modules/expect.so: undefined symbol: Tcl_GetStringResult in Unknown on line 0 Here's the versions Im running of all of the relevant packages: [mfrost@localhost expect-0.3.0]$ rpm -q expect expect-devel tcl tcl-devel php php-devel expect-5.45-3.fc15.x86_64 expect-devel-5.45-3.fc15.x86_64 tcl-8.5.9-3.fc15.x86_64 tcl-devel-8.5.9-3.fc15.x86_64 php-5.3.6-2.fc15.x86_64 php-devel-5.3.6-2.fc15.x86_64 For the moment, I'd be equally happy with an actual fix, as with a work-around. I'd just like to get the module installed so I can use it. Reproduce code: --- [mfrost@localhost expect-0.3.0]$ sudo pecl install expect-beta [mfrost@localhost expect-0.3.0]$ php myscript.php Expected result: I expect the script to run and be able to load the module. Actual result: -- PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/expect.so' - /usr/lib64/php/modules/expect.so: undefined symbol: Tcl_GetStringResult in Unknown on line 0 PHP Warning: fopen(): Unable to find the wrapper "expect" - did you forget to enable it when you configured PHP? in /home/mfrost/ssh_development/class.ssh.php on line 20 PHP Warning: fopen(expect://...@lvis05): failed to open stream: No such file or directory in /home/mfrost/ssh_development/class.ssh.php on line 20 -- Edit this bug report at https://bugs.php.net/bug.php?id=59916&edit=1
Bug #60106 [Opn]: stream_socket_server + long unix socket path = 'Unknown error'
Edit report at https://bugs.php.net/bug.php?id=60106&edit=1
ID: 60106
Updated by: larue...@php.net
Reported by:tyr...@php.net
Summary:stream_socket_server + long unix socket path =
'Unknown error'
Status: Open
Type: Bug
Package:Streams related
Operating System: linux debian squeeze 64 bit
PHP Version:5.4.0beta2
Block user comment: N
Private report: N
New Comment:
actullay, there is a limition,
sys/un.h
/* Structure describing the address of an AF_LOCAL (aka AF_UNIX) socket. */
struct sockaddr_un
{
__SOCKADDR_COMMON (sun_);
char sun_path[108]; /* Path name. */
};
I think this issue could mark as doc problem.
Previous Comments:
[2011-10-20 19:11:44] tyr...@php.net
Description:
this works:
./sapi/cli/php -r '$file = "/tmp/".str_repeat("a",
101);stream_socket_server("unix://".$file) && unlink($file);'
this isn't:
./sapi/cli/php -r '$file = "/tmp/".str_repeat("a",
102);stream_socket_server("unix://".$file) && unlink($file);'
gives me an:
Warning: stream_socket_server(): unable to connect to
unix:///tmp/
aa (Unknown error) in Command line code on line
1
I didn't found any mention in the documentation about restrictions on the
length
of the socket file.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60106&edit=1
Req #59905 [Com]: bbcode_add_smiley priority argument
Edit report at https://bugs.php.net/bug.php?id=59905&edit=1 ID: 59905 Comment by: joaoptm78 at gmail dot com Reported by:m dot jephcote at live dot com Summary:bbcode_add_smiley priority argument Status: Open Type: Feature/Change Request Package:bbcode Operating System: CentOS 5.6 PHP Version:5_3 SVN-2011-08-19 (dev) Block user comment: N Private report: N New Comment: This package is quite buggy and it does indeed appear to have been abandoned. A workaround for this bug is to order your emoticons in descending alphabetical order or starting with the longest emoticons. So for example you would first add :o) then :o via bbcode_add_smiley(). Previous Comments: [2011-09-26 07:41:05] rewt0r at gmx dot com Has this package been abandoned? [2011-08-19 08:31:25] m dot jephcote at live dot com Description: Is there any way to set the priority of which these are parsed? At the moment if I have an emoticon that is assigned to ":o" and another that is assigned to ":o)" the former will be parsed on the latter leaving a ")" Would be good if there was an argument to specify the priority of parsing. -- Edit this bug report at https://bugs.php.net/bug.php?id=59905&edit=1
Bug #60104 [Opn->Fbk]: Segmentation Fault
Edit report at https://bugs.php.net/bug.php?id=60104&edit=1 ID: 60104 Updated by: fel...@php.net Reported by:patrickalla...@php.net Summary:Segmentation Fault -Status: Open +Status: Feedback Type: Bug Package:Reproducible crash Operating System: Gentoo Linux PHP Version:trunk-SVN-2011-10-20 (SVN) Block user comment: N Private report: N New Comment: Please, paste the test source at somewhere. Previous Comments: [2011-10-20 16:39:34] patrickalla...@php.net Description: PHP 5.4 / trunk segfault while using phpunit. It only happens with one specific test, however, it looks like that test content is not relevant at all, emptying its content or putting a "die" at the end of that test avoid the segfault. It must happen in the phpunit code after the execution of that test. Tested using trunk @rev 318251 See the backtrace which is more relevant. Actual result: -- (gdb) bt #0 0x00922721 in ZEND_SEND_VAL_SPEC_CONST_HANDLER (execute_data=0x7fcee7305910) at /home/patrick.allaert/Projets/php- src/Zend/zend_vm_execute.h:2361 #1 0x00919b46 in execute (op_array=0x7fcee5293f78) at /home/patrick.allaert/Projets/php-src/Zend/zend_vm_execute.h:410 #2 0x008dbb61 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/patrick.allaert/Projets/php-src/Zend/zend.c:1272 #3 0x00852760 in php_execute_script (primary_file=0x7390c1a0) at /home/patrick.allaert/Projets/php-src/main/main.c:2414 #4 0x00a25095 in do_cli (argc=6, argv=0x7390c548) at /home/patrick.allaert/Projets/php-src/sapi/cli/php_cli.c:983 #5 0x00a25fad in main (argc=6, argv=0x7390c548) at /home/patrick.allaert/Projets/php-src/sapi/cli/php_cli.c:1356 -- Edit this bug report at https://bugs.php.net/bug.php?id=60104&edit=1
[PHP-BUG] Bug #60106 [NEW]: stream_socket_server + long unix socket path = 'Unknown error'
From: tyrael
Operating system: linux debian squeeze 64 bit
PHP version: 5.4.0beta2
Package: Streams related
Bug Type: Bug
Bug description:stream_socket_server + long unix socket path = 'Unknown error'
Description:
this works:
./sapi/cli/php -r '$file = "/tmp/".str_repeat("a",
101);stream_socket_server("unix://".$file) && unlink($file);'
this isn't:
./sapi/cli/php -r '$file = "/tmp/".str_repeat("a",
102);stream_socket_server("unix://".$file) && unlink($file);'
gives me an:
Warning: stream_socket_server(): unable to connect to
unix:///tmp/
aa (Unknown error) in Command line code on
line
1
I didn't found any mention in the documentation about restrictions on the
length
of the socket file.
--
Edit bug report at https://bugs.php.net/bug.php?id=60106&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60106&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60106&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60106&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60106&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60106&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60106&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60106&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60106&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60106&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60106&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60106&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60106&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60106&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60106&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60106&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60106&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60106&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60106&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60106&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60106&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60106&r=mysqlcfg
[PHP-BUG] Bug #60105 [NEW]: Session failover not functioning
From:
Operating system: FreeBSD 8.1-RELEASE
PHP version: 5.3.8
Package: memcache
Bug Type: Bug
Bug description:Session failover not functioning
Description:
I have tried this eight ways to Sunday. I have created working test cases
on multiple servers with different combinations of settings to try and
figure out why the failover does not work.
We have php5.3.8, pecl-memcache-3.0.6, memcached-1.4.7 with repcached.
Upon session_start() a key is successfully created in memcache. Repcached
does replicate it over to the other server and can be verified by telnet.
When we simulate a failure, the session handler does not fail over to the
next available server listed in the save_path.
Current configuration:
session.save_handler = memcache
session.save_path = "tcp://ip1:11211, tcp://ip2:11211"
memcache.allow_failover="1"
memcache.hash_strategy="consistent"
We have tried to get it work with and without the below ini settings in
different combinations:
memcache.session_redundancy=2
memcache.redundancy=1
Test script:
---
";
$_SESSION['id']=rand();
}else {
echo $_SESSION['id']."\n";
}
?>
--
Edit bug report at https://bugs.php.net/bug.php?id=60105&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60105&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60105&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60105&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60105&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60105&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60105&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60105&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60105&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60105&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60105&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60105&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60105&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60105&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60105&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60105&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60105&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60105&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60105&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60105&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60105&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60105&r=mysqlcfg
[PHP-BUG] Bug #60104 [NEW]: Segmentation Fault
From: patrickallaert Operating system: Gentoo Linux PHP version: trunk-SVN-2011-10-20 (SVN) Package: Reproducible crash Bug Type: Bug Bug description:Segmentation Fault Description: PHP 5.4 / trunk segfault while using phpunit. It only happens with one specific test, however, it looks like that test content is not relevant at all, emptying its content or putting a "die" at the end of that test avoid the segfault. It must happen in the phpunit code after the execution of that test. Tested using trunk @rev 318251 See the backtrace which is more relevant. Actual result: -- (gdb) bt #0 0x00922721 in ZEND_SEND_VAL_SPEC_CONST_HANDLER (execute_data=0x7fcee7305910) at /home/patrick.allaert/Projets/php- src/Zend/zend_vm_execute.h:2361 #1 0x00919b46 in execute (op_array=0x7fcee5293f78) at /home/patrick.allaert/Projets/php-src/Zend/zend_vm_execute.h:410 #2 0x008dbb61 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/patrick.allaert/Projets/php-src/Zend/zend.c:1272 #3 0x00852760 in php_execute_script (primary_file=0x7390c1a0) at /home/patrick.allaert/Projets/php-src/main/main.c:2414 #4 0x00a25095 in do_cli (argc=6, argv=0x7390c548) at /home/patrick.allaert/Projets/php-src/sapi/cli/php_cli.c:983 #5 0x00a25fad in main (argc=6, argv=0x7390c548) at /home/patrick.allaert/Projets/php-src/sapi/cli/php_cli.c:1356 -- Edit bug report at https://bugs.php.net/bug.php?id=60104&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60104&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60104&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60104&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60104&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60104&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60104&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60104&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60104&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60104&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60104&r=support Expected behavior: https://bugs.php.net/fix.php?id=60104&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60104&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60104&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60104&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60104&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60104&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60104&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60104&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60104&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60104&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60104&r=mysqlcfg
Bug #55760 [Bgs]: Can not load php_ldap.dll
Edit report at https://bugs.php.net/bug.php?id=55760&edit=1 ID: 55760 User updated by:mod4wb at heysoft dot de Reported by:mod4wb at heysoft dot de Summary:Can not load php_ldap.dll Status: Bogus Type: Bug Package:LDAP related Operating System: Windows PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Adding any path does not help, because on a fresh Windows, you will not find the files. So you need to download them from the internet and all will work. The problem is that the developer does have additional software (VC) on his machine, which installed the required files, and therefore he can not reproduce the problem. Installing a fresh Windows and checking whether his software runs there is not what one can expect from a super star. Sure php would run without the problem files (it did until them have been included, and dependency walker shows that no function from this dlls is ever used) but for this one would need to agree that a suboptimal solution has been delivered. Previous Comments: [2011-10-20 10:07:23] paj...@php.net no, see the windows documentation to know how to add it to your PATH, per user or system wide. [2011-10-20 09:48:02] ramki067 at gmail dot com Any update on the issue i faced? [2011-10-13 03:47:11] ramki067 at gmail dot com You have said in your earlier posts as, "Add the internet explorer directory to your path". Is this the solution to the problem? If yes, how where should the internet explorer path be added. Please advice. Thanks. [2011-10-12 10:53:51] paj...@php.net See my previous comment, not much we can do against that. Also to fix your setup is rather easy. [2011-10-12 10:32:07] ramki067 at gmail dot com Same problem here: Installed XAMPP 1.7.7 and enabled extension=php_ldap.dll in php.ini file in C:\xampp\php\php.ini path. After restarting apache, i'm getting an error: php_ldap.dll file could not be loaded. Module could not be found". The package has PHP 5.3.8 version. Is LDAP not supported or the support is not added in this PHP release? or am i missing something? Mods Please reply. 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=55760 -- Edit this bug report at https://bugs.php.net/bug.php?id=55760&edit=1
Bug #52144 [Com]: Error: Base lambda function for closure not found
Edit report at https://bugs.php.net/bug.php?id=52144&edit=1 ID: 52144 Comment by: s dot chernomorets at gmail dot com Reported by:taco at procurios dot nl Summary:Error: Base lambda function for closure not found Status: Open Type: Bug Package:Scripting Engine problem Operating System: linux PHP Version:5.3.2 Block user comment: N Private report: N New Comment: It seems option apc.write_lock=Off solves this problem partially. We have config with closure in style "" and include (not include_once) it seceral time per request. 1. If apc_cache_write_lock(apc_cache TSRMLS_CC) (apc_main.c:602) was unsuccessful at first include() then APC return old_compile_file. Function old_compile_file store compiled closures into internal zend hash function_table but not to cache. 2. If apc_cache_write_lock(apc_cache TSRMLS_CC) was successful at second include() then APC try to store opcode (apc_main.c:610-617), but function apc_copy_new_functions(apc_compile.c:1333,1340-1343) not found new functions (our closures) because zend hash function_table contains this closures already (closures were compiled at first include()). So APC copy compiled array from included file to cache without closures. 3. php-code try to call closure -> "Base lambda function for closure not found" Previous Comments: [2011-08-12 06:32:46] hchinchilla at habitissimo dot com We are having the same problem here at Habitissimo. using debian with PHP 5.3.6 and APC 3.1.9. We had to replace APC with xcache to avoid this problem. [2011-07-21 17:07:42] aequasi at gmail dot com Has this problem been resolved yet? having the same issues when i implement APC with symfony2 [2011-06-06 20:04:24] nicolas at netlog dot com Hi there, We're experiencing the same problem here at Netlog. Also on production servers when we have some load. Unable to isolate this issue yet. We're running php 5.3.5 and apc 3.1.9. If we disable APC the problem goes away. Any clues here? [2010-11-05 08:27:47] janne dot hietamaki at gmail dot com Updated to APC 3.1.5 and the problem still persists. [2010-11-05 08:14:07] janne dot hietamaki at gmail dot com I'm seeing this error quite often on our production servers. The problem seems to have something to do with APC cache, and after updating the files or apc_clear_cache() some random anonymous function call breaks at somewhere on our code. I can reproduce the error on our production server almost every time, but I have not yet been able to build a reproducible test case. It seems to be a concurrency issue, so the reproduction most probably requires concurrent APC cache clearing and lambda function calls. We're running PHP 5.3.3 with APC 3.1.4 on RHEL. I could try to upgrade to APC 3.1.5 next. Any help would be appreciated. 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=52144 -- Edit this bug report at https://bugs.php.net/bug.php?id=52144&edit=1
Bug #55737 [Com]: LOAD DATA LOCAL INFILE - The used command is not allowed with this MySQL versio
Edit report at https://bugs.php.net/bug.php?id=55737&edit=1 ID: 55737 Comment by: richardpq at gmail dot com Reported by:stefan dot kaifer at hartmann dot info Summary:LOAD DATA LOCAL INFILE - The used command is not allowed with this MySQL versio Status: Assigned Type: Bug Package:MySQL related Operating System: opensuse 11.0 PHP Version:5.3.8 Assigned To:mysql Block user comment: N Private report: N New Comment: "Some bug fix is planned for PHP 5.4", what is that mean? no solution for php 5.3? I would prefer a solution for this version, rather than wait for the final release of the new version, testing and see if it not affect others thing. Previous Comments: [2011-10-20 13:07:17] stefan dot kaifer at hartmann dot info Thanx, it's very good! [2011-10-20 12:57:34] denis_truffaut at hotmail dot com Some bug fix is planned for PHP 5.4 : http://php.net/releases/NEWS_5_4_0_beta1.txt - PDO MySQL driver: . Fixed bug #54158 (MYSQLND+PDO MySQL requires #define MYSQL_OPT_LOCAL_INFILE) (Andrey) [2011-10-19 02:30:15] richardpq at gmail dot com No, I dont have enable, my php.ini: ; open_basedir, if set, limits all file operations to the defined directory ; and below. This directive makes most sense if used in a per-directory ; or per-virtualhost web server configuration file. This directive is ; *NOT* affected by whether Safe Mode is turned On or Off. ; http://php.net/open-basedir ;open_basedir = Also has the first guy said... I can use LOAD DATA LOCAL INFILE, from MySql client but not from an application using PHP. [2011-10-18 20:23:34] and...@php.net mysqlnd allows LOAD DATA LOCAL in all cases but if open_basedir is enabled. If open_basedir is set it is disabled regardless where the file to be loaded resides. This might be too strict for shared envs. Do you have open_basedir enabled? [2011-10-18 16:27:34] denis_truffaut at hotmail dot com Related bugs : https://bugs.php.net/bug.php?id=46964 https://bugs.php.net/bug.php?id=54158 A PHP Dev said it was resolved in 5.3.6, but it came back. As it is a very common usage of MySQL, especialy to save/import data, it had to be fixed in priority. The override PDO::MYSQL_ATTR_LOCAL_INFILE => 1 also doesn't not work. What to do ?! :O 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=55737 -- Edit this bug report at https://bugs.php.net/bug.php?id=55737&edit=1
Bug #55737 [Fbk->Asn]: LOAD DATA LOCAL INFILE - The used command is not allowed with this MySQL versio
Edit report at https://bugs.php.net/bug.php?id=55737&edit=1 ID: 55737 User updated by:stefan dot kaifer at hartmann dot info Reported by:stefan dot kaifer at hartmann dot info Summary:LOAD DATA LOCAL INFILE - The used command is not allowed with this MySQL versio -Status: Feedback +Status: Assigned Type: Bug Package:MySQL related Operating System: opensuse 11.0 PHP Version:5.3.8 Assigned To:mysql Block user comment: N Private report: N New Comment: Thanx, it's very good! Previous Comments: [2011-10-20 12:57:34] denis_truffaut at hotmail dot com Some bug fix is planned for PHP 5.4 : http://php.net/releases/NEWS_5_4_0_beta1.txt - PDO MySQL driver: . Fixed bug #54158 (MYSQLND+PDO MySQL requires #define MYSQL_OPT_LOCAL_INFILE) (Andrey) [2011-10-19 02:30:15] richardpq at gmail dot com No, I dont have enable, my php.ini: ; open_basedir, if set, limits all file operations to the defined directory ; and below. This directive makes most sense if used in a per-directory ; or per-virtualhost web server configuration file. This directive is ; *NOT* affected by whether Safe Mode is turned On or Off. ; http://php.net/open-basedir ;open_basedir = Also has the first guy said... I can use LOAD DATA LOCAL INFILE, from MySql client but not from an application using PHP. [2011-10-18 20:23:34] and...@php.net mysqlnd allows LOAD DATA LOCAL in all cases but if open_basedir is enabled. If open_basedir is set it is disabled regardless where the file to be loaded resides. This might be too strict for shared envs. Do you have open_basedir enabled? [2011-10-18 16:27:34] denis_truffaut at hotmail dot com Related bugs : https://bugs.php.net/bug.php?id=46964 https://bugs.php.net/bug.php?id=54158 A PHP Dev said it was resolved in 5.3.6, but it came back. As it is a very common usage of MySQL, especialy to save/import data, it had to be fixed in priority. The override PDO::MYSQL_ATTR_LOCAL_INFILE => 1 also doesn't not work. What to do ?! :O [2011-10-03 21:08:08] richardpq at gmail dot com Hi I have exact the same problem, like you I compile php using those options, I have the same php version and mysql 5.5.15, have you resolve the problem? 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=55737 -- Edit this bug report at https://bugs.php.net/bug.php?id=55737&edit=1
Bug #55737 [Com]: LOAD DATA LOCAL INFILE - The used command is not allowed with this MySQL versio
Edit report at https://bugs.php.net/bug.php?id=55737&edit=1 ID: 55737 Comment by: denis_truffaut at hotmail dot com Reported by:stefan dot kaifer at hartmann dot info Summary:LOAD DATA LOCAL INFILE - The used command is not allowed with this MySQL versio Status: Feedback Type: Bug Package:MySQL related Operating System: opensuse 11.0 PHP Version:5.3.8 Assigned To:mysql Block user comment: N Private report: N New Comment: Some bug fix is planned for PHP 5.4 : http://php.net/releases/NEWS_5_4_0_beta1.txt - PDO MySQL driver: . Fixed bug #54158 (MYSQLND+PDO MySQL requires #define MYSQL_OPT_LOCAL_INFILE) (Andrey) Previous Comments: [2011-10-19 02:30:15] richardpq at gmail dot com No, I dont have enable, my php.ini: ; open_basedir, if set, limits all file operations to the defined directory ; and below. This directive makes most sense if used in a per-directory ; or per-virtualhost web server configuration file. This directive is ; *NOT* affected by whether Safe Mode is turned On or Off. ; http://php.net/open-basedir ;open_basedir = Also has the first guy said... I can use LOAD DATA LOCAL INFILE, from MySql client but not from an application using PHP. [2011-10-18 20:23:34] and...@php.net mysqlnd allows LOAD DATA LOCAL in all cases but if open_basedir is enabled. If open_basedir is set it is disabled regardless where the file to be loaded resides. This might be too strict for shared envs. Do you have open_basedir enabled? [2011-10-18 16:27:34] denis_truffaut at hotmail dot com Related bugs : https://bugs.php.net/bug.php?id=46964 https://bugs.php.net/bug.php?id=54158 A PHP Dev said it was resolved in 5.3.6, but it came back. As it is a very common usage of MySQL, especialy to save/import data, it had to be fixed in priority. The override PDO::MYSQL_ATTR_LOCAL_INFILE => 1 also doesn't not work. What to do ?! :O [2011-10-03 21:08:08] richardpq at gmail dot com Hi I have exact the same problem, like you I compile php using those options, I have the same php version and mysql 5.5.15, have you resolve the problem? [2011-09-20 09:49:56] stefan dot kaifer at hartmann dot info Description: Hello I've compiled php myself with this command: ./configure --with-mysql=mysqlnd --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd Now my php-applications can't use "LOAD DATA LOCAL INFILE '/tmp/import-20110919173927-78613.txt' INTO TABLE ..." anymore! On the command prompt I can use "LOAD DATA LOCAL INFILE", that means mysql server allows me to use "LOAD DATA LOCAL INFILE", the server variable "local infile" is setted to "ON" (with "local-infile=1" in the my.cnf). It seems a php-mysqlnd problem. Neither the mysql nor the mysqli extensions allows me to use "LOAD DATA LOCAL INFILE". This is the Connect-line in my code: $Connect = mysql_connect($DB_Host .":".$DB_Port,$DB_User,$DB_Password, FALSE, 128); The error is: #1148 - The used command is not allowed with this MySQL version Mysql-server: 5.5.16 PHP: 5.3.8 PHP-MYSQL-client: mysqlnd 5.0.8-dev - 20102224 - $Revision: 310735 $ PHPINFO: mysql MySQL Support enabled Active Persistent Links 0 Active Links0 Client API version mysqlnd 5.0.8-dev - 20102224 - $Revision: 310735 $ Directive Local Value Master Value mysql.allow_local_infileOn On mysql.allow_persistent Off Off mysql.connect_timeout 60 60 mysql.default_host no valueno value mysql.default_password no valueno value mysql.default_port no valueno value mysql.default_socketno valueno value mysql.default_user no valueno value mysql.max_links Unlimited Unlimited mysql.max_persistentUnlimited Unlimited mysql.trace_modeOff Off mysqli MysqlI Support enabled Client API library version mysqlnd 5.0.8-dev - 20102224 - $Revision: 310735 $ Active Persistent Links 0 Inactive Persistent Links 0 Active Links0 Directive Local Value Master Value mysqli.allow_local_infile On On mysqli.allow_persistent On On mysqli.default_host no valueno value mysqli.default_port 33063306 mysqli.default_pw no valueno value mysqli.default_socket no valueno value mysqli.default_user no valueno value mysqli.max_linksUnlimited Unlimited mysqli.max_persistent Unlimited Unlimited mysqli.reconnectOff Off mysqlnd mysqlnd enabled Version
Bug #54158 [Com]: MYSQLND + PDO MySQL requires #define MYSQL_OPT_LOCAL_INFILE
Edit report at https://bugs.php.net/bug.php?id=54158&edit=1 ID: 54158 Comment by: denis_truffaut at hotmail dot com Reported by:tamas at ideaweb dot hu Summary:MYSQLND + PDO MySQL requires #define MYSQL_OPT_LOCAL_INFILE Status: Closed Type: Bug Package:PDO related Operating System: Linux PHP Version:5.3.5 Assigned To:mysql Block user comment: N Private report: N New Comment: Some bug fix is planned for PHP 5.4 : http://php.net/releases/NEWS_5_4_0_beta1.txt - PDO MySQL driver: . Fixed bug #54158 (MYSQLND+PDO MySQL requires #define MYSQL_OPT_LOCAL_INFILE) (Andrey) Previous Comments: [2011-10-18 16:35:31] richardpq at gmail dot com I don't get it, after 5.3.6 release was working? because I have 5.3.8 and it is no working https://bugs.php.net/bug.php?id=55737 [2011-09-09 07:03:01] and...@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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. [2011-09-02 13:53:30] and...@php.net Automatic comment from SVN on behalf of andrey Revision: http://svn.php.net/viewvc/?view=revision&revision=316039 Log: Fix for Bug #54158 MYSQLND + PDO MySQL requires #define MYSQL_OPT_LOCAL_INFILE and a bunch of other small preprocessor fixes [2011-04-03 03:57:48] anthon dot pang at gmail dot com Sorry, you're right. My "workaround" is actually because MySQL is compiled with --enable-local-infile. [2011-04-03 01:08:09] anthon dot pang at gmail dot com As a workaround, I use PDO::ATTR_EMULATE_PREPARES. With 5.2.17 and 5.3.6 (using mysqlndb), both LOAD DATA INFILE and LOAD DATA LOCAL INFILE work on my Ubuntu 10.04 box, using PDO_MYSQL and MYSQLI extensions. 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=54158 -- Edit this bug report at https://bugs.php.net/bug.php?id=54158&edit=1
php-bugs@lists.php.net
Edit report at https://bugs.php.net/bug.php?id=60082&edit=1 ID: 60082 Updated by: larue...@php.net Reported by:tklingenberg at lastflood dot net Summary:100% CPU / when using references with ArrayObject(&$ref). Status: Assigned Type: Bug Package:SPL related Operating System: GNU/Linux PHP Version:5.3.8 Assigned To:helly Block user comment: N Private report: N New Comment: hmm, your patch seems better, agree. Previous Comments: [2011-10-20 05:46:43] tony2...@php.net I'd suggest to try to detect recursion in this case. Unfortunately, I don't see any way to do it except by adding another field to spl_array internal struct. But on the other hand, this struct is not used anywhere except spl_array.c itself, so it should be fine. The patch is attached. [2011-10-20 05:44:42] tony2...@php.net The following patch has been added/updated: Patch Name: recursion-detection Revision: 1319089482 URL: https://bugs.php.net/patch-display.php?bug=60082&patch=recursion-detection&revision=1319089482 [2011-10-19 02:28:53] larue...@php.net Automatic comment from SVN on behalf of laruence Revision: http://svn.php.net/viewvc/?view=revision&revision=318204 Log: Test for #60082 [2011-10-19 02:09:08] larue...@php.net helly, plz look at this. thanks :) [2011-10-18 12:51:03] larue...@php.net The following patch has been added/updated: Patch Name: bug60082.phpt Revision: 1318942263 URL: https://bugs.php.net/patch-display.php?bug=60082&patch=bug60082.phpt&revision=1318942263 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=60082 -- Edit this bug report at https://bugs.php.net/bug.php?id=60082&edit=1
Bug #60102 [Opn]: Incorrect behaviour when throwing an exception from __wakeup/autloading.
Edit report at https://bugs.php.net/bug.php?id=60102&edit=1 ID: 60102 User updated by:arjen at react dot com Reported by:arjen at react dot com Summary:Incorrect behaviour when throwing an exception from __wakeup/autloading. Status: Open Type: Bug Package:*General Issues Operating System: CentOS 5.6 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Testscript available @ http://home.react.com/~arjen/testcase.tar.gz Because of multiple files. Previous Comments: [2011-10-20 11:57:20] arjen at react dot com Description: When unserializing an object Wakeup with an member b object which throws an exception in __wakeup, the autoloading of member e of type e extends d fails. The thrown exception is also non-catchable. Expected result: loading Wakeup loaded Wakeup: 1 loading B loaded B: 1 loading E loading D loaded D: 1 loading E: 1 fail Actual result: -- loading Wakeup loaded Wakeup: 1 loading B loaded B: 1 loading E loading D loaded D: 1 Fatal error: Uncaught exception 'Exception' in testcase/B.php on line 5 -- Edit this bug report at https://bugs.php.net/bug.php?id=60102&edit=1
[PHP-BUG] Bug #60102 [NEW]: Incorrect behaviour when throwing an exception from __wakeup/autloading.
From: Operating system: CentOS 5.6 PHP version: 5.3.8 Package: *General Issues Bug Type: Bug Bug description:Incorrect behaviour when throwing an exception from __wakeup/autloading. Description: When unserializing an object Wakeup with an member b object which throws an exception in __wakeup, the autoloading of member e of type e extends d fails. The thrown exception is also non-catchable. Expected result: loading Wakeup loaded Wakeup: 1 loading B loaded B: 1 loading E loading D loaded D: 1 loading E: 1 fail Actual result: -- loading Wakeup loaded Wakeup: 1 loading B loaded B: 1 loading E loading D loaded D: 1 Fatal error: Uncaught exception 'Exception' in testcase/B.php on line 5 -- Edit bug report at https://bugs.php.net/bug.php?id=60102&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60102&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60102&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60102&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60102&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60102&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60102&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60102&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60102&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60102&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60102&r=support Expected behavior: https://bugs.php.net/fix.php?id=60102&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60102&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60102&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60102&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60102&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60102&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60102&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60102&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60102&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60102&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60102&r=mysqlcfg
Bug #60092 [Opn]: inappropriate use of st_blksize and st_blocks
Edit report at https://bugs.php.net/bug.php?id=60092&edit=1
ID: 60092
User updated by:jojo at hp dot com
Reported by:jojo at hp dot com
Summary:inappropriate use of st_blksize and st_blocks
Status: Open
Type: Bug
Package:Compile Failure
Operating System: HP NonStop
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Patch attached now
Previous Comments:
[2011-10-19 13:11:13] jojo at hp dot com
Description:
using st_blksite and st_blocks outside of HAVE_ST_BLKSIZE resp. HABE_ST_BLOCKS
in several files, uses !PHP_WIN32 resp. !__BEOS__ instead:
...ext/phar/function_interceptors.c
...ext/phar/stream.c
...ext/sqlite3/libsqlite/sqlite3.c
...main/streams/memory.c
This of course fails on platforms other than WIN32 or BEOS that don't have
these, like uin my cace, HP NonStop ("#ifdef __TANDEM").
--
Edit this bug report at https://bugs.php.net/bug.php?id=60092&edit=1
Bug #60093 [Opn]: HP NonStop not detected by configure
Edit report at https://bugs.php.net/bug.php?id=60093&edit=1 ID: 60093 User updated by:jojo at hp dot com Reported by:jojo at hp dot com Summary:HP NonStop not detected by configure Status: Open Type: Bug Package:Compile Failure Operating System: HP NonStop PHP Version:5.3.8 Block user comment: N Private report: N New Comment: You could also use the attached patch. Previous Comments: [2011-10-19 13:14:24] jojo at hp dot com Description: HP NonStop not detected by configure Newer configure versions have been fixed, so please get and use a newer one -- Edit this bug report at https://bugs.php.net/bug.php?id=60093&edit=1
Bug #55760 [Bgs]: Can not load php_ldap.dll
Edit report at https://bugs.php.net/bug.php?id=55760&edit=1 ID: 55760 Updated by: paj...@php.net Reported by:mod4wb at heysoft dot de Summary:Can not load php_ldap.dll Status: Bogus Type: Bug Package:LDAP related Operating System: Windows PHP Version:5.3.8 Block user comment: N Private report: N New Comment: no, see the windows documentation to know how to add it to your PATH, per user or system wide. Previous Comments: [2011-10-20 09:48:02] ramki067 at gmail dot com Any update on the issue i faced? [2011-10-13 03:47:11] ramki067 at gmail dot com You have said in your earlier posts as, "Add the internet explorer directory to your path". Is this the solution to the problem? If yes, how where should the internet explorer path be added. Please advice. Thanks. [2011-10-12 10:53:51] paj...@php.net See my previous comment, not much we can do against that. Also to fix your setup is rather easy. [2011-10-12 10:32:07] ramki067 at gmail dot com Same problem here: Installed XAMPP 1.7.7 and enabled extension=php_ldap.dll in php.ini file in C:\xampp\php\php.ini path. After restarting apache, i'm getting an error: php_ldap.dll file could not be loaded. Module could not be found". The package has PHP 5.3.8 version. Is LDAP not supported or the support is not added in this PHP release? or am i missing something? Mods Please reply. Thanks. [2011-09-29 14:25:08] nrenou at free dot fr Same problem : With xampp 1.7.7 on a Windows 2003 Server, if you enable php_ldap.dll, Apache won't start ssleay32.dll, libeay32.dll, libsasl.sll and php5ts.dll are in c:\xampp\php and Apache doesn't start if you don't copy these files into c:\xampp\php\ext (the same folder than php_ldap.dll) Regards 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=55760 -- Edit this bug report at https://bugs.php.net/bug.php?id=55760&edit=1
Bug #40913 [Com]: PDO::PARAM_LOB does not bind to a stream for fetching a BLOB
Edit report at https://bugs.php.net/bug.php?id=40913&edit=1 ID: 40913 Comment by: oridan82 at gmail dot com Reported by:dennis at inmarket dot lviv dot ua Summary:PDO::PARAM_LOB does not bind to a stream for fetching a BLOB Status: Closed Type: Bug Package:PDO related Operating System: Win XP PHP Version:5.2.6 Assigned To:mysql Block user comment: N Private report: N New Comment: PHP 5.3.5 PARAM_LOB is returning a string instead of a stream. Code: - $stmt = $conn->prepare($qry); $stmt->bindValue(1, $_GET['id']); $stmt->bindValue(2, $_GET['aid']); $stmt->execute(); $stmt->bindColumn(4, $mimeType, PDO::PARAM_STR, 256); $stmt->bindColumn(6, $lob, PDO::PARAM_LOB); $stmt->fetch(PDO::FETCH_BOUND); echo gettype($lob); Expected Result: resource Actual Result: -- string Previous Comments: [2011-01-04 13:21:09] u...@php.net See last comment, works with 5.3.4 [2010-12-27 01:02:32] php at paloch dot net Seems to be fixed in 5.3.4 final. I was struggling with this issue (and PHP 5.2.16) all evening before finding this post. I tried installing PHP 5.3.4 and voila, problem solved. [2010-11-22 10:43:16] u...@php.net 5.2 only gets security fixes, if at all. Can this be reproduced with 5.3.4-RC, using libmysql (recent one!), using mysqlnd? [2010-10-05 18:10:13] samuel at ingessons dot se And another reason why I need a stream and not a string is that a string would consume all the memory for a large object. [2010-10-05 17:23:46] samuel at ingessons dot se The reason why I want to have a stream and not echo it directly is that I use a function that should return a stream. 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=40913 -- Edit this bug report at https://bugs.php.net/bug.php?id=40913&edit=1
Bug #55760 [Com]: Can not load php_ldap.dll
Edit report at https://bugs.php.net/bug.php?id=55760&edit=1 ID: 55760 Comment by: ramki067 at gmail dot com Reported by:mod4wb at heysoft dot de Summary:Can not load php_ldap.dll Status: Bogus Type: Bug Package:LDAP related Operating System: Windows PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Any update on the issue i faced? Previous Comments: [2011-10-13 03:47:11] ramki067 at gmail dot com You have said in your earlier posts as, "Add the internet explorer directory to your path". Is this the solution to the problem? If yes, how where should the internet explorer path be added. Please advice. Thanks. [2011-10-12 10:53:51] paj...@php.net See my previous comment, not much we can do against that. Also to fix your setup is rather easy. [2011-10-12 10:32:07] ramki067 at gmail dot com Same problem here: Installed XAMPP 1.7.7 and enabled extension=php_ldap.dll in php.ini file in C:\xampp\php\php.ini path. After restarting apache, i'm getting an error: php_ldap.dll file could not be loaded. Module could not be found". The package has PHP 5.3.8 version. Is LDAP not supported or the support is not added in this PHP release? or am i missing something? Mods Please reply. Thanks. [2011-09-29 14:25:08] nrenou at free dot fr Same problem : With xampp 1.7.7 on a Windows 2003 Server, if you enable php_ldap.dll, Apache won't start ssleay32.dll, libeay32.dll, libsasl.sll and php5ts.dll are in c:\xampp\php and Apache doesn't start if you don't copy these files into c:\xampp\php\ext (the same folder than php_ldap.dll) Regards [2011-09-22 11:15:46] paj...@php.net And for the record here: it is a dependency of Crypt32.dll which is used by libsasl.dll. 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=55760 -- Edit this bug report at https://bugs.php.net/bug.php?id=55760&edit=1
Bug #55840 [Opn->Bgs]: phpinfo() outputs differently if output_buffer is used
Edit report at https://bugs.php.net/bug.php?id=55840&edit=1 ID: 55840 Updated by: m...@php.net Reported by:jamess at sharklasers dot com Summary:phpinfo() outputs differently if output_buffer is used -Status: Open +Status: Bogus Type: Bug Package:PHP options/info functions Operating System: WinXP SP3 PHP Version:5.3.8 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 Your browser sends Cache-Control if you reload the page. Previous Comments: [2011-10-03 19:33:12] jamess at sharklasers dot com Description: phpinfo() outputs differently than if its contents are being captured with output buffer. Test script: --- Actual result: *Example1: *Example2: ob_start(); phpinfo(); $i=ob_get_clean(); echo $i; ?> Expected Result: *Example 1: *Example 2: Expected result: * Apache Environment: HTTP_CACHE_CONTROL is not present. * HTTP Headers Information: HTTP Request Headers: Cache-Control is not present. * HTTP Headers Information: HTTP Response Headers: Keep-Alive, Connection, Transfer-Encoding, Content-Type are present. Actual result: -- * Apache Environment: HTTP_CACHE_CONTROL is present. * HTTP Headers Information: HTTP Request Headers: Cache-Control is present. * HTTP Headers Information: HTTP Response Headers: Keep-Alive, Connection, Transfer-Encoding, Content-Type are not present. -- Edit this bug report at https://bugs.php.net/bug.php?id=55840&edit=1
Bug #21918 [Com]: strange behaviour of mixed type in array-keys
Edit report at https://bugs.php.net/bug.php?id=21918&edit=1
ID: 21918
Comment by: sushant dot d84 at gmail dot com
Reported by:messju at lammfellpuschen dot de
Summary:strange behaviour of mixed type in array-keys
Status: Closed
Type: Bug
Package:Scripting Engine problem
Operating System: *
PHP Version:4.3.3-RC3/5.0.0b2
Assigned To:zeev
Block user comment: N
Private report: N
New Comment:
I have an array which I use for long Binary Tree. I am pasting the array here
which shows the negative key.
The code was very general
$i=0;
while ($MyCondition)
{
$i=$i*2+1;
temparray[$i]= $MyItem;
$i=$i*2+2;
temparray[$i]= $MyItem;
}
and the output has one negative key in it..
"[-2147483648] =>"
Thanks and Regards
Sushant Danekar
http://Splendornet.com
http://vidility.com/blog
Previous Comments:
[2011-10-20 07:18:41] sushant dot d84 at gmail dot com
I have an array which I use for long Binary Tree. I am pasting the array here
which shows the negative key.
The code was very general
$i=0;
while ($MyCondition)
{
$i=$i*2+1;
temparray[$i]= $MyItem;
$i=$i*2+2;
temparray[$i]= $MyItem;
}
and the output has one negative key in it..
"[-2147483648] =>"
[2003-08-13 13:44:09] he...@php.net
Well i didn't mean to shout or something like that :-)
I reopened the bug because the part of the fix removed was for documentation
consistency. And i didn't want to open a new bug on this.
To be precise: "A key may be either an integer or a string. If a key is the
standard representation of an integer, it will be interpreted as such (i.e. "8"
will be interpreted as 8, while "08" will be interpreted as "08"). There are no
different indexed and associative array types in PHP; there is only one array
type, which can both contain integer and string indices." (1)
The above is the exact purpose of this bug and is fixed now.
The inconsistency lies in this: "If you do not specify a key for a given value,
then the maximum of the integer indices is taken, and the new key will be that
maximum value + 1. If you specify a key that already has a value assigned to
it, that value will be overwritten." (2)
While the documentation says: "As of PHP 4.3.0, the index generation behaviour
described above has changed. Now, if you append to an array in which the
current maximum key is negative, then the next key created will be zero (0).
Before, the new index would have been set to the largest existing key + 1, the
same as positive indices are." (3)
Since (1) and (2) were broken in PHP 4.3 i didn't really care about the note
(3). If we leave the things as they are now (1) throughtout (3) match. However
i like the behavior without (3) more since it is consistent and more logically.
[2003-08-13 04:18:46] sni...@php.net
Zeev is right about this being the wrong bug reopened, this is (still) fixed in
CVS.
[2003-08-13 02:55:03] z...@php.net
It's not 'broken' again, what I reverted had nothing to do with this bug. Look
at the diff before you start shouting!
I'm still not sure if we'll keep the auto conversion for negative numbers. My
preference is to fix the docs, since all sorts of other notations don't work,
and we have no intention on making them work (e.g., $foo["+7"], $foo["3.5"],
etc.
[2003-08-12 18:45:55] sni...@php.net
Zeev could at least explain WHY he reverted the fix..
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=21918
--
Edit this bug report at https://bugs.php.net/bug.php?id=21918&edit=1
Bug #21918 [Com]: strange behaviour of mixed type in array-keys
Edit report at https://bugs.php.net/bug.php?id=21918&edit=1
ID: 21918
Comment by: sushant dot d84 at gmail dot com
Reported by:messju at lammfellpuschen dot de
Summary:strange behaviour of mixed type in array-keys
Status: Closed
Type: Bug
Package:Scripting Engine problem
Operating System: *
PHP Version:4.3.3-RC3/5.0.0b2
Assigned To:zeev
Block user comment: N
Private report: N
New Comment:
I have an array which I use for long Binary Tree. I am pasting the array here
which shows the negative key.
The code was very general
$i=0;
while ($MyCondition)
{
$i=$i*2+1;
temparray[$i]= $MyItem;
$i=$i*2+2;
temparray[$i]= $MyItem;
}
and the output has one negative key in it..
"[-2147483648] =>"
Previous Comments:
[2003-08-13 13:44:09] he...@php.net
Well i didn't mean to shout or something like that :-)
I reopened the bug because the part of the fix removed was for documentation
consistency. And i didn't want to open a new bug on this.
To be precise: "A key may be either an integer or a string. If a key is the
standard representation of an integer, it will be interpreted as such (i.e. "8"
will be interpreted as 8, while "08" will be interpreted as "08"). There are no
different indexed and associative array types in PHP; there is only one array
type, which can both contain integer and string indices." (1)
The above is the exact purpose of this bug and is fixed now.
The inconsistency lies in this: "If you do not specify a key for a given value,
then the maximum of the integer indices is taken, and the new key will be that
maximum value + 1. If you specify a key that already has a value assigned to
it, that value will be overwritten." (2)
While the documentation says: "As of PHP 4.3.0, the index generation behaviour
described above has changed. Now, if you append to an array in which the
current maximum key is negative, then the next key created will be zero (0).
Before, the new index would have been set to the largest existing key + 1, the
same as positive indices are." (3)
Since (1) and (2) were broken in PHP 4.3 i didn't really care about the note
(3). If we leave the things as they are now (1) throughtout (3) match. However
i like the behavior without (3) more since it is consistent and more logically.
[2003-08-13 04:18:46] sni...@php.net
Zeev is right about this being the wrong bug reopened, this is (still) fixed in
CVS.
[2003-08-13 02:55:03] z...@php.net
It's not 'broken' again, what I reverted had nothing to do with this bug. Look
at the diff before you start shouting!
I'm still not sure if we'll keep the auto conversion for negative numbers. My
preference is to fix the docs, since all sorts of other notations don't work,
and we have no intention on making them work (e.g., $foo["+7"], $foo["3.5"],
etc.
[2003-08-12 18:45:55] sni...@php.net
Zeev could at least explain WHY he reverted the fix..
[2003-08-12 15:46:46] he...@php.net
Broken again
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=21918
--
Edit this bug report at https://bugs.php.net/bug.php?id=21918&edit=1
