Req #38025 [Com]: Missing stream wrapper methods
Edit report at http://bugs.php.net/bug.php?id=38025&edit=1 ID: 38025 Comment by: james at gogo dot co dot nz Reported by: flconseil at yahoo dot fr Summary: Missing stream wrapper methods Status: Open Type: Feature/Change Request Package: Feature/Change Request Operating System: All PHP Version: 5.1.4 New Comment: I will add also that if touch() gets called with a (normally stream wrapped) URL, it actually attempts to touch a file by that name on the local file system, most likely unsuccessfully (producing a WARNING) but there is no particular reason why it could not be successful in some situation. Better/safer behavior would be to give an ERROR that you are trying to touch a stream wrapped file which can't be touched (or preferably of course, implement the ability for stream wrappers to accommodate touch()). Previous Comments: [2010-06-25 18:36:28] james at gogo dot co dot nz In the 4 years since this bug/feature request was reported, flock() has been implemented. I can not see any documentation to indicate that touch(), chmod() etc... are possible to implement with stream wrappers yet. url_stat() is able to provide read access for these data points, but there is no means to provide the write access. [2006-07-06 16:59:40] flconseil at yahoo dot fr Description: The following functions cannot be implemented in a stream wrapper because the corresponding methods don't exist : - chgrp & lchgrp - chown &lchown - chmod - flock - link & symlink/readlink - touch To be confirmed for : - ftruncate - realpath For most of these (links, owner, mode), as the values can be returned by stat/lstat() calls, PHP should provide a way to set/modify them. -- Edit this bug report at http://bugs.php.net/bug.php?id=38025&edit=1
Bug #51610 [Com]: 1 second+ needed for OCI8 versus PDO/oci to open/close connection and exit
Edit report at http://bugs.php.net/bug.php?id=51610&edit=1
ID: 51610
Comment by: marioroy at verizon dot net
Reported by: marioroy at verizon dot net
Summary: 1 second+ needed for OCI8 versus PDO/oci to open/close
connection and exit
Status: Wont fix
Type: Bug
Package: OCI8 related
Operating System: Linux & Snow Leopard
PHP Version: 5.3SVN-2010-04-20 (snap)
Assigned To: sixd
New Comment:
I have applied this patch to oci8.c. It resolves the issue for me. I
set
use_spool to 0. Can we have use_spool enabled/disabled via an oci8.ini
directive. Thanks.
@@ -1711,7 +1693,7 @@
smart_str hashed_details = {0};
time_t timestamp;
php_oci_spool *session_pool = NULL;
- zend_bool use_spool = 1; /* Default is to use
client-side
session pool */
+ zend_bool use_spool = 0; /* Default is to use
client-side
session pool */
zend_bool ping_done = 0;
Previous Comments:
[2010-06-18 04:19:45] s...@php.net
The PHP OCI8 code changes in question have been in production for two
years. They were introduced to support Database Resident Connection
Pooling and FAN for scalability in web apps. The dominant use cases
for SQL*Plus and PHP are very different.
[2010-06-17 15:29:25] chris at leaflock dot net
I filed a duplicate bug, but I noticed something unique; It doesn't
happen with Oracle 10.2.0.3.
I'm pretty unhappy about this, what is the benefit and/or requirement
for this behavior, and why does it not happen in 10.2.0.3?
Oracle's own SQLPlus doesn't display this behavior. I never thought I'd
see the day when SQLPlus could do something faster for me than PHP.
[2010-04-22 00:33:09] marioroy at verizon dot net
Thank you for the feedback.
[2010-04-21 18:31:34] s...@php.net
This is expected. There is a shutdown cost at process termination from
closing
a timer thread needed by the connection rearchitecture of OCI8 1.3.
Most deployments either do not start and stop PHP processes frequently,
or are
not sensitive to the time between completing the work of the script and
the
termination of the process.
It's possible that PDO_OCI may be changed in future and might get the
same
behaviour.
[2010-04-20 05:24:44] marioroy at verizon dot net
Description:
Is this normal to see the native OCI8 1.3.5 or later requiring
additional time to
run code snippet shown below when accessing Oracle 10.2.0.4. I'm seeing
this at
work as well (SUSE Linux). Therefore, I have stayed with OCI8 1.2.5 for
the
moment.
Notice how the time is the same when using the PDO/OCI interface.
Test script:
---
# Native OCI8 Performance:
#
# PHP 5.2.14 201004191430, OCI8 1.2.5: ~ 0.15 seconds ;this is nice
#
# PHP 5.3.3 201004191430, OCI8 1.2.5: ~ 0.25 seconds ;takes 0.1 extra
here
# PHP 5.3.3 201004191430, OCI8 1.3.5: ~ 1.20 seconds ;slowness begins
when
# PHP 5.3.3 201004191430, OCI8 1.4.1: ~ 1.20 seconds ;script exits for
1.3.5+
# PHP 5.3.3 201004191430, OCI8 1.4.2: ~ 1.20 seconds
# PDO/OCI Performance:
#
# PHP 5.2.14 201004191430, OCI8 1.2.5: ~ 0.15 seconds ;very fast
#
# PHP 5.3.3 201004191430, OCI8 1.2.5: ~ 0.15 seconds ;same as PHP
5.2.14 :)
# PHP 5.3.3 201004191430, OCI8 1.3.5: ~ 0.15 seconds ;very happy to
see this
# PHP 5.3.3 201004191430, OCI8 1.4.1: ~ 0.15 seconds ;with 1.3.5+
# PHP 5.3.3 201004191430, OCI8 1.4.2: ~ 0.15 seconds
getMessage(),
E_USER_ERROR);
}
$conn = NULL;
exit;
?>
Expected result:
I'm hoping that PHP 5.3.2+ with OCI8 1.4.1+ can perform as fast as PHP
5.2.13 with
OCI8 1.2.5 when using the native driver. This is why I have stayed with
1.2.5 at
work.
It wasn't until tonight that I saw the times the same via the PDO
interface. That
made my day.
Actual result:
--
The native OCI8 1.3.5+ requires extra time to open/close and exit. The
time delta
is 1 second for such a small code snippet.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51610&edit=1
Req #52188 [Opn->Bgs]: Arithmetic Operator: Addition maybe have a problem
Edit report at http://bugs.php.net/bug.php?id=52188&edit=1 ID: 52188 Updated by: ras...@php.net Reported by: hostmaster at ovi dot com Summary: Arithmetic Operator: Addition maybe have a problem -Status: Open +Status: Bogus Type: Feature/Change Request Package: Scripting Engine problem Operating System: openSuSE PHP Version: 5.3.2 New Comment: Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about "floats" and what IEEE 754 is, read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. . Previous Comments: [2010-06-26 01:05:26] hostmaster at ovi dot com Description: PHP version: 5.3.2 I think addition operator have a problem. Pls run the script below and the code in "Test script" box. "; } print "\n"; print $a .":". ($b + $c); print "\n"; ?> If the number is 16.98, the result will be ok. Test script: --- "; } print "\n"; } } -- Edit this bug report at http://bugs.php.net/bug.php?id=52188&edit=1
[PHP-BUG] Req #52188 [NEW]: Arithmetic Operator: Addition maybe have a problem
From: Operating system: openSuSE PHP version: 5.3.2 Package: Scripting Engine problem Bug Type: Feature/Change Request Bug description:Arithmetic Operator: Addition maybe have a problem Description: PHP version: 5.3.2 I think addition operator have a problem. Pls run the script below and the code in "Test script" box. "; } print "\n"; print $a .":". ($b + $c); print "\n"; ?> If the number is 16.98, the result will be ok. Test script: --- "; } print "\n"; } } -- Edit bug report at http://bugs.php.net/bug.php?id=52188&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52188&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52188&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52188&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52188&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52188&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52188&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52188&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52188&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52188&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52188&r=support Expected behavior: http://bugs.php.net/fix.php?id=52188&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52188&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52188&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52188&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52188&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52188&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52188&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52188&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52188&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52188&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52188&r=mysqlcfg
[PHP-BUG] Bug #52187 [NEW]: build error
From: Operating system: FreeBSD 7.3-RELEASE (amd64) PHP version: 5.2.13 Package: *General Issues Bug Type: Bug Bug description:build error Description: Try ./configure --with-apxs2=/usr/local/sbin/apxs then `make` and you get always build error: previous declaration of 'regoff_t' was here The same for 5.2.14RC1 I have apache-2.0.63 installed on x64 system Actual result: -- /bin/sh /usr/home/max/dist/php-5.2.13/libtool --silent --preserve-dup-deps -- mode=compile gcc -DBIG_SECURITY_HOLE -I/usr/local/include/apache2 -D_REENTRANT -D_THREAD_SAFE -I/usr/local/include/apr-0 -I/usr/local/include/apr-0 - I/usr/local/include -I/usr/local/include/db42 -Isapi/apache2handler/ - I/usr/home/max/dist/php-5.2.13/sapi/apache2handler/ -DPHP_ATOM_INC - I/usr/home/max/dist/php-5.2.13/include -I/usr/home/max/dist/php-5.2.13/main - I/usr/home/max/dist/php-5.2.13 -I/usr/home/max/dist/php-5.2.13/ext/date/lib - I/usr/local/include/libxml2 -I/usr/local/include -I/usr/home/max/dist/php- 5.2.13/TSRM -I/usr/home/max/dist/php-5.2.13/Zend-I/usr/local/include -g -O2 -c /usr/home/max/dist/php-5.2.13/sapi/apache2handler/mod_php5.c -o sapi/apache2handler/mod_php5.lo In file included from /usr/local/include/apache2/httpd.h:44, from /usr/home/max/dist/php- 5.2.13/sapi/apache2handler/php_apache.h:24, from /usr/home/max/dist/php- 5.2.13/sapi/apache2handler/mod_php5.c:26: /usr/local/include/apache2/ap_regex.h:90: error: conflicting types for 'regoff_t' /usr/home/max/dist/php-5.2.13/regex/regex.h:17: error: previous declaration of 'regoff_t' was here *** Error code 1 -- Edit bug report at http://bugs.php.net/bug.php?id=52187&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52187&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52187&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52187&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52187&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52187&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52187&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52187&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52187&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52187&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52187&r=support Expected behavior: http://bugs.php.net/fix.php?id=52187&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52187&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52187&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52187&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52187&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52187&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52187&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52187&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52187&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52187&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52187&r=mysqlcfg
Bug #52184 [Com]: Using null as array gives no warning or error
Edit report at http://bugs.php.net/bug.php?id=52184&edit=1
ID: 52184
Comment by: egorinsk at gmail dot com
Reported by: egorinsk at gmail dot com
Summary: Using null as array gives no warning or error
Status: Bogus
Type: Bug
Package: *General Issues
Operating System: linux
PHP Version: 5.3.2
New Comment:
Thank you for your response.
> You aren't accessing an array offset but a string offset. null is
casted to String. The string is shorter than the offset (length is 0) so
it returns NULL.
Well, PHP emits a notice when accessing uninitialized string offset, so
this is not the case:
~: php -r 'error_reporting(E_ALL); $a=""; echo $a[12]; '
PHP Notice: Uninitialized string offset: 12 in Command line code on
line 1
PHP Stack trace:
PHP 1. {main}() Command line code:0
Notice: Uninitialized string offset: 12 in Command line code on line 1
Call Stack:
0.0002 317032 1. {main}() Command line code:0
Anyway, I guess there should be at least warning, because null is
neither a string, nor array, and trying to access element of null is
obviously an error, and I, as a developer, would prefer to have it
logged.
Previous Comments:
[2010-06-25 15:25:41] johan...@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
You aren't accessing an array offset but a string offset. null is casted
to String. The string is shorter than the offset (length is 0) so it
returns NULL.
[2010-06-25 13:39:14] egorinsk at gmail dot com
Description:
Using null as array gives no warning, notice or error, just returns
null. It is at least strange.
Test script:
---
Expected result:
Some kind of notice or warning.
Actual result:
--
(nothing)
--
Edit this bug report at http://bugs.php.net/bug.php?id=52184&edit=1
Req #52185 [Dup->Bgs]: superglobals as objects
Edit report at http://bugs.php.net/bug.php?id=52185&edit=1 ID: 52185 Updated by: dtajchre...@php.net Reported by: tobias dot sattler at gmx dot de Summary: superglobals as objects -Status: Duplicate +Status: Bogus Type: Feature/Change Request Package: Unknown/Other Function Operating System: Mac OSX PHP Version: Irrelevant Previous Comments: [2010-06-25 23:24:31] dtajchre...@php.net See #52174. [2010-06-25 22:08:41] tobias dot sattler at gmx dot de Description: In times of OOP it would be nice if you can just use the superglobals as objects. Of course you can do it yourself with $foo = (object)$_POST; but then the compiler has do the work twice instead of once. Therefore it would be nice if there is a switch in php.ini file like use_superglobals_as_objects = no; # yes - $_POST->foo, $_GET->foobar -- Edit this bug report at http://bugs.php.net/bug.php?id=52185&edit=1
Req #52185 [Opn->Dup]: superglobals as objects
Edit report at http://bugs.php.net/bug.php?id=52185&edit=1 ID: 52185 Updated by: dtajchre...@php.net Reported by: tobias dot sattler at gmx dot de Summary: superglobals as objects -Status: Open +Status: Duplicate Type: Feature/Change Request Package: Unknown/Other Function Operating System: Mac OSX PHP Version: Irrelevant New Comment: See #52174. Previous Comments: [2010-06-25 22:08:41] tobias dot sattler at gmx dot de Description: In times of OOP it would be nice if you can just use the superglobals as objects. Of course you can do it yourself with $foo = (object)$_POST; but then the compiler has do the work twice instead of once. Therefore it would be nice if there is a switch in php.ini file like use_superglobals_as_objects = no; # yes - $_POST->foo, $_GET->foobar -- Edit this bug report at http://bugs.php.net/bug.php?id=52185&edit=1
Bug #52186 [Csd]: phpinfo() shows 10.1 or 11.1 when installed with ORACLE_HOME 10.2 or 11.2
Edit report at http://bugs.php.net/bug.php?id=52186&edit=1 ID: 52186 Updated by: s...@php.net Reported by: s...@php.net Summary: phpinfo() shows 10.1 or 11.1 when installed with ORACLE_HOME 10.2 or 11.2 Status: Closed Type: Bug Package: OCI8 related Operating System: All PHP Version: 5.3SVN-2010-06-25 (SVN) Assigned To: sixd New Comment: Fixed in PHP 5.3 and trunk. Will be included in any future PECL OCI8 1.4.2 release. Previous Comments: [2010-06-25 23:14:36] s...@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-06-25 23:09:15] s...@php.net Automatic comment from SVN on behalf of sixd Revision: http://svn.php.net/viewvc/?view=revision&revision=300752 Log: Fix bug #52186 (phpinfo shows 10.1 or 11.1 when installed with ORACLE_HOME 10.2 or 11.2) [2010-06-25 22:15:22] s...@php.net Description: When the OCI8 extensions is installed using an ORACLE_HOME (not Instant Client) 10.2 or 11.2, the compile time Oracle version shown by phpinfo() is 10.1 or 11.1. This is because the displayed value is derived from an Oracle library filename extension which, for drop-in compatibility, is not updated for the patch releases of Oracle. Also in some cases installing from PECL no version is shown at all because the PHP build scripts can't define the required macro. The fix is to use the OCI_MAJOR_VERSION and OCI_MINOR_VERSION macros in oci8.c. These macros are available with Oracle libraries 10.2 onwards. -- Edit this bug report at http://bugs.php.net/bug.php?id=52186&edit=1
Bug #52186 [Asn->Csd]: phpinfo() shows 10.1 or 11.1 when installed with ORACLE_HOME 10.2 or 11.2
Edit report at http://bugs.php.net/bug.php?id=52186&edit=1 ID: 52186 Updated by: s...@php.net Reported by: s...@php.net Summary: phpinfo() shows 10.1 or 11.1 when installed with ORACLE_HOME 10.2 or 11.2 -Status: Assigned +Status: Closed Type: Bug Package: OCI8 related Operating System: All PHP Version: 5.3SVN-2010-06-25 (SVN) Assigned To: sixd 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: [2010-06-25 23:09:15] s...@php.net Automatic comment from SVN on behalf of sixd Revision: http://svn.php.net/viewvc/?view=revision&revision=300752 Log: Fix bug #52186 (phpinfo shows 10.1 or 11.1 when installed with ORACLE_HOME 10.2 or 11.2) [2010-06-25 22:15:22] s...@php.net Description: When the OCI8 extensions is installed using an ORACLE_HOME (not Instant Client) 10.2 or 11.2, the compile time Oracle version shown by phpinfo() is 10.1 or 11.1. This is because the displayed value is derived from an Oracle library filename extension which, for drop-in compatibility, is not updated for the patch releases of Oracle. Also in some cases installing from PECL no version is shown at all because the PHP build scripts can't define the required macro. The fix is to use the OCI_MAJOR_VERSION and OCI_MINOR_VERSION macros in oci8.c. These macros are available with Oracle libraries 10.2 onwards. -- Edit this bug report at http://bugs.php.net/bug.php?id=52186&edit=1
[PHP-BUG] Bug #52186 [NEW]: phpinfo() shows 10.1 or 11.1 when installed with ORACLE_HOME 10.2 or 11.2
From: sixd Operating system: All PHP version: 5.3SVN-2010-06-25 (SVN) Package: OCI8 related Bug Type: Bug Bug description:phpinfo() shows 10.1 or 11.1 when installed with ORACLE_HOME 10.2 or 11.2 Description: When the OCI8 extensions is installed using an ORACLE_HOME (not Instant Client) 10.2 or 11.2, the compile time Oracle version shown by phpinfo() is 10.1 or 11.1. This is because the displayed value is derived from an Oracle library filename extension which, for drop-in compatibility, is not updated for the patch releases of Oracle. Also in some cases installing from PECL no version is shown at all because the PHP build scripts can't define the required macro. The fix is to use the OCI_MAJOR_VERSION and OCI_MINOR_VERSION macros in oci8.c. These macros are available with Oracle libraries 10.2 onwards. -- Edit bug report at http://bugs.php.net/bug.php?id=52186&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52186&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52186&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52186&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52186&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52186&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52186&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52186&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52186&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52186&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52186&r=support Expected behavior: http://bugs.php.net/fix.php?id=52186&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52186&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52186&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52186&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52186&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52186&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52186&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52186&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52186&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52186&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52186&r=mysqlcfg
[PHP-BUG] Req #52185 [NEW]: superglobals as objects
From: Operating system: Mac OSX PHP version: Irrelevant Package: Unknown/Other Function Bug Type: Feature/Change Request Bug description:superglobals as objects Description: In times of OOP it would be nice if you can just use the superglobals as objects. Of course you can do it yourself with $foo = (object)$_POST; but then the compiler has do the work twice instead of once. Therefore it would be nice if there is a switch in php.ini file like use_superglobals_as_objects = no; # yes - $_POST->foo, $_GET->foobar -- Edit bug report at http://bugs.php.net/bug.php?id=52185&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52185&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52185&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52185&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52185&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52185&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52185&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52185&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52185&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52185&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52185&r=support Expected behavior: http://bugs.php.net/fix.php?id=52185&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52185&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52185&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52185&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52185&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52185&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52185&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52185&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52185&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52185&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52185&r=mysqlcfg
Req #38025 [Com]: Missing stream wrapper methods
Edit report at http://bugs.php.net/bug.php?id=38025&edit=1 ID: 38025 Comment by: james at gogo dot co dot nz Reported by: flconseil at yahoo dot fr Summary: Missing stream wrapper methods Status: Open Type: Feature/Change Request Package: Feature/Change Request Operating System: All PHP Version: 5.1.4 New Comment: In the 4 years since this bug/feature request was reported, flock() has been implemented. I can not see any documentation to indicate that touch(), chmod() etc... are possible to implement with stream wrappers yet. url_stat() is able to provide read access for these data points, but there is no means to provide the write access. Previous Comments: [2006-07-06 16:59:40] flconseil at yahoo dot fr Description: The following functions cannot be implemented in a stream wrapper because the corresponding methods don't exist : - chgrp & lchgrp - chown &lchown - chmod - flock - link & symlink/readlink - touch To be confirmed for : - ftruncate - realpath For most of these (links, owner, mode), as the values can be returned by stat/lstat() calls, PHP should provide a way to set/modify them. -- Edit this bug report at http://bugs.php.net/bug.php?id=38025&edit=1
Bug #52184 [Opn->Bgs]: Using null as array gives no warning or error
Edit report at http://bugs.php.net/bug.php?id=52184&edit=1 ID: 52184 Updated by: johan...@php.net Reported by: egorinsk at gmail dot com Summary: Using null as array gives no warning or error -Status: Open +Status: Bogus Type: Bug Package: *General Issues Operating System: linux PHP Version: 5.3.2 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 You aren't accessing an array offset but a string offset. null is casted to String. The string is shorter than the offset (length is 0) so it returns NULL. Previous Comments: [2010-06-25 13:39:14] egorinsk at gmail dot com Description: Using null as array gives no warning, notice or error, just returns null. It is at least strange. Test script: --- Expected result: Some kind of notice or warning. Actual result: -- (nothing) -- Edit this bug report at http://bugs.php.net/bug.php?id=52184&edit=1
Bug #45488 [Com]: preg_replace failed when the $subject parameter length exceeds 100009
Edit report at http://bugs.php.net/bug.php?id=45488&edit=1 ID: 45488 Comment by: daniel dot reiche at tu-dresden dot de Reported by: webez dot cn at gmail dot com Summary: preg_replace failed when the $subject parameter length exceeds 19 Status: Bogus Type: Bug Package: PCRE related Operating System: * PHP Version: 5.2.6 New Comment: if this is intended, shouldn't the manual reflect that and e.g. state that the subject length is limited by PCRE_BACKTRACK_LIMIT ? Just happened to stumble over this myself, and only the Bug-Report Dialog showed this bug to me after i tried to write a new one. Was not able to find it myself using the search! Previous Comments: [2008-07-12 16:06:33] fel...@php.net This is expected, it when fails preg_last_error() returns: int(2) That means PREG_BACKTRACK_LIMIT_ERROR. See http://docs.php.net/manual/en/pcre.configuration.php#ini.pcre.backtrack-limit [2008-07-11 17:57:39] webez dot cn at gmail dot com Description: if the $subject parameter's length exceeds 19, str_replace has no return value. This has been reproduced on windows 2003 with php 5.2.6 and Linux with php 5.2.5 PS: If there is backslash in the $subject parameter and $pattern parameter, the critical poiont will change, the maximum string length to reproduce this bug will increase. Reproduce code: --- "; } ?> Expected result: str_replace with length: 19 passed str_replace with length: 100010 passed Actual result: -- str_replace with length: 19 passed str_replace with length: 100010 failed -- Edit this bug report at http://bugs.php.net/bug.php?id=45488&edit=1
[PHP-BUG] Bug #52184 [NEW]: Using null as array gives no warning or error
From: Operating system: linux PHP version: 5.3.2 Package: *General Issues Bug Type: Bug Bug description:Using null as array gives no warning or error Description: Using null as array gives no warning, notice or error, just returns null. It is at least strange. Test script: --- Expected result: Some kind of notice or warning. Actual result: -- (nothing) -- Edit bug report at http://bugs.php.net/bug.php?id=52184&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52184&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52184&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52184&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52184&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52184&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52184&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52184&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52184&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52184&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52184&r=support Expected behavior: http://bugs.php.net/fix.php?id=52184&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52184&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52184&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52184&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52184&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52184&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52184&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52184&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52184&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52184&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52184&r=mysqlcfg
Req #52182 [Com]: get_object_by_id and get_object_id
Edit report at http://bugs.php.net/bug.php?id=52182&edit=1
ID: 52182
Comment by: olamedia at gmail dot com
Reported by: olamedia at gmail dot com
Summary: get_object_by_id and get_object_id
Status: Bogus
Type:Feature/Change Request
Package: Unknown/Other Function
PHP Version: 5.3.2
New Comment:
2 johannes
So you think, that I need to force call $object->invalidate() / garbage
collection
each time I want no memory leaks? Well, I don't need a "unique id", just
"lifetime
unique id".
spl_object_hash() don't have a reverse function spl_get_object_by_hash()
Previous Comments:
[2010-06-25 13:17:14] johan...@php.net
Your design looks broken. Why should unset a random pointer to the
object destroy it? If you really need to unset them - which I'd most
likely consider broken design - add a method to invalidate it this ...
If you really want to do this the needed function is available -
spl_object_hash().
But mind that we don't have any true unique identifier - once an object
is destroyed it's ID might be re-used by others.
[2010-06-25 12:35:55] olamedia at gmail dot com
Description:
Requesting new functions:
get_object_id() to get identifier of the object like in var_dump()
(Object #XXX)
get_object_by_id() to get object by identifier
Related bug in test script
Test script:
---
class a{
protected $b;
public function __construct($b){
$this->b = $b;
}
}
class b{
}
$b = new b()
$a = new a($b);
unset($b); // __destruct will not be called because of link left in $a
Expected result:
class a{
protected $b;
public function __construct($b){
$this->b = get_object_id($b); // integer
}
public function getB(){
return get_object_by_id($this->b);
}
}
class b{
}
$b = new b()
$a = new a($b);
var_dump($a->getB()); // Object #
unset($b); // __destruct will be called because no links left
var_dump($a->getB()); // boolean false
--
Edit this bug report at http://bugs.php.net/bug.php?id=52182&edit=1
Req #52182 [Opn->Bgs]: get_object_by_id and get_object_id
Edit report at http://bugs.php.net/bug.php?id=52182&edit=1
ID: 52182
Updated by: johan...@php.net
Reported by: olamedia at gmail dot com
Summary: get_object_by_id and get_object_id
-Status: Open
+Status: Bogus
Type:Feature/Change Request
Package: Unknown/Other Function
PHP Version: 5.3.2
New Comment:
Your design looks broken. Why should unset a random pointer to the
object destroy it? If you really need to unset them - which I'd most
likely consider broken design - add a method to invalidate it this ...
If you really want to do this the needed function is available -
spl_object_hash().
But mind that we don't have any true unique identifier - once an object
is destroyed it's ID might be re-used by others.
Previous Comments:
[2010-06-25 12:35:55] olamedia at gmail dot com
Description:
Requesting new functions:
get_object_id() to get identifier of the object like in var_dump()
(Object #XXX)
get_object_by_id() to get object by identifier
Related bug in test script
Test script:
---
class a{
protected $b;
public function __construct($b){
$this->b = $b;
}
}
class b{
}
$b = new b()
$a = new a($b);
unset($b); // __destruct will not be called because of link left in $a
Expected result:
class a{
protected $b;
public function __construct($b){
$this->b = get_object_id($b); // integer
}
public function getB(){
return get_object_by_id($this->b);
}
}
class b{
}
$b = new b()
$a = new a($b);
var_dump($a->getB()); // Object #
unset($b); // __destruct will be called because no links left
var_dump($a->getB()); // boolean false
--
Edit this bug report at http://bugs.php.net/bug.php?id=52182&edit=1
[PHP-BUG] Bug #52183 [NEW]: Reflectionfunction reports invalid number of arguments for function aliases
From: Operating system: Linux PHP version: 5.3.2 Package: Reflection related Bug Type: Bug Bug description:Reflectionfunction reports invalid number of arguments for function aliases Description: When defining a function alias internally in PHP, PHP_FALIAS requires an arginfo as the third parameter. For example gzwrite() is internally represented as a function alias to fwrite(): PHP_FALIAS(gzwrite, fwrite, NULL) Here however the argument info is not provided. This leads to the fact that the reflection api can't extract the parameters of gzwrite. Why does an FALIAS require an arginfo? Couldn't it just take the argument info of the alias function if the arginfo is null? The impact is that you can't determine the required arguments from the gzwrite function. I hacked the code and added the arginfo stuff and the reflection api immediatly noticed that gzwrite requires 2 parameters. We are doing massive static code analysis and our code analysis returns bogus results due to the fact that the reflection api can't report the real arguments of a function. Test script: --- getNumberOfRequiredParameters()); var_dump($refl->getNumberOfParameters()); } ?> Expected result: int(2) int(3) int(2) int(3) Actual result: -- int(0) int(0) int(2) int(3) -- Edit bug report at http://bugs.php.net/bug.php?id=52183&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52183&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52183&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52183&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52183&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52183&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52183&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52183&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52183&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52183&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52183&r=support Expected behavior: http://bugs.php.net/fix.php?id=52183&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52183&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52183&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52183&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52183&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52183&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52183&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52183&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52183&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52183&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52183&r=mysqlcfg
[PHP-BUG] Req #52182 [NEW]: get_object_by_id and get_object_id
From:
Operating system:
PHP version: 5.3.2
Package: Unknown/Other Function
Bug Type: Feature/Change Request
Bug description:get_object_by_id and get_object_id
Description:
Requesting new functions:
get_object_id() to get identifier of the object like in var_dump() (Object
#XXX)
get_object_by_id() to get object by identifier
Related bug in test script
Test script:
---
class a{
protected $b;
public function __construct($b){
$this->b = $b;
}
}
class b{
}
$b = new b()
$a = new a($b);
unset($b); // __destruct will not be called because of link left in $a
Expected result:
class a{
protected $b;
public function __construct($b){
$this->b = get_object_id($b); // integer
}
public function getB(){
return get_object_by_id($this->b);
}
}
class b{
}
$b = new b()
$a = new a($b);
var_dump($a->getB()); // Object #
unset($b); // __destruct will be called because no links left
var_dump($a->getB()); // boolean false
--
Edit bug report at http://bugs.php.net/bug.php?id=52182&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52182&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52182&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52182&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52182&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52182&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52182&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52182&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52182&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52182&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52182&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52182&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52182&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52182&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52182&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52182&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52182&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52182&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52182&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52182&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52182&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52182&r=mysqlcfg
Req #45002 [Com]: __get() and __set() don't work for static variable calls
Edit report at http://bugs.php.net/bug.php?id=45002&edit=1
ID: 45002
Comment by: temporary dot hole at googlemail dot com
Reported by: jb2386 at hotmail dot com
Summary: __get() and __set() don't work for static variable
calls
Status: Open
Type: Feature/Change Request
Package: Feature/Change Request
Operating System: Any
PHP Version: 5.2.6
New Comment:
I have an idea to use this for a static registry class, would be really
useful for keeping 'application-wide' data out of global variables.
I have no idea how to apply this patch, is it possible to use the above
mentioned .diff on PHP 5.3.1 ?
Previous Comments:
[2010-05-14 09:13:41] vincentbab at gmail dot com
I would really apreciate this feature too
[2009-09-24 10:23:05] peter dot rother at gmail dot com
'Twould be seriously nice to have this featureâ¦please let us know if
anything can be done soon.
[2009-08-01 15:25:58] atrauzzi at gmail dot com
I'd have to say I'm waiting on this feature as well.
Is there a snapshot I could be using to test it out?
[2009-07-30 21:21:58] some at email dot com
When to expect resolving this bug
[2009-05-13 15:38:49] rcavallari at hotmail dot com
Any news about __{get,set}Static in the mainline?
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=45002
--
Edit this bug report at http://bugs.php.net/bug.php?id=45002&edit=1
Req #42396 [Com]: Followup to #36711: __halt_compiler() and unicode detection
Edit report at http://bugs.php.net/bug.php?id=42396&edit=1 ID: 42396 Comment by: phofstetter at sensational dot ch Reported by: francois at tekwire dot net Summary: Followup to #36711: __halt_compiler() and unicode detection Status: Assigned Type: Feature/Change Request Package: Feature/Change Request Operating System: all PHP Version: 5.2.3 Assigned To: hirokawa New Comment: somehow, recently, the default value of detect_unicode seems to have changed. With detect_unicode enabled, it's impossible to run any PHAR-file - neither through the CLI or through the web server. IMHO, this should really be looked into. Previous Comments: [2007-08-27 08:38:58] j...@php.net IMHO, #42396 is not a bug, but it is the specification. The normal script doesn't contain a null byte if it is not encoded in Unicode. It is understandable the addition of a unique byte seqence '0x' detection to support PHAR/PHK, but it is a change to add a new feature. Rui [2007-08-24 10:30:12] j...@php.net Patch posted to internals: http://news.php.net/php.internals/31870 [2007-08-24 10:29:05] j...@php.net The same folks who maintain mbstring have added that support so it's not so wrong choice. Reclassified though. And assigned to the maintainer. [2007-08-23 16:24:33] francois at tekwire dot net Not sure it should be reclassified as mbstring related, as the bug is in Zend/zend_multibyte.c and has nothing to do with mbstring. PHP5 has a little unicode part in the engine. It even has an (undocumented) 'detect_unicode' option. [2007-08-23 14:08:09] j...@php.net Reclassified: There is no unicode in PHP 5. Just mbstring. 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=42396 -- Edit this bug report at http://bugs.php.net/bug.php?id=42396&edit=1
