[PHP-BUG] Bug #61820 [NEW]: using ob_gzhandler will complain about headers already sent when no compression
From: Operating system: Linux PHP version: 5.4.0 Package: Zlib related Bug Type: Bug Bug description:using ob_gzhandler will complain about headers already sent when no compression Description: When using ob_gzhandler with PHP 5.4.0+, PHP will emit warnings after flushing more than once (it looks like it's trying to modify headers on each flush). This problem didn't exist in PHP 5.3. Test script: --- https://bugs.php.net/bug.php?id=61820&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61820&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61820&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61820&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61820&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61820&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61820&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61820&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61820&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61820&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61820&r=support Expected behavior: https://bugs.php.net/fix.php?id=61820&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61820&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61820&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61820&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61820&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61820&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61820&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61820&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61820&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61820&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61820&r=mysqlcfg
[PHP-BUG] Bug #61821 [NEW]: Using ob_start() + zlib.output_compression makes it impossible to flush output
From:
Operating system: Linux
PHP version: 5.4.0
Package: Zlib related
Bug Type: Bug
Bug description:Using ob_start() + zlib.output_compression makes it impossible
to flush output
Description:
When using ob_start() followed by a ini_set('zlib.output_compression',
true),
using ob_flush() won't output anything, even if no zlib compression will
happen.
This is a new bug since PHP 5.4.0, maybe linked to #61820
Test script:
---
https://bugs.php.net/bug.php?id=61821&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61821&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61821&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61821&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61821&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61821&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61821&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61821&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61821&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61821&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61821&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61821&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61821&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61821&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61821&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61821&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61821&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61821&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61821&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61821&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61821&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61821&r=mysqlcfg
#48867 [NEW]: Casting 0xffffffffffffffff to int does not returns -1
From: [email protected] Operating system: Linux x86_64 PHP version: 5.2.10 PHP Bug Type: Scripting Engine problem Bug description: Casting 0x to int does not returns -1 Description: Casting hexadecimal representation of -1 to int is supposed to return -1 in php. It seems to not reproduce on sunOS. sapi/cli/php -r 'var_dump((int)0x);' int(-1) SunOS t2000-010131 5.11 snv_101 sun4v sparc SUNW,Sun-Fire-T200 Solaris It was reproduced on the following distro of Linux: Gentoo, Arch It was also reproduced on a self-compiled version of PHP 5.2.10 Reproduce code: --- magical...@memol ~ $ php -r 'var_dump((int)0x);' Expected result: int(-1) Actual result: -- int(0) -- Edit bug report at http://bugs.php.net/?id=48867&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48867&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48867&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48867&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48867&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48867&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48867&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48867&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48867&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48867&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48867&r=support Expected behavior: http://bugs.php.net/fix.php?id=48867&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48867&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48867&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48867&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48867&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48867&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48867&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48867&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48867&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48867&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48867&r=mysqlcfg
#49203 [NEW]: call_user_func_array when calling a parent constructor not from a user class
From: [email protected] Operating system: Linux x86_64 PHP version: 5.3.0 PHP Bug Type: Scripting Engine problem Bug description: call_user_func_array when calling a parent constructor not from a user class Description: When using: call_user_func_array(array('parent', '__construct'), $var); This works if the parent is a user-defined class, but not if it's an extension-provided class (the extended constructor gets called twice). This is not easy to explain, see attached reproduce code for more details. My initial code was (in a class extending mysqli): private function __construct($params) { call_user_func_array(array('parent', '__construct'), $params); $this->set_charset('utf8'); } Using this instead awfully fixes the problem: parent::__construct($params[0], $params[1], $params[2], $params[3]); Note that this wasn't possible in PHP 5.2.x Warning: call_user_func_array(): First argument is expected to be a valid callback, 'parent::__construct' was given in foo.php on line 5 Reproduce code: --- http://bugs.php.net/?id=49203&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49203&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49203&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49203&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49203&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49203&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49203&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49203&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49203&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49203&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49203&r=support Expected behavior: http://bugs.php.net/fix.php?id=49203&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49203&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49203&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49203&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49203&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49203&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49203&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49203&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49203&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49203&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49203&r=mysqlcfg
#49204 [NEW]: Late Static Binding class name problem
From: [email protected] Operating system: Linux x86_64 PHP version: 5.3.0 PHP Bug Type: Scripting Engine problem Bug description: Late Static Binding class name problem Description: In some cases the class name as returned by get_called_class() is incorrect. Can't explain this clearly without more sleep, but the following reproduction code should help understanding the problem. I tried to simplify the code, but the bug disappears in this case. Expected behaviour is to have class C constructed, then class B constructed, with a nice "Here is B\n" displayed. In reality the B::getInstance() static call done from C::__construct doesn't change the classname for LSB, meaning that when Singleton::getInstance() will call get_called_class() it will receive "C" (and letting us enter into an infinite recursion). Reproduce code: --- http://bugs.php.net/?id=49204&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49204&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49204&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49204&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49204&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49204&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49204&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49204&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49204&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49204&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49204&r=support Expected behavior: http://bugs.php.net/fix.php?id=49204&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49204&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49204&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49204&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49204&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49204&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49204&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49204&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49204&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49204&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49204&r=mysqlcfg
#46832 [NEW]: memleak on handles duplicated with curl_copy_handle()
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 5.2CVS-2008-12-11 (CVS) PHP Bug Type: cURL related Bug description: memleak on handles duplicated with curl_copy_handle() Description: When an handle is copied with curl_copy_handle(), its ability to free memory used by strings is disabled. In ext/curl/interface.c near line 1215 : zend_llist_copy(&dupch->to_free.str, &ch->to_free.str); /* Don't try to free copied strings, they're free'd when the original handle is destroyed */ dupch->to_free.str.dtor = NULL; zend_llist_copy(&dupch->to_free.slist, &ch->to_free.slist); zend_llist_copy(&dupch->to_free.post, &ch->to_free.post); 1. New strings allocated by this new handle will have "NULL" as dtor 2. slist and post will still be free'd on both handles. Freeing one handle first also probably breaks the second handle 3. The copied handle will have unexpected behaviour with libcurl <7.17.0 if the source handle is freed before the copied handle. Two options exists here: 1. Disable this function for people who don't have at least libcurl 7.17.0, and let libcurl handle duplication of strings, etc.. (it now does this automatically, cf bug #45161). 2. Manually duplicate all options that are set in the source curl handle and register them in newly allocated handle on curl_copy_handle(). This can lead to errors as we do not keep record of all set options. Reproduce code: --- http://localhost/test/tset/est'); curl_close($ch2); var_dump(memory_get_usage()); } Expected result: (always the same int dumped) Actual result: -- [...] int(415128) int(415256) int(415384) int(415512) int(415640) int(415768) int(415896) int(416024) int(416152) int(416280) int(416408) int(416536) int(416664) [Thu Dec 11 06:50:37 2008] Script: 'curl_memleak.php' ext/curl/interface.c(1342) : Freeing 0x0198CB78 (31 bytes), script=curl_memleak.php Last leak repeated 2047 times === Total 2048 memory leaks detected === -- Edit bug report at http://bugs.php.net/?id=46832&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46832&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46832&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46832&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46832&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46832&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46832&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46832&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46832&r=needscript Try newer version: http://bugs.php.net/fix.php?id=46832&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46832&r=support Expected behavior: http://bugs.php.net/fix.php?id=46832&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46832&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46832&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46832&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46832&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46832&r=dst IIS Stability: http://bugs.php.net/fix.php?id=46832&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46832&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46832&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46832&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46832&r=mysqlcfg
#51056 [NEW]: fread() on blocking stream will block even if data is available
From: [email protected] Operating system: Linux Gentoo 2.6.32 PHP version: 5.3.1 PHP Bug Type: Streams related Bug description: fread() on blocking stream will block even if data is available Description: On a blocking stream, a call to fread() will return even if the passed buffer size has not been reached. A call to fread() should return immediatly if there is data pending to be read (buffered by php). Instead of that, php will call poll() on the stream to wait for more data to arrive, then will return the previously read data and the new data. Suggestion: if fread() is called on a blocking stream that already contains data, PHP should call poll() with a 0 timeout, read any newly available data and return immediatly. If no data is currently in PHP's internal buffer, current behaviour can be kept. (it is also possible to skip completly the poll() part and directly return any pending data without checking if the real stream has anything, but I believe that it might not be as logical, a call to fread() should read) Reproduce code: --- 0) { // parent fclose($pair[0]); while(!feof($pair[1])) { $start = microtime(true); $data = fread($pair[1], 256); printf("fread took %01.2fms to read %d bytes\n", (microtime(true)-$start)*1000, strlen($data)); } exit; } // child fclose($pair[1]); while(!feof($pair[0])) { fwrite($pair[0], "Hello 1\n"); // 8 bytes usleep(5000); fwrite($pair[0], str_repeat('a', 300)."\n"); // 301 bytes sleep(1); } Expected result: Testing PHP version: 5.3.1 fread took 0.09ms to read 8 bytes fread took 5.08ms to read 256 bytes fread took 0.00ms to read 45 bytes fread took 1000.10ms to read 8 bytes fread took 5.04ms to read 256 bytes fread took 0.00ms to read 45 bytes fread took 1000.10ms to read 8 bytes fread took 5.04ms to read 256 bytes (etc) Actual result: -- Testing PHP version: 5.3.1 fread took 0.09ms to read 8 bytes fread took 5.08ms to read 256 bytes fread took 1000.10ms to read 53 bytes fread took 5.04ms to read 256 bytes fread took 1000.10ms to read 53 bytes fread took 5.04ms to read 256 bytes (etc) -- Edit bug report at http://bugs.php.net/?id=51056&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51056&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51056&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51056&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51056&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51056&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51056&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51056&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51056&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51056&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51056&r=support Expected behavior: http://bugs.php.net/fix.php?id=51056&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51056&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51056&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51056&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51056&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51056&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51056&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51056&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51056&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51056&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51056&r=mysqlcfg
[PHP-BUG] Req #51295 [NEW]: SQLite3::busyTimeout not existing
From: magicaltux Operating system: Linux Gentoo 2.6.33 PHP version: 5.3SVN-2010-03-14 (SVN) Package: SQLite related Bug Type: Feature/Change Request Bug description:SQLite3::busyTimeout not existing Description: In SQLite3, method busyTimeout() is missing, and by default there is no busy handler. In old SQLite extension, a default timeout of 60 seconds was set, and a busyTimeout() method was available to define the timeout. I recently started with SQLite3 to have this kind of errors as load was growing on SELECT statement: Warning: SQLite3Stmt::execute(): Unable to execute statement: database is locked Some internet research showed that this could be fixed by setting a different busy timeout, and I noticed PHP wasn't setting any on SQLite3. While I'm unsure about setting a default busyTimeout on SQLite3 (it currently have none, but PHP_5_3 is still young enough to change this kind of behaviour) it should be at least possible to set one. Patch to add a SQLite3::busyTimeout() method (same behaviour as old SQLite::busyTimeout() method, with the exception this one has a true/false return value, while sqlite3_busy_timeout will always return SQLITE_OK, it may change in the future). The patch: https://ookoo.org/svn/snip/php_5_3-sqlite3-busytimeout-method.patch -- Edit bug report at http://bugs.php.net/bug.php?id=51295&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51295&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51295&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51295&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51295&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51295&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51295&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51295&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51295&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51295&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51295&r=support Expected behavior: http://bugs.php.net/fix.php?id=51295&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51295&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51295&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51295&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51295&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51295&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51295&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51295&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51295&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51295&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51295&r=mysqlcfg
Req #51353 [Com]: ZIP64 problem
Edit report at http://bugs.php.net/bug.php?id=51353&edit=1 ID: 51353 Comment by: [email protected] Reported by:niculaantoniu at yahoo dot com Summary:ZIP64 problem Status: Assigned Type: Feature/Change Request Package:Zip Related Operating System: ANY PHP Version:5.3.2 Assigned To:pajoye Block user comment: N Private report: N New Comment: Precision: PHP seems to be able to open files with more than 65535 files, but will only be able to access the 65535 first files in the archive. libzip is BSD. The related diff (adding support for archives with more than 65535 files) it at: http://hg.nih.at/libzip/?cs=daa140b84947 Previous Comments: [2010-03-22 21:16:32] niculaantoniu at yahoo dot com Description: You can not decompress ZIP64 files (zip files with more than 64k entries) The libzip >= 0.9.1 does support more than 64k entries. Test script: --- No need for test script just read the libzip news section: http://nih.at/libzip/NEWS.html The libzip >= 0.9.1 does support more than 64k entries. -- Edit this bug report at http://bugs.php.net/bug.php?id=51353&edit=1
