#45726 [Asn->Csd]: PHP_Archive / Archive.php missing
ID: 45726
Updated by: [EMAIL PROTECTED]
Reported By: Bjorn dot Wiberg at its dot uu dot se
-Status: Assigned
+Status: Closed
Bug Type: PHAR related
-Operating System: AIX 5.3 5300-08-01-0819
+Operating System: *
PHP Version: 5.3CVS-2008-08-06
Assigned To: helly
New Comment:
This bug has been fixed in CVS.
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.
Cannot reproduce, Iirc this did happen in earlier versions though.
Try running buildconf.
./buildconf --force && ./configure --disable-all --enable-phar && make
[...]
Generating phar.php
Generating phar.phar
Pear package PHP_Archive or Archive.php class file not found.
clicommand.inc
directorygraphiterator.inc
directorytreeiterator.inc
invertedregexiterator.inc
pharcommand.inc
phar.inc
Build complete.
Don't forget to run 'make test'.
Previous Comments:
[2008-08-29 12:26:01] rainer dot tammer at schulergroup dot com
Hello,
the same problem exists on AIX 5.2 / 5.3.
Bye
Rainer
[2008-08-22 22:12:30] technopark02 at gmail dot com
This issue is easy to reproduce with php5.3-200808220630 on Solaris 10
x86/x64 as well.
[2008-08-13 19:25:03] [EMAIL PROTECTED]
Assigned to the PHAR maintainer.
[2008-08-06 08:03:49] Bjorn dot Wiberg at its dot uu dot se
Sorry, same error with 5.3-dev (5.3-200808060630):
---8<--- excerpt ---8<---
t/power_510_32/usr/lib
-L/gestconf/project/GNOME_ACL/GNOME/build/acc_gnome2_14_0f1/export/power_510_32/usr/lib
-L/gestconf/project/GNOME_ACL/GNOME/build/GNOME_2_14_0/export/power_510_32/usr/lib
-L/users/project/PDP/PDP_51_vac_6_14/usr/ccs/lib
-L/users/project/PDP/PDP_51_vac_6_14/usr/lib -lz -lm -lz -ljpeg -lssl
-lcrypto -lgdbm -lbz2 -lz -lssl -lcrypto -lm -lz -liconv -lm -lcurl
-lssl -lcrypto -lz -lssl -lcrypto -lz -lz -liconv -lm -lz -liconv -lm
-lz -liconv -lm -lz -liconv -lm -lz -liconv -lm -lz -liconv -lm -lz
-liconv -lm -lz -liconv -lm -lxslt -lz -liconv -lm -lxml2 -lpthread -lz
-liconv -lm -lz -liconv -lm
-Wl,-blibpath:/usr/local/lib:/opt/freeware/lib:/usr/X11R6/lib:/opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.0.0:/opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.0.0/../../..:/usr/lib:/lib
ld: 0711-224 WARNING: Duplicate symbol: php_optidx
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
information.
ld: 0711-783 WARNING: TOC overflow. TOC size: 72664 Maximum size:
65536
Extra instructions are being generated for each reference to a
TOC
symbol if the symbol is in the TOC overflow area.
Generating phar.php
Generating phar.phar
Pear package PHP_Archive or Archive.php class file not found.
Fatal error: Uncaught exception 'PharException' with message 'illegal
stub for phar
"/home/bwiberg/rpm/BUILD/php5.3-200808060630/ext/phar/phar.phar"' in
/home/bwiberg/rpm/BUILD/php5.3-200808060630/ext/phar/phar.php:994
Stack trace:
#0 /home/bwiberg/rpm/BUILD/php5.3-200808060630/ext/phar/phar.php(994):
Phar->setStub('#!/apache/php/b...')
#1 /home/bwiberg/rpm/BUILD/php5.3-200808060630/ext/phar/phar.php(1054):
PharCommand->phar_set_stub_begin(Object(Phar), '/home/bwiberg/r...',
'/home/bwiberg/r...', '/apache/php/bin...')
#2 [internal function]: PharCommand->cli_cmd_run_pack(Array)
#3 /home/bwiberg/rpm/BUILD/php5.3-200808060630/ext/phar/phar.php(225):
call_user_func(Array, Array)
#4 /home/bwiberg/rpm/BUILD/php5.3-200808060630/ext/phar/phar.php(2073):
CLICommand->__construct(19, Array)
#5 {main}
thrown in
/home/bwiberg/rpm/BUILD/php5.3-200808060630/ext/phar/phar.php on line
994
make: *** [ext/phar/phar.phar] Error 255
Bad exit status from /var/opt/freeware/tmp/rpm-tmp.10312 (%build)
[EMAIL PROTECTED]:~/rpm/SPECS$ cd ..
[EMAIL PROTECTED]:~/rpm$ cd BUILD/php5.3-200808060630/
[EMAIL PROTECTED]:~/rpm/BUILD/php5.3-200808060630$
/opt/freeware/bin/find -iname Archive.php
[EMAIL PROTECTED]:~/rpm/BUILD/php5.3-200808060630$
--->8--- end excerpt --->8---
(No Archive.php anywhere...)
[2008-08-05 13:53:40] Bjorn dot Wiberg at its dot uu dot se
Description:
PHP complains about Archive.php / PHP_Archive not being found during
compilation.
Reproduce code:
---
#! /bin/sh
#
# Created by configure
LDFLAGS='-Wl,-bbigtoc' \
CC='gcc' \
'./configure' \
'--disable-fileinfo' \
'--enable-bcmath' \
'--enable-calendar&
#45613 [Asn]: Segfault when using is_file() on Apache-2.2.8
ID: 45613 Updated by: [EMAIL PROTECTED] Reported By: crocodile2u at yandex dot ru Status: Assigned Bug Type: Apache2 related Operating System: * PHP Version: 5.3CVS-2008-07-24 (CVS) -Assigned To: helly +Assigned To: dmitry New Comment: Dmitry, please submit, patch looks correct. Previous Comments: [2008-08-14 12:06:21] [EMAIL PROTECTED] Here is a patch for it (made by Dmitry): http://dev.daylessday.org/diff/bug45613.diff [2008-08-05 11:15:54] crocodile2u at yandex dot ru The problem is still here with PHP-5.3.0alpha [2008-07-28 08:58:51] crocodile2u at yandex dot ru I've just installed the latest snapshot of PHP-5.3 and the problem persists. The dump: #0 0x in ?? () #1 0xb71feef8 in phar_is_file (ht=1, return_value=0x83db0b8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0, tsrm_ls=0x83c5a70) at /home/vbolshov/src/php/php5.3-200807280630/ext/phar/func_interceptors.c:956 #2 0xb73f3828 in zend_do_fcall_common_helper_SPEC (execute_data=0x84a0a70, tsrm_ls=0x83c5a70) at /home/vbolshov/src/php/php5.3-200807280630/Zend/zend_vm_execute.h:313 #3 0xb73e00b5 in execute (op_array=0x83dac2c, tsrm_ls=0x83c5a70) at /home/vbolshov/src/php/php5.3-200807280630/Zend/zend_vm_execute.h:104 #4 0xb73bad2f in zend_execute_scripts (type=8, tsrm_ls=0x83c5a70, retval=0x0, file_count=3) at /home/vbolshov/src/php/php5.3-200807280630/Zend/zend.c:1199 #5 0xb73617d5 in php_execute_script (primary_file=0xb44c41f0, tsrm_ls=0x83c5a70) at /home/vbolshov/src/php/php5.3-200807280630/main/main.c:2088 #6 0xb744fa48 in php_handler (r=0x83cac20) at /home/vbolshov/src/php/php5.3-200807280630/sapi/apache2handler/sapi_apache2.c:630 #7 0x08079639 in ap_run_handler () #8 0x0807ca47 in ap_invoke_handler () #9 0x08089d60 in ap_process_request () #10 0x0808706b in ?? () #11 0x083cac20 in ?? () #12 0x0004 in ?? () #13 0x083cac20 in ?? () #14 0x in ?? () Source code for the script was: http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. 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/45613 -- Edit this bug report at http://bugs.php.net/?id=45613&edit=1
#45613 [Asn->Fbk]: Segfault when using is_file() on Apache-2.2.8
ID: 45613 Updated by: [EMAIL PROTECTED] Reported By: crocodile2u at yandex dot ru -Status: Assigned +Status: Feedback Bug Type: Apache2 related -Operating System: Ununtu 8.04 +Operating System: * PHP Version: 5.3CVS-2008-07-24 (CVS) Assigned To: tony2001 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.3-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.3-win32-installer-latest.msi Previous Comments: [2008-08-05 11:15:54] crocodile2u at yandex dot ru The problem is still here with PHP-5.3.0alpha [2008-08-01 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-07-28 08:58:51] crocodile2u at yandex dot ru I've just installed the latest snapshot of PHP-5.3 and the problem persists. The dump: #0 0x in ?? () #1 0xb71feef8 in phar_is_file (ht=1, return_value=0x83db0b8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0, tsrm_ls=0x83c5a70) at /home/vbolshov/src/php/php5.3-200807280630/ext/phar/func_interceptors.c:956 #2 0xb73f3828 in zend_do_fcall_common_helper_SPEC (execute_data=0x84a0a70, tsrm_ls=0x83c5a70) at /home/vbolshov/src/php/php5.3-200807280630/Zend/zend_vm_execute.h:313 #3 0xb73e00b5 in execute (op_array=0x83dac2c, tsrm_ls=0x83c5a70) at /home/vbolshov/src/php/php5.3-200807280630/Zend/zend_vm_execute.h:104 #4 0xb73bad2f in zend_execute_scripts (type=8, tsrm_ls=0x83c5a70, retval=0x0, file_count=3) at /home/vbolshov/src/php/php5.3-200807280630/Zend/zend.c:1199 #5 0xb73617d5 in php_execute_script (primary_file=0xb44c41f0, tsrm_ls=0x83c5a70) at /home/vbolshov/src/php/php5.3-200807280630/main/main.c:2088 #6 0xb744fa48 in php_handler (r=0x83cac20) at /home/vbolshov/src/php/php5.3-200807280630/sapi/apache2handler/sapi_apache2.c:630 #7 0x08079639 in ap_run_handler () #8 0x0807ca47 in ap_invoke_handler () #9 0x08089d60 in ap_process_request () #10 0x0808706b in ?? () #11 0x083cac20 in ?? () #12 0x0004 in ?? () #13 0x083cac20 in ?? () #14 0x in ?? () Source code for the script was: http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. 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/45613 -- Edit this bug report at http://bugs.php.net/?id=45613&edit=1
#45634 [Opn->Bgs]: DirectoryIterator default sorting error
ID: 45634 Updated by: [EMAIL PROTECTED] Reported By: jcknight at gmail dot com -Status: Open +Status: Bogus Bug Type: SPL related Operating System: Linux PHP Version: 5.2.6 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 It does not help making the wrong bug entry several times. Instead you do cost us very precious time. Guess we have a life too. Duplicate of #45505: "DirectoryIterator default sorting error" entered by same person. Read: the file system is usually not sorted. Now, while many programs that do display fs entries sort before displaying, SPLs classes do not as that would mean a major slow down. That said, if you need sorting, you need to do it yourself. Previous Comments: [2008-07-26 20:51:24] jcknight at gmail dot com Description: The DirectoryIterator class does not iterate the directory how it is organized on the file system. Reproduce code: --- current() ."\n"; } ?> Expected result: [EMAIL PROTECTED] fox]# ls -l total 272 -rw-r--r-- 1 nobody nobody 8855 2007-10-28 13:21 dance_L.gif -rw-r--r-- 1 nobody nobody 8846 2007-10-28 13:21 dance_R.gif -rw-r--r-- 1 nobody nobody 9880 2007-10-28 13:21 enter_L.gif -rw-r--r-- 1 nobody nobody 9852 2007-10-28 13:21 enter_R.gif -rw-r--r-- 1 nobody nobody 8186 2007-10-28 13:21 growl_L.gif -rw-r--r-- 1 nobody nobody 8173 2007-10-28 13:21 growl_R.gif -rw-r--r-- 1 nobody nobody 7299 2007-10-28 13:21 headstand_L.gif -rw-r--r-- 1 nobody nobody 7328 2007-10-28 13:22 headstand_R.gif -rw-r--r-- 1 nobody nobody 7464 2007-10-28 13:21 hide_L.gif -rw-r--r-- 1 nobody nobody 7479 2007-10-28 13:21 hide_R.gif -rw-r--r-- 1 nobody nobody 7924 2007-10-28 13:21 laugh_L.gif -rw-r--r-- 1 nobody nobody 7957 2007-10-28 13:21 laugh_R.gif -rw-r--r-- 1 nobody nobody 8138 2007-10-28 13:22 lay_L.gif -rw-r--r-- 1 nobody nobody 8131 2007-10-28 13:22 lay_R.gif -rw-r--r-- 1 nobody nobody 5822 2007-10-28 13:21 mad_L.gif -rw-r--r-- 1 nobody nobody 5836 2007-10-28 13:21 mad_R.gif -rw-r--r-- 1 nobody nobody 8557 2007-10-28 13:24 music_L.gif -rw-r--r-- 1 nobody nobody 8533 2007-10-28 13:24 music_R.gif -rw-r--r-- 1 nobody nobody 8061 2007-10-28 13:22 nuzzle_L.gif -rw-r--r-- 1 nobody nobody 8079 2007-10-28 13:22 nuzzle_R.gif -rw-r--r-- 1 nobody nobody 7426 2007-10-28 13:22 rollover_L.gif -rw-r--r-- 1 nobody nobody 7402 2007-10-28 13:22 rollover_R.gif -rw-r--r-- 1 nobody nobody 6077 2007-10-28 13:22 sad_L.gif -rw-r--r-- 1 nobody nobody 6060 2007-10-28 13:22 sad_R.gif -rw-r--r-- 1 nobody nobody 8407 2007-10-28 13:26 sit_L.gif -rw-r--r-- 1 nobody nobody 8424 2007-10-28 13:26 sit_R.gif -rw-r--r-- 1 nobody nobody 5478 2007-10-28 13:22 sleep_L.gif -rw-r--r-- 1 nobody nobody 5499 2007-10-28 13:22 sleep_R.gif -rw-r--r-- 1 nobody nobody 7976 2007-10-28 13:22 sprawl_L.gif -rw-r--r-- 1 nobody nobody 7957 2007-10-28 13:22 sprawl_R.gif [EMAIL PROTECTED] fox]# Actual result: -- [EMAIL PROTECTED] skel]# php ./test.php . .. laugh_L.gif laugh_R.gif sprawl_L.gif sprawl_R.gif music_L.gif music_R.gif dance_L.gif dance_R.gif lay_L.gif lay_R.gif sad_L.gif sad_R.gif nuzzle_L.gif growl_L.gif nuzzle_R.gif growl_R.gif headstand_L.gif headstand_R.gif sit_L.gif sit_R.gif rollover_L.gif rollover_R.gif sleep_L.gif sleep_R.gif enter_L.gif mad_L.gif enter_R.gif mad_R.gif hide_L.gif hide_R.gif [EMAIL PROTECTED] skel]# -- Edit this bug report at http://bugs.php.net/?id=45634&edit=1
#44792 [Asn->Bgs]: Serializing objects with protected members introduces null charcters
ID: 44792
Updated by: [EMAIL PROTECTED]
Reported By: alex at fav dot or dot it
-Status: Assigned
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.2.5
Assigned To: helly
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
That's just how PHP works. If you don't like the 0's then use interface
Serializable:
$> php --rc Serializable
Previous Comments:
[2008-07-21 14:33:13] penny at mjollnir dot org
Present in 5.2.6 as well.
[2008-07-15 17:22:32] [EMAIL PROTECTED]
Marcus, yet another PPP issue.
[2008-04-21 11:14:12] alex at fav dot or dot it
Description:
The output from the serialization of objects that contain protected
(and possibly private also) members contains null characters. These
characters are unnecessary and can cause problems when inserting the
serialized data into databases.
An asterisk is placed before the variable name in the serialized
string, which I assume is to mark it as protected. This asterisk is
surrounded by null characters.
This appears to be the same as the closed #29865 (closed 10/2005), but
in version 5.2.5 and the latest snapshot, the bug still exists.
Reproduce code:
---
php -r 'class Foo { protected $bar = 1; } $v = new Foo; echo
serialize($v);' | hexdump
Expected result:
The output should not contain null characters (shown as '00') around
the asterisk.
Actual result:
--
000 3a4f 3a33 4622 6f6f 3a22 3a31 737b 363a
010 223a 2a00 6200 7261 3b22 3a69 3b31 007d
01f
--
Edit this bug report at http://bugs.php.net/?id=44792&edit=1
#43538 [Opn->Bgs]: count on non-array should return false, not 1
ID: 43538
Updated by: [EMAIL PROTECTED]
Reported By: warren at transfusionmedia dot com
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
-Operating System: Win XP SP2
+Operating System: *
-PHP Version: 5.2.5
+PHP Version: *
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
It returns 1 as that means you have one element.
Anyway this is the expected behavior and used by all our users for
about 10 years now. Changing this will break most PHP applications out
there. Further more the scenarios shown should use is_array() and family
of funtions.
Previous Comments:
[2008-07-16 00:32:21] [EMAIL PROTECTED]
Seems odd why its coded to return 1 imo, heres a patch against latest
PHP_5_3 cvs that changes this to return false:
http://www.phpfi.com/332583
[2007-12-08 20:30:47] warren at transfusionmedia dot com
Description:
When doing count($var) where $var is not an array, the return = 1.
The problem is when you're doing a check in your code:
if (count($var) > 0){
//do something
}
This will evaluate as true if $var is not an array. This is a problem
if you are doing this:
if (count($var) > 0){
sort($var); // anything that requires $var to be an array
}
If there is anything in that if statement that requires $var to be an
array, there will be a fatal error. I know you can also add an is_array
check in there, but that is non-obvious and shouldn't be necessary.
Really, if $var is not an array, count($var) should return false or
null, or at least a -1
Reproduce code:
---
$var = "foo";
if (count($var) > 0){
sort($var);
} else {
echo "The value of var is not greater than zero";
}
Expected result:
The value of var is not greater than zero
Actual result:
--
Warning: sort() expects parameter 1 to be array, string given
--
Edit this bug report at http://bugs.php.net/?id=43538&edit=1
#45073 [Opn->Bgs]: ?
ID: 45073 Updated by: [EMAIL PROTECTED] Reported By: gogulas at wp dot pl -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: windows/unix PHP Version: 5.2.6 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 Sleep means sleep and execution time means time of execution. If you want run time then use timing functionality. Previous Comments: [2008-05-22 22:53:54] gogulas at wp dot pl Description: HELLo This is not a bug. time when funcion sleep() holding script, (aswell as for example sql querty), dosnt include to total script execute time, so if we set max execution time in php.ini for example 60 sec. the sleep(); will hold script for seconds. So run it times :P IMO next versions of php shouldnt exclude sleep() from max_execution_time. Realy, who need this for anything except crackers? :P -- Edit this bug report at http://bugs.php.net/?id=45073&edit=1
#45065 [Opn->Bgs]: trigger '__autoload' for :: operator, extends, and implements
ID: 45065
Updated by: [EMAIL PROTECTED]
Reported By: noah at dizzler dot com
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 5.2.6
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
Autoload looks for classes where needed. It does not load classes for
cases where a non loaded class already decides on the result (e.g.
instanceof)
Previous Comments:
[2008-05-22 14:02:36] noah at dizzler dot com
Description:
class MyClass extends MyParent implements MyInterface {
public static function any_static_method() { }
}
MyClass::any_static_method()
the above should trigger __autoload() for MyClass
which would trigger __autoload() for MyParent
which would trigger __autoload() for MyInterface
Elegant and truly automatic :)
--
Edit this bug report at http://bugs.php.net/?id=45065&edit=1
#44793 [Bgs]: ArrayObject does not report as Iterator
ID: 44793
Updated by: [EMAIL PROTECTED]
Reported By: matthew at zend dot com
Status: Bogus
Bug Type: SPL related
-Operating System: Linux (Ubuntu)
+Operating System: *
-PHP Version: 5.2.5
+PHP Version: 5+
New Comment:
For you rand everybodies education, there are two very useful commands
as shown below. The second shows that ArrayAccess does not implement any
Interface at all. The first shows that ArrayObject and ArrayIterator are
on the same level. Doing 'php --rc ArrayIterator' and 'php --rc
ArrayObject' you will find that the former implement Iterator while as
the second implements IteratorAggregate which in turn does not inherit
Iterator.
[EMAIL PROTECTED] php-cvs]$ php ext/spl/examples/class_tree.php
ArrayAccess
make: `sapi/cli/php' is up to date.
ArrayAccess
|-ArrayIterator
| \-RecursiveArrayIterator (RecursiveIterator)
| \-SubClasses
|-ArrayObject
|-CachingIterator (ArrayAccess, Countable)
| \-RecursiveCachingIterator (RecursiveIterator)
|-SplDoublyLinkedList
| |-SplQueue
| \-SplStack
\-SplObjectStorage
[EMAIL PROTECTED] php-cvs]$ php --rc ArrayAccess
make: `sapi/cli/php' is up to date.
Interface [ interface ArrayAccess ] {
Previous Comments:
[2008-04-21 16:12:36] [EMAIL PROTECTED]
Actually, ArrayAccess does not implment ArrayIterator, but vice versa.
ArrayObject therefor does not implement Iterator.
[2008-04-21 16:07:34] [EMAIL PROTECTED]
Re-opening
[2008-04-21 16:03:38] matthew at zend dot com
This is a bug in SPL, which is bundled in PHP core; additionally, it
exposes a potential issue with how inheritence is resolved in the
language. Please re-open.
[2008-04-21 15:51:24] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
class ArrayObject implements IteratorAggregate, Traversable,
ArrayAccess, Serializable, Countable.
Traversable is not the same as Iterator: Traversable allows an object
to be magically iterated by, i.e foreach, while Iterator explicitly
provides userland iteration interface through
next/valid/current/key/rewind.
[2008-04-21 12:52:27] matthew at zend dot com
Description:
ArrayObject extends ArrayAccess, which implements ArrayIterator and in
turn Iterator. However, when checking to see if a concrete instance of
ArrayObject implements Iterator, the return is false.
Reproduce code:
---
$o = new ArrayObject(array());
if ($o instanceof Iterator) {
echo "Instance of Iterator";
} else {
echo "Failed";
}
Expected result:
Instance of Iterator
Actual result:
--
Failed
--
Edit this bug report at http://bugs.php.net/?id=44793&edit=1
#44734 [Opn->Bgs]: array sematics for ArrayObject and derivates
ID: 44734
Updated by: [EMAIL PROTECTED]
Reported By: Kai dot Kunstmann at combase dot de
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: any
PHP Version: 5.2.5
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
ArrayObject/ArrayIterator implement ArrayAccess and do exactly what
they are supposed to do. They add a new semantics to objects. This is
for instance used in SimpleXML. If you do not like it don't use it.
Otherwise read the documentation. Aside from that I cannot find any
substantial information in this report.
Previous Comments:
[2008-04-15 16:40:10] Kai dot Kunstmann at combase dot de
the code used for the sample output is actually this:
ArrayObject = new ArrayObject();
$ArrayObject[] = 'foo';
$ArrayObject[] = 'bar';
$ArrayObject[] = 479;
sort($ArrayObject);
var_dump('sorted', $ArrayObject);
$values = array_values($ArrayObject);
var_dump('values', $values);
var_dump('is_array', is_array($ArrayObject));
[2008-04-15 15:57:52] Kai dot Kunstmann at combase dot de
Description:
As you probably know, objects extending or implementing certain classes
and interfaces from the SPL allow for special array syntax.
e.g. the array-push idiom on the ArrayAccess interface:
...or the foreach-loop on Iterator:
...ArrayObject even allows for the list-each idiom:
This is a nice feature, which I very much appreciate. However, it is
error prone as it is not complete. The avarage PHP user, none-OOP
programmer and not-about-type-caring guy will certainly fail to replace
arrays with ArrayObject and that alike, as it simply is not the same.
It's just the same syntax for two different semantics.
I like the idea to be able to implement my own Collection classes and
iterate over instances just like in Java. Taking that road however
requires me to implement my own utility methods like 'sort()' and
derivates (yes, some build-ins fail to sort an $ArrayObject) and
replacements for all those high-performance array_* methods.
Replacing those is necessary because the only common thing ArrayObject
and array do share is in fact the special array syntax I mentioned
before - plus some functions that 'magically' work.
Refactoring existing functional code to OOP design patterns is a pain,
if not impossible, but desired to reduce development costs.
I hereby request some improvement on ArrayObject and its siblings, ie.
- a better integration with the already existing array_* functions, so
that ArrayObject and derivates can be considered real arrays.
- a richer set of predefined interfaces and utility classes like
ArrayAccess and Iterator that allow any implementing class to be used in
certain array context, eg. Sortable, Comparable, Mergable, Walkable ,
etc.
- maybe a collection interface just like in Java, with 'Array' being
the most versatile class -- implementing most of the interfaces.
...or maybe just some more 'magic functions' that allow the prior, but
cripple PHP's emerging OOP approach.
Reproduce code:
---
$ArrayObject = new ArrayObject();
$ArrayObject[] = 'foo';
$ArrayObject[] = 'bar';
$ArrayObject[] = 479;
sort($ArrayObject);
var_dump($ArrayObject);
$values = array_values($ArrayObject);
var_dump($values);
foreach($ArrayObject as $key => $value) {
var_dump($key, $value);
}
var_dump(is_array($ArrayObject));
Expected result:
string(6) "sorted"
object(ArrayObject)#1 (3) {
[0]=>
string(3) "bar"
[1]=>
string(3) "foo"
[2]=>
int(479)
}
string(6) "values"
array(3) {
[0]=>
string(3) "bar"
[1]=>
string(3) "foo"
[2]=>
int(479)
}
string(8) "is_array"
bool(true)
Actual result:
--
Warning: sort() expects parameter 1 to be array, object given
in ...
string(6) "sorted"
object(ArrayObject)#1 (3) {
[0]=>
string(3) "foo"
[1]=>
string(3) "bar"
[2]=>
int(479)
}
Warning: array_values() [function.array-values]: The argument
should be an array in ...
string(6) "values"
NULL
string(8) "is_array"
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=44734&edit=1
#44461 [Ver->Csd]: parse_ini_file crashes
ID: 44461
Updated by: [EMAIL PROTECTED]
Reported By: crrodriguez at suse dot de
-Status: Verified
+Status: Closed
Bug Type: Reproducible crash
-Operating System: Linux 64bit
+Operating System: *
-PHP Version: 5.3CVS-2008-03-17 (CVS)
+PHP Version: *
-Assigned To:
+Assigned To: helly
New Comment:
This bug has been fixed in CVS.
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:
[2008-03-21 00:33:18] [EMAIL PROTECTED]
ok, I misread the action for '\r'.
there's this code as well:
yy286:
yych = *++YYCURSOR;
switch (yych) {
case '\n': goto yy284;
default:goto yy285;
}
so it's yyfill(2) because of \r\n. Dunno where to patch this.. we can
either change the regex and check for the newline manually (which is
sort of a hack), enable yyfill for lens > 1 (what's the "safe"
threshold?), or change the yyfill macro to something smarter..
[2008-03-21 00:25:19] [EMAIL PROTECTED]
damn, oh I hate YYFILL.. the problem is this piece of code generated by
re2c:
yy282:
++YYCURSOR;
if ((YYLIMIT - YYCURSOR) < 2) YYFILL(2);
yych = *YYCURSOR;
yy283:
switch (yych) {
case '\n': goto yy284;
case '\r': goto yy286;
default:goto yy282;
}
yy284:
++YYCURSOR;
yy285:
yyleng = YYCURSOR - SCNG(yy_text);
#line 476 "zend_ini_scanner.l"
{ /* Comment */
BEGIN(INITIAL);
SCNG(lineno)++;
return END_OF_LINE;
}
the problem is that YYFILL(2) is ignored (because it's > 1). I dunno
why re2c doesn't generate a YYFILL(1) there instead..
[2008-03-19 21:34:51] [EMAIL PROTECTED]
I can confirm this, its over-reading by a character if there is no
newline at the end of the file.
[2008-03-19 21:12:37] crrodriguez at suse dot de
I have:
re2c -v
re2c 0.13.3
I have checked a fresh-, clean CVS copy just now and i can still
reproduce the problem.
Here I have the exact ini file that makes php crash
http://stuff.cristianrodriguez.net/phpbugs/bug44461.tar.bz2
# cd bug44461
# ./sapi/cli/php bug44461.php
[2008-03-18 21:50:57] [EMAIL PROTECTED]
Did you do './cvsclean && ./buildconf' ? And what re2c version do you
have installed?
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/44461
--
Edit this bug report at http://bugs.php.net/?id=44461&edit=1
#44266 [Opn->Bgs]: classes inheriting from SimpleXMLElement cannot have properties
ID: 44266
Updated by: [EMAIL PROTECTED]
Reported By: m dot beyer5 at gmx dot de
-Status: Open
+Status: Bogus
Bug Type: SimpleXML related
-Operating System: Linux
+Operating System: *
-PHP Version: 5.2.5
+PHP Version: *
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
Short answer no.
SimpleXML is designed in a way that properties map to sub elements or
attributes depending on the current level. So we cannot have some of
those mapping to pure properties. What you want is wrapping SimpleXML
instances in your own class (has-a design).
Previous Comments:
[2008-02-27 14:07:24] m dot beyer5 at gmx dot de
Description:
Classes inheriting from SimpleXMLElements should be able to have class
properties the same way any other class does.
Currently SimpleXML treats operations on class properties as operations
on the xml part of the object.
There should be a way to adress both seperately.
Reproduce code:
---
class Foo extends SimpleXMLElement
{
public $bar;
}
$str = "";
$foo = new Foo($str);
$foo->bar = array();
Expected result:
Assigning anything to Foo->bar should not affect the XML part but
should be handled as a normal class property.
Actual result:
--
SimpleXMLElement tries to interpret the public variable as an XML
Element, causing a warning:
Warning: It is not yet possible to assign complex types to properties
--
Edit this bug report at http://bugs.php.net/?id=44266&edit=1
#42527 [Asn->Bgs]: Regression with ArrayObject::offsetUnset(): not unsetting (works in 5.2.3)
ID: 42527
Updated by: [EMAIL PROTECTED]
Reported By: ahmadj at mediatrac dot net
-Status: Assigned
+Status: Bogus
Bug Type: SPL related
Operating System: *
PHP Version: *
Assigned To: helly
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Previous Comments:
[2008-03-09 22:13:28] [EMAIL PROTECTED]
This is by design. The ctor does not allow by ref per design and this
is not going to change.
[2007-09-03 10:04:14] [EMAIL PROTECTED]
Assigned to the SPL maintainer.
[2007-09-03 10:02:05] [EMAIL PROTECTED]
Did you try the RCs released for PHP 5.2.4?
[2007-09-03 09:35:27] ahmadj at mediatrac dot net
Description:
At PHP 5.23 ArrayObject::offsetUnset() works as I expected, but at PHP
5.24 it doesn't work as I expected. The array offset doesn't
destroy/unset properly and it still reside in the array.
Reproduce code:
---
$ArrayField = array("clip.clip_id", "clip.clip_title",
"clip.clip_published_date", "media.media_name",
"conditional_category.conditional_id",
"conditional_category.conditional_name",
"client_category_set.client_cids",
"client_category_set.category_name");
$ArrayGroups = array("clip.clip_published_date",
"client_category_set.category_name", "clip.clip_title",
"clip.clip_id");
$collection = new ArrayObject($ArrayField);
for ($iter = $collection->getIterator(); $iter->valid();
$iter->next()) {
if (!in_array($iter->current(), $ArrayGroups)) {
$collection->offsetUnset($iter->key());
}
}
Expected result:
At PHP 5.22 & 5.23, the $arrayField at offset(3,4,5,6) get unset
properly, but when I try this code at PHP 5.24 the $arrayField at those
offsets didn't get unset as PHP 5.22/5.23 did.
--
Edit this bug report at http://bugs.php.net/?id=42527&edit=1
#42527 [Asn]: Regression with ArrayObject::offsetUnset(): not unsetting (works in 5.2.3)
ID: 42527
Updated by: [EMAIL PROTECTED]
Reported By: ahmadj at mediatrac dot net
Status: Assigned
Bug Type: SPL related
-Operating System: CentOS 5
+Operating System: *
-PHP Version: 5.2.4
+PHP Version: *
Assigned To: helly
New Comment:
This is by design. The ctor does not allow by ref per design and this
is not going to change.
Previous Comments:
[2007-09-03 10:04:14] [EMAIL PROTECTED]
Assigned to the SPL maintainer.
[2007-09-03 10:02:05] [EMAIL PROTECTED]
Did you try the RCs released for PHP 5.2.4?
[2007-09-03 09:35:27] ahmadj at mediatrac dot net
Description:
At PHP 5.23 ArrayObject::offsetUnset() works as I expected, but at PHP
5.24 it doesn't work as I expected. The array offset doesn't
destroy/unset properly and it still reside in the array.
Reproduce code:
---
$ArrayField = array("clip.clip_id", "clip.clip_title",
"clip.clip_published_date", "media.media_name",
"conditional_category.conditional_id",
"conditional_category.conditional_name",
"client_category_set.client_cids",
"client_category_set.category_name");
$ArrayGroups = array("clip.clip_published_date",
"client_category_set.category_name", "clip.clip_title",
"clip.clip_id");
$collection = new ArrayObject($ArrayField);
for ($iter = $collection->getIterator(); $iter->valid();
$iter->next()) {
if (!in_array($iter->current(), $ArrayGroups)) {
$collection->offsetUnset($iter->key());
}
}
Expected result:
At PHP 5.22 & 5.23, the $arrayField at offset(3,4,5,6) get unset
properly, but when I try this code at PHP 5.24 the $arrayField at those
offsets didn't get unset as PHP 5.22/5.23 did.
--
Edit this bug report at http://bugs.php.net/?id=42527&edit=1
#44084 [Opn->Bgs]: dividing problem
ID: 44084 Updated by: [EMAIL PROTECTED] Reported By: hosting at indiannic dot com -Status: Open +Status: Bogus Bug Type: Math related Operating System: windows 2000 PHP Version: 5.2.5 New Comment: [EMAIL PROTECTED] PHP_5_3]$ php -r 'var_dump(46985.532 / 3600 );' make: `sapi/cli/php' is up to date. float(13.05153667) [EMAIL PROTECTED] PHP_5_3]$ php -r '$t=46985.532/3600; var_dump($t);' make: `sapi/cli/php' is up to date. float(13.05153667) [EMAIL PROTECTED] PHP_5_3]$ php -r '$t=46985.532/3600; echo($t);' make: `sapi/cli/php' is up to date. [EMAIL PROTECTED] PHP_5_3]$ Same for 5.2 Previous Comments: [2008-02-09 15:56:57] hosting at indiannic dot com a few links below we have php 5 and php 4 both on the same server windows 2000 with iis 5 this is on php 5.2.5 http://maptelltrack.com/divide.php this gives correct Wrong answer this is on php 4.3.10 http://maptell.com/divide.php this gives correct answer [2008-02-09 14:58:03] hosting at indiannic dot com Description: dividing a float value with another gives result as 10 always Reproduce code: --- Expected result: 13.0515 Actual result: -- 10 -- Edit this bug report at http://bugs.php.net/?id=44084&edit=1
#44067 [Opn->Csd]: Implement hasChildren in SimpleXML
ID: 44067 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: N/A PHP Version: 5.2.5 New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Use SimpleXMLIterator :-) Previous Comments: [2008-02-07 04:29:27] [EMAIL PROTECTED] Description: SimpleXML provides the useful children() method to return the children of a given element, it returns E_WARNING if no children are present. As such, it would be useful to be able to ensure an element has children before attempting to retreive them. can i has cheezburger? or just bool SimpleXMLElement->hasChidren() -- Edit this bug report at http://bugs.php.net/?id=44067&edit=1
#44063 [Opn->Bgs]: RecursiveIteratorIterator needs rewind right after creation
ID: 44063
Updated by: [EMAIL PROTECTED]
Reported By: smirnov at h-type dot com
-Status: Open
+Status: Bogus
Bug Type: SPL related
-Operating System: Windows
+Operating System: *
PHP Version: 5.2.5
-Assigned To:
+Assigned To: helly
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
Flipe, your assumption is wrong. Adding rewind to the constructor would
result in a doubled call to rewind on the ArrayIterator.
Now the whole Iterator collection is designed to not duplicate any
calls and to be used by foreach. So you are basically missing the rewind
call, which by the way all examples with while have (at least my own
ones).
I might however look into this again and check whether I can do
something about the starting value in case of the missing rewind call on
the ArrayIterator.
Previous Comments:
[2008-02-07 01:07:59] [EMAIL PROTECTED]
Marcus, is my impression or is missing a rewind in this constructor?
http://felipe.ath.cx/diff/bug44063.diff
[2008-02-06 14:28:08] smirnov at h-type dot com
Description:
RecursiveIteratorIterator returns one extra result if we don't provide
rewind() before while.
Reproduce code:
---
$array = array(
array('name'=>'butch', 'sex'=>'male'),
array('name'=>'fido', 'sex'=>'male'),
array('name'=>'girly','sex'=>'female')
);
$it=new RecursiveIteratorIterator(new RecursiveArrayIterator($array));
//$it->rewind(); //The result will be as expected if uncomment this
while($it->valid()){
echo $it->key().' -- '.$it->current()."\n";
$it->next();
}
Expected result:
name -- butch
sex -- male
name -- fido
sex -- male
name -- girly
sex -- female
Actual result:
--
0 -- Array
name -- butch
sex -- male
name -- fido
sex -- male
name -- girly
sex -- female
--
Edit this bug report at http://bugs.php.net/?id=44063&edit=1
#44018 [Opn->Fbk]: RecursiveDirectoryIterator options inconsistancy
ID: 44018
Updated by: [EMAIL PROTECTED]
Reported By: jordan dot raub at dataxltd dot com
-Status: Open
+Status: Feedback
Bug Type: SPL related
Operating System: *
PHP Version: 5.2.5
Assigned To: helly
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
Can you './cvsclean' and rebuild 5.2 or at least 'touch
ext/spl/spl_directory.c && make' ? The last fix for 5.2 was only in the
headers and in my checks it worked correct.
Previous Comments:
[2008-02-04 22:08:20] jordan dot raub at dataxltd dot com
had to reopen it. php5.3cvs works fine but php5.2cvs fixed the error
but put added a bug..
php5.3cvs works fine. the test script I ran now give the appropriate
output:
$options not passed
string(21) "/virtualhosts/tmp/dir"
object(RecursiveDirectoryIterator)#1 (4) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["fileName":"SplFileInfo":private]=>
string(21) "/virtualhosts/tmp/dir"
["glob":"DirectoryIterator":private]=>
bool(false)
["subPathName":"RecursiveDirectoryIterator":private]=>
string(0) ""
}
string(52) "/virtualhosts/tmp/RecursiveDirectoryIteratorTest.php"
object(RecursiveDirectoryIterator)#1 (4) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["fileName":"SplFileInfo":private]=>
string(52) "/virtualhosts/tmp/RecursiveDirectoryIteratorTest.php"
["glob":"DirectoryIterator":private]=>
bool(false)
["subPathName":"RecursiveDirectoryIterator":private]=>
string(0) ""
}
$options = 0
string(21) "/virtualhosts/tmp/dir"
object(RecursiveDirectoryIterator)#2 (4) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["fileName":"SplFileInfo":private]=>
string(21) "/virtualhosts/tmp/dir"
["glob":"DirectoryIterator":private]=>
bool(false)
["subPathName":"RecursiveDirectoryIterator":private]=>
string(0) ""
}
string(52) "/virtualhosts/tmp/RecursiveDirectoryIteratorTest.php"
object(RecursiveDirectoryIterator)#2 (4) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["fileName":"SplFileInfo":private]=>
string(52) "/virtualhosts/tmp/RecursiveDirectoryIteratorTest.php"
["glob":"DirectoryIterator":private]=>
bool(false)
["subPathName":"RecursiveDirectoryIterator":private]=>
string(0) ""
}
$options = 10
string(21) "/virtualhosts/tmp/dir"
object(SplFileInfo)#4 (2) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["fileName":"SplFileInfo":private]=>
string(21) "/virtualhosts/tmp/dir"
}
string(52) "/virtualhosts/tmp/RecursiveDirectoryIteratorTest.php"
object(SplFileInfo)#2 (2) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["fileName":"SplFileInfo":private]=>
string(52) "/virtualhosts/tmp/RecursiveDirectoryIteratorTest.php"
}
$options = 100
string(3) "dir"
object(RecursiveDirectoryIterator)#1 (3) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["glob":"DirectoryIterator":private]=>
bool(false)
["subPathName":"RecursiveDirectoryIterator":private]=>
string(0) ""
}
string(34) "RecursiveDirectoryIteratorTest.php"
object(RecursiveDirectoryIterator)#1 (3) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["glob":"DirectoryIterator":private]=>
bool(false)
["subPathName":"RecursiveDirectoryIterator":private]=>
string(0) ""
}
$options = 110
string(3) "dir"
object(SplFileInfo)#4 (2) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["fileName":"SplFileInfo":private]=>
string(21) "/virtualhosts/tmp/dir"
}
string(34) "RecursiveDirectoryIteratorTest.php"
object(SplFileInfo)#1 (2) {
["pathName":"SplFileInfo&
#44018 [Opn->Csd]: RecursiveDirectoryIterator options inconsistancy
ID: 44018
Updated by: [EMAIL PROTECTED]
Reported By: jordan dot raub at dataxltd dot com
-Status: Open
+Status: Closed
Bug Type: SPL related
Operating System: *
PHP Version: 5.2.5
Assigned To: helly
New Comment:
This bug has been fixed in CVS.
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.
I Fixed this in PHP 5.2.6-dev and above along with the documentation.
Now 0 is CURRENT_AS_SELF and KEY_AS_PATHNAME.
Previous Comments:
[2008-02-04 18:12:39] jordan dot raub at dataxltd dot com
that last post was straight from cvs...
cvs -d :pserver:[EMAIL PROTECTED]:/repository checkout -r PHP_5_3
php5
[2008-02-04 18:11:04] jordan dot raub at dataxltd dot com
looking through the code it looks like DIT_CTOR_FLAGS shouldn't be sent
for the RecursiveDirectoryIterator. Maybe another flag should be sent
(RDIT_CTOR_FLAGS = 0x0010) and the flags sent to the
parse_parameters should be default SPL_FILE_DIR_CURRENT_AS_SELF to
denote that "this" should be a RecursiveDirectoryIterator?
$options not passed
string(21) "/virtualhosts/tmp/dir"
object(SplFileInfo)#3 (2) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["fileName":"SplFileInfo":private]=>
string(21) "/virtualhosts/tmp/dir"
}
string(52) "/virtualhosts/tmp/RecursiveDirectoryIteratorTest.php"
object(SplFileInfo)#4 (2) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["fileName":"SplFileInfo":private]=>
string(52) "/virtualhosts/tmp/RecursiveDirectoryIteratorTest.php"
}
$options = 0
string(21) "/virtualhosts/tmp/dir"
object(RecursiveDirectoryIterator)#2 (4) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["fileName":"SplFileInfo":private]=>
string(21) "/virtualhosts/tmp/dir"
["glob":"DirectoryIterator":private]=>
bool(false)
["subPathName":"RecursiveDirectoryIterator":private]=>
string(0) ""
}
string(52) "/virtualhosts/tmp/RecursiveDirectoryIteratorTest.php"
object(RecursiveDirectoryIterator)#2 (4) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["fileName":"SplFileInfo":private]=>
string(52) "/virtualhosts/tmp/RecursiveDirectoryIteratorTest.php"
["glob":"DirectoryIterator":private]=>
bool(false)
["subPathName":"RecursiveDirectoryIterator":private]=>
string(0) ""
}
$options = 10
string(21) "/virtualhosts/tmp/dir"
object(SplFileInfo)#3 (2) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["fileName":"SplFileInfo":private]=>
string(21) "/virtualhosts/tmp/dir"
}
string(52) "/virtualhosts/tmp/RecursiveDirectoryIteratorTest.php"
object(SplFileInfo)#2 (2) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["fileName":"SplFileInfo":private]=>
string(52) "/virtualhosts/tmp/RecursiveDirectoryIteratorTest.php"
}
$options = 100
string(3) "dir"
object(RecursiveDirectoryIterator)#4 (3) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["glob":"DirectoryIterator":private]=>
bool(false)
["subPathName":"RecursiveDirectoryIterator":private]=>
string(0) ""
}
string(34) "RecursiveDirectoryIteratorTest.php"
object(RecursiveDirectoryIterator)#4 (3) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["glob":"DirectoryIterator":private]=>
bool(false)
["subPathName":"RecursiveDirectoryIterator":private]=>
string(0) ""
}
$options = 110
string(3) "dir"
object(SplFileInfo)#3 (2) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["fileName":"SplFileInfo":private]=>
string(21) "/virtualhosts/tmp/dir"
}
string(34) "RecursiveDirectoryIteratorTest.php"
object(SplFileInfo)#4 (2) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/
#44043 [Opn]: Enforcing a method without specifying the arguments
ID: 44043
Updated by: [EMAIL PROTECTED]
Reported By: j dot boggiano at seld dot be
Status: Open
Bug Type: Class/Object related
-Operating System: Windows/Linux
+Operating System: *
PHP Version: 6CVS-2008-02-04 (snap)
New Comment:
What we could do is adding '...'. That way you can do stuff like:
interface Foo {
function bar($first, ...);
}
Now all classes that derive from Foo must implement the same function
protocol, for instance:
class Baz {
function bar($first, ...) {}
}
Anything else would violate the inheritance rules.
Previous Comments:
[2008-02-04 18:44:46] j dot boggiano at seld dot be
Description:
The purpose of this is to allow an abstract class or an interface to
enforce the implementation of a method, without however enforcing the
arguments signature.
This is -as I understand it- not a bug, but a feature request.
Reproduce code:
---
/***
* This works in PHP5 but does not anymore in PHP6
*/
class Parnt {
public function foo() {}
}
class Child extends Parnt {
public function foo($arg){}
}
/***
* Those don't work in either 5 or 6
*/
abstract class Abst {
abstract public function foo();
}
class Child2 extends Abst {
public function foo($arg){}
}
interface Int {
public function foo();
}
class Child3 implements Int {
public function foo($arg){}
}
Expected result:
/***
* Proposal for a solution
*/
abstract class AbstFixed {
abstract public function foo;
}
class Child4 extends AbstFixed {
public function foo($arg){}
}
// => Declaring the method without parenthesis (which currently throws
a parse error) would allow the implementations of this method to use any
argument signature they please.
Actual result:
--
At the moment those three examples throw a fatal error in PHP6 with :
Declaration of Child::foo() must be compatible with that of
Parnt::foo()
I don't think it is a bug, but I think having the capability to allow
variable function signatures would definitely be a plus, especially with
PHP6 coming that prevents the first example to work.
--
Edit this bug report at http://bugs.php.net/?id=44043&edit=1
#44018 [Opn->Fbk]: RecursiveDirectoryIterator options inconsistancy
ID: 44018
Updated by: [EMAIL PROTECTED]
Reported By: jordan dot raub at dataxltd dot com
-Status: Open
+Status: Feedback
Bug Type: SPL related
Operating System: *
PHP Version: 5.2.5
Assigned To: helly
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.3-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.3-win32-installer-latest.msi
There is indeed an issue. Can you update from cvs (5.3 or HEAD) and
try
again please?
Previous Comments:
[2008-02-04 16:22:56] jordan dot raub at dataxltd dot com
similar result with the latest snapshot...
$options not passed
string(21) "/virtualhosts/tmp/dir"
object(SplFileInfo)#3 (2) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["fileName":"SplFileInfo":private]=>
string(21) "/virtualhosts/tmp/dir"
}
string(52) "/virtualhosts/tmp/RecursiveDirectoryIteratorTest.php"
object(SplFileInfo)#4 (2) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["fileName":"SplFileInfo":private]=>
string(52) "/virtualhosts/tmp/RecursiveDirectoryIteratorTest.php"
}
$options = 0
string(21) "/virtualhosts/tmp/dir"
object(RecursiveDirectoryIterator)#2 (4) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["fileName":"SplFileInfo":private]=>
string(21) "/virtualhosts/tmp/dir"
["glob":"DirectoryIterator":private]=>
bool(false)
["subPathName":"RecursiveDirectoryIterator":private]=>
string(0) ""
}
string(52) "/virtualhosts/tmp/RecursiveDirectoryIteratorTest.php"
object(RecursiveDirectoryIterator)#2 (4) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["fileName":"SplFileInfo":private]=>
string(52) "/virtualhosts/tmp/RecursiveDirectoryIteratorTest.php"
["glob":"DirectoryIterator":private]=>
bool(false)
["subPathName":"RecursiveDirectoryIterator":private]=>
string(0) ""
}
$options = 10
string(21) "/virtualhosts/tmp/dir"
object(SplFileInfo)#3 (2) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["fileName":"SplFileInfo":private]=>
string(21) "/virtualhosts/tmp/dir"
}
string(52) "/virtualhosts/tmp/RecursiveDirectoryIteratorTest.php"
object(SplFileInfo)#2 (2) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["fileName":"SplFileInfo":private]=>
string(52) "/virtualhosts/tmp/RecursiveDirectoryIteratorTest.php"
}
$options = 100
string(3) "dir"
object(RecursiveDirectoryIterator)#4 (3) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["glob":"DirectoryIterator":private]=>
bool(false)
["subPathName":"RecursiveDirectoryIterator":private]=>
string(0) ""
}
string(34) "RecursiveDirectoryIteratorTest.php"
object(RecursiveDirectoryIterator)#4 (3) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["glob":"DirectoryIterator":private]=>
bool(false)
["subPathName":"RecursiveDirectoryIterator":private]=>
string(0) ""
}
$options = 110
string(3) "dir"
object(SplFileInfo)#3 (2) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["fileName":"SplFileInfo":private]=>
string(21) "/virtualhosts/tmp/dir"
}
string(34) "RecursiveDirectoryIteratorTest.php"
object(SplFileInfo)#4 (2) {
["pathName":"SplFileInfo":private]=>
string(17) "/virtualhosts/tmp"
["fileName":"SplFileInfo":private]=>
string(52) "/virtualhosts/tmp/RecursiveDirectoryIteratorTest.php"
}
[2008-02-04 14:39:06] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.3-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.3-win32-installer-latest.msi
-
#41748 [Asn->Fbk]: exif_read_data returns corrupted GPS data
ID: 41748
Updated by: [EMAIL PROTECTED]
Reported By: frederic dot maziere1 at neuf dot fr
-Status: Assigned
+Status: Feedback
Bug Type: EXIF related
Operating System: W2000 and WXP
PHP Version: 5.2.3, 4.4.7
Assigned To: helly
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.3-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.3-win32-installer-latest.msi
There is indeed an issue. Can you update from cvs (5.3 or HEAD) and try
again please?
Previous Comments:
[2007-06-20 12:37:57] frederic dot maziere1 at neuf dot fr
Description:
While it works on many files exif_read_data returns corrupted GPS data
on others.
exif_read_data returns bad latitude and longitude values for the
following file :
http://trekmaniac3.free.fr/Canaries2006/images/thumb/IMG_3801.jpg
FYI, xnview, robogeo (and others) are able to read and return correct
GPS data from that file. The expected values are :
latitude=27°38'26.39"
longitude=17°58'49.93"
When analyzing the data returns by exif_read_data, it looks like
there's a 3 value shift in the array of the rational values returned.
This problem occurs in every php version I tried : 4.3.10 or 5.2.0
Reproduce code:
---
$exif=exif_read_data('IMG_3801.jpg');
foreach ($exif as $key => $section) {
print_r($section);
foreach ($section as $name => $val) {
echo "$key.$name: $val\n";
}
}
Expected result:
GPSLatitude.0: 452984832/16777216
GPSLatitude.1: 637534208/16777216
GPSLatitude.2: 442812995/16777216
GPSLongitude.0:285212672/16777216
GPSLongitude.1:973078528/16777216
GPSLongitude.2:837753660/16777216
...
Actual result:
--
GPS tags returned :
GPSLatitude.0: 542065991/808334710
GPSLatitude.1: 3224110/452984832
GPSLatitude.2: 16777216/637534208
GPSLongitude.0: 16777216/442812995
GPSLongitude.1: 16777216/285212672
GPSLongitude.2: 16777216/973078528
GPSTimeStamp.0: 16777216/837753660
GPSTimeStamp.1: 16777216/9
GPSTimeStamp.2: 1/49
--
Edit this bug report at http://bugs.php.net/?id=41748&edit=1
#44032 [Opn]: Incorrect EXIF reading
ID: 44032 Updated by: [EMAIL PROTECTED] Reported By: ungu at terong dot com Status: Open Bug Type: EXIF related Operating System: Linux PHP Version: 5.2.5 -Assigned To: +Assigned To: helly New Comment: Please send files to [EMAIL PROTECTED], also what version of ACDSee are you using? I of course need the images before and after ACDSee touched them as well as what kind of info you added. If you compile PHP yourself then you can edit ext/exif/exif.c and change the line '#undef EXIF_DEBUG' to '#define EXIF_DEBUG 1'. When running PHP again you will get a detailed analysis of what might be wrong. Previous Comments: [2008-02-03 16:33:09] ungu at terong dot com Description: When I use exif_read_data() on some files edited using ACDSee, I got incorrect EXIF reading as follow: Make: -empty- Model: tal Imaging ... Software: Exif DateTime: NIKON CORPORATION I can send you the files if you need it. -- Edit this bug report at http://bugs.php.net/?id=44032&edit=1
#44018 [Opn->Fbk]: RecursiveDirectoryIterator options inconsistancy
ID: 44018
Updated by: [EMAIL PROTECTED]
Reported By: jordan dot raub at dataxltd dot com
-Status: Open
+Status: Feedback
Bug Type: SPL related
-Operating System: linux
+Operating System: *
PHP Version: 5.2.5
-Assigned To:
+Assigned To: helly
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.3-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.3-win32-installer-latest.msi
Previous Comments:
[2008-02-01 22:02:28] jordan dot raub at dataxltd dot com
(oops sorry... first paragraph should have been)
creating a new RecursiveDirectoryIterator with no options passed and 0
as the options passed give 2 different things. for nothing passed the
current value is an SplFileInfo while for a 0 passed a
RecursiveDirectoryIterator object is passed. I would think that sending
in 0 and nothing would give the same thing. Also in
RecursiveDirectoryIterator constructor (ext/spl/spl_directory.c line 965
php5.2.5 not CVS) the flags are automatically set to return an
SplFileInfo object, should this not be a RecursiveDirectoryIterator?
(correct me if i'm wrong)
[2008-02-01 21:56:38] jordan dot raub at dataxltd dot com
Description:
creating a new RecursiveDirectoryIterator with no options passes and 0
as the options passed give 2 different things. for nothing passed the
current value is a RecursiveDirectoryIterator while for a 0 passed a
SplFileInfo object is passed. I would think that sending in 0 and
nothing would give the same thing. Also in RecursiveDirectoryIterator
constructor (ext/spl/spl_directory.c line 965 php5.2.5 not CVS) the
flags are automatically set to return an SplFileInfo object, should this
not be a RecursiveDirectoryIterator? (correct me if i'm wrong)
also the documentation has the constants set:
const CURRENT_AS_FILEINFO RecursiveDirectoryIterator::x0010
const KEY_AS_FILENAME RecursiveDirectoryIterator::x0020
while from this test code they should be the following
const CURRENT_AS_FILEINFO RecursiveDirectoryIterator::x0010
const KEY_AS_FILENAME RecursiveDirectoryIterator::x0100
Thanks,
Jordan
Reproduce code:
---
#!/usr/lib/php5/bin/php
$file)
{
var_dump($key);
var_dump($file);
}
$options = 0;
printf("\$options = %x\n", $options);
foreach(new RecursiveDirectoryIterator(dirname(__FILE__), $options) as
$key => $file)
{
var_dump($key);
var_dump($file);
}
$options = 0;
$options |= RecursiveDirectoryIterator::CURRENT_AS_FILEINFO;
printf("\$options = %x\n", $options);
foreach(new RecursiveDirectoryIterator(dirname(__FILE__), $options) as
$key => $file)
{
var_dump($key);
var_dump($file);
}
$options = 0;
$options |= RecursiveDirectoryIterator::KEY_AS_FILENAME;
printf("\$options = %x\n", $options);
foreach(new RecursiveDirectoryIterator(dirname(__FILE__), $options) as
$key => $file)
{
var_dump($key);
var_dump($file);
}
$options = 0;
$options |= RecursiveDirectoryIterator::CURRENT_AS_FILEINFO;
$options |= RecursiveDirectoryIterator::KEY_AS_FILENAME;
printf("\$options = %x\n", $options);
foreach(new RecursiveDirectoryIterator(dirname(__FILE__), $options) as
$key => $file)
{
var_dump($key);
var_dump($file);
}
Expected result:
$options not passed
string(21) "/virtualhosts/tmp/dir"
object(RecursiveDirectoryIterator)#2 (0) {
}
string(52) "/virtualhosts/tmp/RecursiveDirectoryIteratorTest.php"
object(RecursiveDirectoryIterator)#2 (0) {
}
$options = 0
string(21) "/virtualhosts/tmp/dir"
object(RecursiveDirectoryIterator)#2 (0) {
}
string(52) "/virtualhosts/tmp/RecursiveDirectoryIteratorTest.php"
object(RecursiveDirectoryIterator)#2 (0) {
}
$options = 10
string(21) "/virtualhosts/tmp/dir"
object(SplFileInfo)#3 (0) {
}
string(52) "/virtualhosts/tmp/RecursiveDirectoryIteratorTest.php"
object(SplFileInfo)#2 (0) {
}
$options = 100
string(3) "dir"
object(RecursiveDirectoryIterator)#4 (0) {
}
string(34) "RecursiveDirectoryIteratorTest.php"
object(RecursiveDirectoryIterator)#4 (0) {
}
$options = 110
string(3) "dir"
object(SplFileInfo)#3 (0) {
}
string(34) "RecursiveDirectoryIteratorTest.php"
object(SplFileInfo)#4 (0) {
}
Actual result:
--
$options not passed
string(21) "/virtualhosts/tmp/dir"
object(SplFileInfo)#3 (0) {
}
string(52) "/virtualhosts/tmp/RecursiveDirectoryIteratorTest.php"
object(SplFileInfo)#4 (0) {
}
$options = 0
string(21) "/virtualhosts/tmp/dir"
object(RecursiveDirectoryIterator)#2 (0) {
}
string(52) "/virtualho
#43970 [Asn]: Crash if exif loaded before mbstring
ID: 43970 Updated by: [EMAIL PROTECTED] Reported By: bryan dot tongminh at gmail dot com Status: Assigned Bug Type: Dynamic loading Operating System: Windows Vista Bussiness 64 bits PHP Version: 5.2.5 Assigned To: jmertic New Comment: When we add mbstring as optional dependency for the case that it is not built in, would that fix the issue? Previous Comments: [2008-02-01 22:29:46] [EMAIL PROTECTED] Obviously installer bug since this is documented that mbstring must be before exif in php.ini. Assigned to our installer guru. [2008-01-29 17:00:39] bryan dot tongminh at gmail dot com Description: If php_exif.dll if loaded before php_mbstring.dll in php.ini, PHP crashes with the following error description: Probleemhandtekening: Gebeurtenisnaam van probleem: APPCRASH Naam van de toepassing: php-cgi.exe Versie van toepassing:5.2.5.5 Tijdstempel van toepassing: 4733dfaa Naam van foutmodule: php_mbstring.dll Versie van foutmodule:5.2.5.5 Tijdstempel van foutmodule: 4733e09e Uitzonderingscode:c005 Uitzonderingsmarge: 1a76 Versie van besturingssysteem: 6.0.6000.2.0.0.256.6 Landinstelling-id:1043 Aanvullende informatie 1: 8d13 Aanvullende informatie 2: cdca9b1d21d12b77d84f02df48e34311 Aanvullende informatie 3: 8d13 Aanvullende informatie 4: cdca9b1d21d12b77d84f02df48e34311 Lees onze privacyverklaring: http://go.microsoft.com/fwlink/?linkid=50163&clcid=0x0413 The Windows installer automatically sets php_exif.dll above php_mbstring.dll. -- Edit this bug report at http://bugs.php.net/?id=43970&edit=1
#43231 [Asn->Bgs]: array-based callback syntax is overly E_STRICT
ID: 43231
Updated by: [EMAIL PROTECTED]
Reported By: chuck at horde dot org
-Status: Assigned
+Status: Bogus
Bug Type: Scripting Engine problem
-Operating System: MacOS 10.4
+Operating System: *
-PHP Version: 5.3CVS-2007-11-10 (CVS)
+PHP Version: 5.2.*
-Assigned To: colder
+Assigned To: helly
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
This is indeed the correct behavior. You do not pass in a valid
callback. If you call hello() directly you get an E_STRICT. Now
call_user_func[_array]() tries to bind this function and cannot because
it is not a valid one. It used to work in 5.2 for BC sakes, because I
overlooked this in 5.0. When I first noticed this issue in 5.1, we
couldn't change it in 5.1 and we also decided to not change this in 5.2.
Previous Comments:
[2008-01-17 06:11:28] [EMAIL PROTECTED]
Ping?
[2007-11-25 20:08:47] [EMAIL PROTECTED]
Just a reminder on this, since you said you already had the patch?
[2007-11-14 08:03:15] [EMAIL PROTECTED]
And this is HEAD issue too, that's where I simply MFH'd the stuff that
broke this. :)
[2007-11-10 10:32:31] [EMAIL PROTECTED]
I already have a patch for that, will commit that once I'll boot the
other system
[2007-11-10 03:20:27] chuck at horde dot org
Description:
The callback syntax of array('classname', 'methodname') for making
static method calls is now enforcing E_STRICT even if E_STRICT is not
on. So methods that are not explicitly declared static can't be used
this way even with E_STRICT off. Putting static in front of the function
makes it work, but of course results in a parse error when the code is
run under PHP 4.
Reproduce code:
---
http://bugs.php.net/?id=43231&edit=1
#37076 [Asn->Csd]: SimpleXML ignores .=
ID: 37076 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: SimpleXML related Operating System: * -PHP Version: 5CVS-2007-08-15 (CVS) +PHP Version: 5.2.* Assigned To: helly New Comment: This bug has been fixed in CVS. 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: [2008-01-22 14:40:26] [EMAIL PROTECTED] A simple fix: http://ecl.zoone.com.br/etc/patches/bug37076.patch [2007-08-15 16:23:37] [EMAIL PROTECTED] (Updated version). Marcus: Still doesn't work.. :) [2006-05-27 10:40:24] [EMAIL PROTECTED] http://php.is/bugs/37076/bug37076.phpt (fails still) [2006-05-27 01:12:01] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Can you please write a test case? [2006-04-14 12:03:29] [EMAIL PROTECTED] Reproduced in HEAD It does however work in 5.0.. 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/37076 -- Edit this bug report at http://bugs.php.net/?id=37076&edit=1
#37964 [Asn->Csd]: Reflection shows private methods of parent class
ID: 37964
Updated by: [EMAIL PROTECTED]
Reported By: lavin dot peter at gmail dot com
-Status: Assigned
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: Windows XP
-PHP Version: 5.1.4
+PHP Version: 5.2.*
Assigned To: helly
New Comment:
This bug has been fixed in CVS.
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:
[2008-01-16 10:34:47] [EMAIL PROTECTED]
Assigned to the Reflection maintainer.
[2008-01-16 02:18:02] [EMAIL PROTECTED]
Simple fix:
Index: php_reflection.c
===
RCS file: /repository/php-src/ext/reflection/php_reflection.c,v
retrieving revision 1.164.2.33.2.45.2.6
diff -u -r1.164.2.33.2.45.2.6 php_reflection.c
--- php_reflection.c31 Dec 2007 07:17:13 -
1.164.2.33.2.45.2.6
+++ php_reflection.c16 Jan 2008 02:14:41 -
@@ -519,7 +519,8 @@
zend_hash_internal_pointer_reset_ex(&ce->function_table, &pos);
while
(zend_hash_get_current_data_ex(&ce->function_table, (void **) &mptr,
&pos) == SUCCESS) {
- if (!(mptr->common.fn_flags &
ZEND_ACC_STATIC)) {
+ if (!((mptr->common.fn_flags &
ZEND_ACC_STATIC) ||
+ ((mptr->common.fn_flags &
ZEND_ACC_PRIVATE) && mptr->common.scope != ce))) {
char *key;
uint key_len;
ulong num_index;
[2006-08-20 13:36:43] ruslan dot kyrychuk at gmail dot com
Maybe it is not valid to have private variables of parent class in
Reflection. Then it is only my own custom serialization problem.
[2006-08-20 12:39:18] ruslan dot kyrychuk at gmail dot com
With this serializing interface (if you mean __sleep and __wakeup
method) and with reflection can not work with private variables, I can
not write serialization method that can be used in all child classes .In
every child class Reflection will have child instance and will not have
access for private variables of parent.
Reproduce code:
---
class A
{
public function __sleep()
{
$refl = new ReflectionObject($this);
$props = $refl->getProperties();
$result = array();
foreach($props as $prop)
$result[] = $prop->getName();
return $result ;
}
private $privateVar = 'Test Private';
public $publicVar = 'Test Public';
public function setPublic($value)
{
$this->publicVar = $value;
}
public function setPrivate($value)
{
$this->privateVar = $value;
}
}
class B extends A{}
$instance = new B();
$instance->setPrivate('Set Test Private');
$instance->setPublic('Set Test Private');
var_dump($instance);
var_dump(unserialize(serialize($instance)));
Expected result:
Object before serializing and after is same.
Actual result:
--
object(B)#1 (2) {
["privateVar:private"]=>
string(16) "Set Test Private"
["publicVar"]=>
string(16) "Set Test Private"
}
object(B)#3 (2) {
["privateVar:private"]=>
string(12) "Test Private"
["publicVar"]=>
string(16) "Set Test Private"
}
--
When writing
public function __sleep(){return array('privateVar', 'publicVar');} In
B class
Than you'll get
Notice: serialize() [function.serialize]: "privateVar" returned as
member variable from __sleep() but does not exist.
So you can't write custom serializing for child object when private
properties exists in parent class.
[2006-08-20 11:07:59] [EMAIL PROTECTED]
That is why we have a new serializing interface which allows you to
call a serializing function in the base class which then can deal with
the private properties in that base class.
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/37964
--
Edit this bug report at http://bugs.php.net/?id=37964&edit=1
#43745 [Opn->WFx]: Scalar type hinting
ID: 43745 Updated by: [EMAIL PROTECTED] Reported By: sam at sambarrow dot com -Status: Open +Status: Wont fix Bug Type: Feature/Change Request -Operating System: Ubuntu Linux 7.04 +Operating System: * -PHP Version: 5.3CVS-2008-01-04 (CVS) +PHP Version: * New Comment: We will not implement scalar type hints. Check the archives on the exact why. For pure hinting you can use pecl/SPL_Types which will act like Java autoboxing. Previous Comments: [2008-01-04 04:51:27] sam at sambarrow dot com Description: Requesting support for scalar type hinting. I have a fully working patch written, I have been using it myself with no problems for a couple of months. Full specs: Type hinting patch allows for 8 new type hints, in addition to array and class type hinting. - Integers (specified by "int", "integer", or "long") - Floats (specified by "float", "double", or "real") - Numbers (matches integers and floats, specified by "num" or "number") - Strings (specified by "string") - Booleans (specified by "bool" or "boolean") - Scalars (matches strings, booleans, and numbers; specified by "scalar") - Resources (specified by "resource") - Objects (matches any object, specified by "object") -- Edit this bug report at http://bugs.php.net/?id=43745&edit=1
#43630 [Opn->Bgs]: exif_read_data crashes on certain images
ID: 43630 Updated by: [EMAIL PROTECTED] Reported By: erin at thedalzells dot org -Status: Open +Status: Bogus Bug Type: EXIF related Operating System: ALL PHP Version: 6CVS-2007-12-18 (CVS) 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 This simply tells you that your EXIF information is broken. Previous Comments: [2007-12-18 21:08:17] erin at thedalzells dot org Description: I have PHP version 5.2.3 and am getting an error on this image: http://thedalzells.org/photos/test/IMG_2982.JPG when I try to read the EXIF data with exif_read_data. I have looked at the other bug reports and they all say fixed in head for version 5.2.1. Reproduce code: --- $file = '/home/.jeannie/edalzell/thedalzells.org/photos/test/IMG_2982.JPG'; $data = exif_read_data($file, "EXIF"); Expected result: No errors Actual result: -- Warning: exif_read_data(IMG_2982.JPG) [exif_read_data]: Process tag(x=UndefinedTa): Illegal format code 0x, suppose BYTE in /home/.jeannie/edalzell/thedalzells.org/secret/core/core.functions.php(637) : eval()'d code on line 22 Warning: exif_read_data(IMG_2982.JPG) [exif_read_data]: Process tag(x=UndefinedTa): Illegal pointer offset(x6E004361 + x43616E6F = xB161B1D0 > x0207) in /home/.jeannie/edalzell/thedalzells.org/secret/core/core.functions.php(637) : eval()'d code on line 22 Warning: exif_read_data(IMG_2982.JPG) [exif_read_data]: Illegal IFD offset in /home/.jeannie/edalzell/thedalzells.org/secret/core/core.functions.php(637) : eval()'d code on line 22 -- Edit this bug report at http://bugs.php.net/?id=43630&edit=1
#43542 [Opn]: simpleXML thinks that comment is node
ID: 43542
Updated by: [EMAIL PROTECTED]
Reported By: 007not at gmail dot com
Status: Open
Bug Type: SimpleXML related
-Operating System: win xp sp2
+Operating System: *
PHP Version: 5.2.5
New Comment:
The comment is a node. What we actually need is a way to figure out the
xml type of a SimpleXMLElement instance (Element, Comment,...). This
will also have to return the internal SXE state (iterator for something
or direct value).
Previous Comments:
[2007-12-10 20:29:17] 007not at gmail dot com
hubert, you rigth about first test, i made mistake while i made posting
of this bug.
the right firts test looks such:
//first test
echo "node:";
var_dump($xml->node);
echo "notExitsNode:";
var_dump($xml->notExitsNode);
echo "otherNode:";
var_dump($xml->otherNode);
Expected result:
node:
object(SimpleXMLElement)[2]
public 'comment' =>
object(SimpleXMLElement)[4]
notExitsNode:
null
otherNode:
object(SimpleXMLElement)[2]
Actual result:
--
node:
object(SimpleXMLElement)[2]
public 'comment' =>
object(SimpleXMLElement)[4]
notExitsNode:
object(SimpleXMLElement)[2]
otherNode:
object(SimpleXMLElement)[2]
>Actually, that "comment" property might have been intentionally
created
as a way to indicate whether the node has a comment.
But it is illogical, and we will have "comments hell" like:
array(/*'comment' => 'value'*/) === array('comment' => 'value')
>As for your second test, I'm afraid it is incorrect
may be (because i tryed to count nodes, and it must be 1 1), but when
we use arrays we have problems with fake comments
$i = 0;
foreach ((array) $xml->node as $node)
{
$i++;
}
echo $i . "\n";
$i = 0;
foreach ((array) $xml->otherNode as $node)
{
$i++;
}
echo $i . "\n";
Expected result:
0
0
Actual result:
--
1
0
#
updated test:
value
XML;
$xml = simplexml_load_string($string);
//first test
echo "node:";
var_dump($xml->node);
echo "notExitsNode:";
var_dump($xml->notExitsNode);
echo "otherNode:";
var_dump($xml->otherNode);
/*
Expected result:
node:
object(SimpleXMLElement)[2]
public 'comment' =>
object(SimpleXMLElement)[4]
notExitsNode:
null
otherNode:
object(SimpleXMLElement)[2]
Actual result:
--
node:
object(SimpleXMLElement)[2]
public 'comment' =>
object(SimpleXMLElement)[4]
notExitsNode:
object(SimpleXMLElement)[2]
otherNode:
object(SimpleXMLElement)[2]
*/
//second test
$i = 0;
foreach ($xml->node as $node)
{
$i++;
}
echo $i . "\n";
$i = 0;
foreach ($xml->otherNode as $node)
{
$i++;
}
echo $i . "\n";
$i = 0;
foreach ((array) $xml->node as $node)
{
$i++;
}
echo $i . "\n";
$i = 0;
foreach ((array) $xml->otherNode as $node)
{
$i++;
}
echo $i . "\n";
/*
Expected result:
1
1
0
0
Actual result:
--
1
1
1
0
*/
//third test
var_dump($xml->node->comment);
var_dump($xml->otherNode->comment);
//check magic
echo "node:\n";
if (is_object($xml->node->comment))
{
echo "is_object === TRUE \n";
}
if (isset($xml->node->comment))
{
echo "isset === TRUE \n";
}
//but
if (strlen($xml->node->comment) > 0)
{
echo "strlen > 0\n";
}
if (strlen($xml->node->comment) == 0)
{
echo "strlen == 0\n";
}
echo "otherNode:\n";
if (is_object($xml->otherNode->comment))
{
echo "is_object === TRUE \n";
}
if (isset($xml->otherNode->comment))
{
echo "isset === TRUE \n";
}
/*
Expected result:
node:
is_object === TRUE
isset === TRUE
strlen == 0
otherNode:
is_object === TRUE
Actual result:
--
node:
is_object === TRUE
strlen == 0
otherNode:
is_object === TRUE
*/
[2007-12-09 14:39:46] hubert dot roksor at gmail dot com
Regarding your first test, I wouldn't consider that a bug. var_dump()
is a debugging tool, it may expose some of the behind-the-scene magic.
Actually, that "comment" property might have been intentionally created
as a way to indicate whether the node has a comment. That would explain
isset()'s behaviour in your third test, but in this case I would
recommand replacing that magical property with a method such as
$node->hasComment(). I guess Rob Richards will be able to shed some
light here.
As for your second test, I'm afraid it is incorrect: both $xml->node
and $xml->otherNode should return 1 element and I don't see why having a
comment as a child would change that.
[2007-12-09 11:02:10] 007not at gmail dot com
Description:
also see http://bugs.php.net/43392
>[EMAIL PROTECTED] comment:
>Th
#43450 [Opn]: Memory leak on some functions with implicit object __toString() call
ID: 43450
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Operating System: Any
PHP Version: 5.2.5
New Comment:
It appears that zend_std_cast_object_tostring() does not check whether
it has to dref readobj prior writing to writeobj in case they are the
same zval.
That said the code needs to be refactored to:
- if (readobj==writeobj) { zval_dtor(readobj); } // not zval_ptr_dtor
- call INIT_PZVAL(writeobj) always
- set Z_TYPE_P(writeobj) = IS_NULL; for the default case
Previous Comments:
[2007-11-30 01:34:56] [EMAIL PROTECTED]
I'm still not sure if this has anything to do with the new Zend parsing
API, but I've tested the md5 function with the zend_get_parameters_ex
(the old API) and the leak didn't occur. See the two version for a
comparison.
currently
PHP_NAMED_FUNCTION(php_if_md5)
{
char *arg;
int arg_len;
zend_bool raw_output = 0;
char md5str[33];
PHP_MD5_CTX context;
unsigned char digest[16];
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC,
"s|b", &arg, &arg_len, &raw_output) == FAILURE) {
return;
}
md5str[0] = '\0';
PHP_MD5Init(&context);
PHP_MD5Update(&context, arg, arg_len);
PHP_MD5Final(digest, &context);
if (raw_output) {
RETURN_STRINGL(digest, 16, 1);
} else {
make_digest_ex(md5str, digest, 16);
RETVAL_STRING(md5str, 1);
}
}
--- hacked rewrite
PHP_NAMED_FUNCTION(php_if_md5)
{
zval **zarg;
zend_bool raw_output = 0;
char md5str[33];
PHP_MD5_CTX context;
unsigned char digest[16];
if (ZEND_NUM_ARGS() != 1 ||
zend_get_parameters_ex(1, &zarg) == FAILURE) {
WRONG_PARAM_COUNT;
}
convert_to_string_ex(zarg);
md5str[0] = '\0';
PHP_MD5Init(&context);
PHP_MD5Update(&context, Z_STRVAL_PP(zarg), Z_STRLEN_PP(zarg));
PHP_MD5Final(digest, &context);
if (raw_output) {
RETURN_STRINGL(digest, 16, 1);
} else {
make_digest_ex(md5str, digest, 16);
RETVAL_STRING(md5str, 1);
}
}
[2007-11-29 14:59:48] [EMAIL PROTECTED]
Description:
Under certain circumenstances, the implicit call to __toString() on an
object may lead to memory leaks.
In the reproducable example, the following line leaks ($o is a simply
object):
md5($o);
But this line doesn't:
md5($o->__toString());
This only applies to certain functions, I've identifier md5, sha1 and
crc32.
If I try other examples like strstr or strlen, there's no leak at all.
A wild guess is that this maybe has to do whether the function
internally uses zend_parse_parameters() or zend_get_parameters_ex().
The function which leak use zend_parse_parameters(), the others don't.
But this may completely accidental.
It seems very related to bug#38591. However I don't see how bug#38604
is related to this issue (mentioned in bug#38591).
This leak was most notable found in an application which is supposed to
run for a long time, even hours. So usually within web application this
is not an issue.
Reproduce code:
---
__toString());
# does not leak either way
# strstr($o, 'f');
#strstr($o->__toString(), 'f');
if ($i % 1e3 == 0) {
printf("%u: %1.2f KB\n",
$i, memory_get_usage(true) / 1024);
}
}
Expected result:
Constant memory usage.
Actual result:
--
Memory grows and grows.
--
Edit this bug report at http://bugs.php.net/?id=43450&edit=1
#43519 [Opn->Csd]: stream_get_meta_data returns invalid mode
ID: 43519
Updated by: [EMAIL PROTECTED]
Reported By: ross dot lawley at gmail dot com
-Status: Open
+Status: Closed
Bug Type:Streams related
PHP Version: 5.2.5
New Comment:
Duplicate, see http://bugs.php.net/43510
Previous Comments:
[2007-12-06 17:10:42] dz at bitxtender dot com
As with the other bug report that was closed as bogus, the reproduce
code of course has to be:
$meta = stream_get_meta_data(fopen('http://www.google.com/', 'r'));
var_dump($meta['mode']);
The simple reason why this must work is because one might want to
serialize an object with a file pointer, and that can only be done by
grabbing the meta data on sleep, and restoring the stream on wakeup.
But
fopen() on an HTTP resource with r+ gives a warning that the stream
does
not support writing.
[2007-12-06 14:26:25] ross dot lawley at gmail dot com
Description:
When an fopen() is done on an HTTP URL with mode "r", the
stream_get_meta_data() result returns "r+"
Please reopen #43510 and close this bug because:
The mode parameter specifies the type of access you have to the
stream!
r > Open for reading only; place the file pointer at the beginning of
the file.
r+ > Open for reading and writing; place the file pointer at the
beginning of the file.
Its in the documentation the meta information *should* report the mode
it was opened with so that you can know what you access is to the stream
data, it might be handled elsewhere and not being able to rely on the
meta data is a BUG
Reproduce code:
---
$f = fopen('http://www.google.com/', 'r');
var_dump(stream_get_meta_data($f['mode']));
Expected result:
string 'r' (length=1)
Actual result:
--
string 'r+' (length=2)
--
Edit this bug report at http://bugs.php.net/?id=43519&edit=1
#43510 [Bgs->Opn]: stream_get_meta_data does not return same mode as used in fopen
ID: 43510
Updated by: [EMAIL PROTECTED]
Reported By: dz at bitxtender dot com
-Status: Bogus
+Status: Open
Bug Type: Streams related
Operating System: *
PHP Version: *
New Comment:
Reopening after discussions. David, please explain the reasoning
Previous Comments:
[2007-12-06 13:50:09] [EMAIL PROTECTED]
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
Why should the exact mode matter?
[2007-12-06 03:15:34] dz at bitxtender dot com
Description:
When an fopen() is done on an HTTP URL with mode "r", the
stream_get_meta_data() result returns "r+"
Reproduce code:
---
$meta = stream_get_meta_data(fopen('http://www.google.com/', 'r'));
var_dump($meta['mode']);
Expected result:
string 'r' (length=1)
Actual result:
--
string 'r+' (length=2)
[2007-12-06 02:18:22] dz at bitxtender dot com
Description:
When an fopen() is done on an HTTP URL with mode "r", the
stream_get_meta_data() result returns "r+"
Reproduce code:
---
$f = fopen('http://www.google.com/', 'r');
var_dump(stream_get_meta_data($f['mode']));
Expected result:
string 'r' (length=1)
Actual result:
--
string 'r+' (length=2)
--
Edit this bug report at http://bugs.php.net/?id=43510&edit=1
#41528 [Asn]: Classes extending ArrayObject do not serialize correctly
ID: 41528
Updated by: [EMAIL PROTECTED]
Reported By: m dot stach at ewerk dot com
Status: Assigned
Bug Type: SPL related
-Operating System: All
+Operating System: *
-PHP Version: 5.2.2
+PHP Version: 5.2.*
-Assigned To: helly
+Assigned To: davidc
New Comment:
There is a fix for it in 5.3.0 that needs a few tweaks, you can test it
for your usage already though. Assigning to david to do the tweaking.
Previous Comments:
[2007-08-05 15:31:25] pcdinh at gmail dot com
This bug remain still on PHP 5.2.4RC1
[2007-05-29 10:48:09] m dot stach at ewerk dot com
Description:
If a class extends ArrayObject, serializing does not work correctly.
All properties are missing after unserializing, only the array contents
are remain.
ArrayObjects (un)serializes without problems and does not implement the
Serializable interface, so there seems no need to change the
implementation of that interface.
The documentation mentions that it is not possible to serialize objects
of internal class. Since ArrayObject itself serializes fine, I regard
ArrayObject as "non-internal".
May be this is a documentation bug. But this would IMHO limit the broad
use of the ArrayObject class.
Reproduce code:
---
class a extends ArrayObject {
public $a = 2;
}
$a = new a();
$a->a = 1;
var_dump($a);
var_dump($a->a);
$a = unserialize(serialize($a));
var_dump($a);
var_dump($a->a);
Expected result:
object(a)#1 (1) { ["a"]=> int(1) }
int(1)
object(a)#1 (1) { ["a"]=> int(1) }
int(1)
Actual result:
--
object(a)#1 (0) { }
int(1)
object(a)#2 (0) { }
int(2)
--
Edit this bug report at http://bugs.php.net/?id=41528&edit=1
#43510 [Opn->Bgs]: stream_get_meta_data does not return same mode as used in fopen
ID: 43510
Updated by: [EMAIL PROTECTED]
Reported By: dz at bitxtender dot com
-Status: Open
+Status: Bogus
Bug Type: Streams related
-Operating System: Mac OS X 10.5.1
+Operating System: *
-PHP Version: 5.2.5
+PHP Version: *
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
Why should the exact mode matter?
Previous Comments:
[2007-12-06 03:15:34] dz at bitxtender dot com
Description:
When an fopen() is done on an HTTP URL with mode "r", the
stream_get_meta_data() result returns "r+"
Reproduce code:
---
$meta = stream_get_meta_data(fopen('http://www.google.com/', 'r'));
var_dump($meta['mode']);
Expected result:
string 'r' (length=1)
Actual result:
--
string 'r+' (length=2)
[2007-12-06 02:18:22] dz at bitxtender dot com
Description:
When an fopen() is done on an HTTP URL with mode "r", the
stream_get_meta_data() result returns "r+"
Reproduce code:
---
$f = fopen('http://www.google.com/', 'r');
var_dump(stream_get_meta_data($f['mode']));
Expected result:
string 'r' (length=1)
Actual result:
--
string 'r+' (length=2)
--
Edit this bug report at http://bugs.php.net/?id=43510&edit=1
#42681 [Asn->Bgs]: Static variables in sub/superclasses
ID: 42681
Updated by: [EMAIL PROTECTED]
Reported By: alex94040 at yahoo dot com
-Status: Assigned
+Status: Bogus
Bug Type: Class/Object related
Operating System: *
PHP Version: 5.2.4
Assigned To: helly
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
This is different from 28442. In fact the static variables are
different here as 28442 proves. However you are only using one of them.
You need to wait for LSB to make it into PHP and use the new syntax
then. This will most likely be solved in 5.3.0.
Previous Comments:
[2007-09-18 10:44:17] [EMAIL PROTECTED]
Marcus, can you reply to this please?
[2007-09-16 03:36:20] alex94040 at yahoo dot com
Description:
This is a reactivation of bug 28442; that bug shows as "fixed/closed",
but the issue still repros.
We need to be able to redefine static members of classes (including
constants), and set them independently.
Reproduce code:
---
class ClassA
{
private static $cn;
public static function setName( $cn )
{
self::$cn = $cn;
}
public static function getName( )
{
return self::$cn;
}
}
class ClassB extends ClassA
{
private static $cn; // with or without this, result is the same
}
ClassA::setName( 'AAA' );
ClassB::setName( 'BBB' );
print( ClassA::getName() . "\n" ); // prints 'BBB'
print( ClassB::getName() . "\n" ); // prints 'BBB'
Expected result:
Result should read "AAA BBB"
Actual result:
--
Result actually reads "BBB BBB"
--
Edit this bug report at http://bugs.php.net/?id=42681&edit=1
#38618 [Asn]: default implementation of hasChildren() in RecursiveArrayIterator does not work
ID: 38618 Updated by: [EMAIL PROTECTED] Reported By: mike at silverorange dot com Status: Assigned Bug Type: SPL related -Operating System: Linux +Operating System: * -PHP Version: 5.2.3 +PHP Version: 5.2.5 Assigned To: helly New Comment: So far the behavior is expected as ArrayObject/ArrayIterator follow arrays as well as objects. For 5.3 I added a new flag ArrayObject::CHILD_ARRAYS_ONLY that can be used to prevent ArrayIterator from following objects. IF you feel this is ok let me know. If you think the behavior should be reverse, meaning the flag should be active by default and there should be a way to disable it then open a RFC on [EMAIL PROTECTED] Previous Comments: [2007-08-20 15:01:23] [EMAIL PROTECTED] Marcus, can you check this out please? [2007-08-20 14:14:53] mike at silverorange dot com I played around with the test case a bit more and it seems that the default RecursiveArrayIterator iterates the public properties of objects within the arrays. For example, if I adda public $foo = 'bar' property to the Fruit class, I get the following (incorrect) output: Default recursive array iteraration: title => apple foo => bar title => orange foo => bar title => banana foo => bar title => grape foo => bar title => peach foo => bar title => strawberry foo => bar title => grapefruit foo => bar [2007-08-20 14:05:21] mike at silverorange dot com I tried changing the scope of the $title property from protected to public and the test case does indeed run correctly. Even so, the test case should still run correctly when the property is protected. [2007-08-20 10:34:33] [EMAIL PROTECTED] Replace "protected" with "public" and it works fine.. [2007-07-02 15:03:09] mike at silverorange dot com Sorray about that. Try this link: http://labs.silverorange.com/local/solabs/include/recursive-array-iterator.txt 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/38618 -- Edit this bug report at http://bugs.php.net/?id=38618&edit=1
#43167 [Ver->Asn]: ReflectionMethod::isConstructor() does not work for interfaces
ID: 43167
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Verified
+Status: Assigned
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.2.*
Assigned To: johannes
Previous Comments:
[2007-11-06 13:25:23] [EMAIL PROTECTED]
This is discussable as it is not really a constructor here. It simply
forces the protocol for the constructor. We do mark abstract
constructors as ctors though, so we imho should do so in interfaces as
well.
[EMAIL PROTECTED] PHP_5_3]$ php -r 'abstract class t{abstract function
__construct();} ReflectionClass::export("T");'
make: `sapi/cli/php' is up to date.
Class [ abstract class t ] {
@@ Command line code 1-1
- Constants [0] {
}
- Static properties [0] {
}
- Static methods [0] {
}
- Properties [0] {
}
- Methods [1] {
Method [ abstract public method __construct ] {
@@ Command line code 1 - 1
}
}
}
[2007-11-01 07:52:22] [EMAIL PROTECTED]
Description:
ReflectionMethod::isConstructor() does not work for methods that are
named __construct() in interfaces.
Reproduce code:
---
getMethod('__construct');
var_dump($constructor->isConstructor());
Expected result:
bool(true)
Actual result:
--
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=43167&edit=1
#22216 [Opn->WFx]: Named Arguments
ID: 22216
Updated by: [EMAIL PROTECTED]
Reported By: tim dot lokot at printsoft dot com
-Status: Open
+Status: Wont fix
Bug Type: Feature/Change Request
-Operating System: All
+Operating System: *
-PHP Version: 4.3.0
+PHP Version: *
New Comment:
This has been discussed and declined several times. Check the mail
archives for discussions.
Previous Comments:
[2007-11-09 17:52:02] zyss at mail dot zp dot ua
It is really needef feature to have in PHP. I miss this feature very
much when function has many arguments or when there are several boolean
arguments that require true/false values or when there are several
arguments with default value set and you want to use only, say, last
argument it would be very helpful to have named arguments support.
Having this feature would dramatically increase code readability.
Even standard functions will be easier to read having this feature. for
example:
in_array($needle, $haystack, $strict => true);
is much easier to read that just
in_array($needle, $haystack, true);
It would be more native to PHP to use named arguments with => like
foo(var2 => $value);
or
foo($var2 => $value);
[2006-06-14 11:48:29] jason at godsey dot net
$value) {
if(!isset($args["$key"])) {
if ($value == REQUIRED) {
$backtrace = debug_backtrace();
$function = $backtrace[1]["function"];
throw new Exception("function: $function var: \$$key not
defined");
}
$args[$key] = $value;
}
}
return 0;
}
function debugging ($args)
{
$defaults = array(
"name"=>"Lanny Jason Godsey",
"text"=>"This is the default text!",
"date"=>REQUIRED
);
parseRequired($defaults, $args);
print "($args[date]) Welcome $args[name], text entered:
$args[text]\n";
}
debugging(array("name"=>"L. Jason Godsey","date"=>date("Y-m-d")));
?>
[2003-02-13 16:59:47] tim dot lokot at printsoft dot com
I know this can be accomplished in other way and also know this has
been brought up before, but they are messy and require code from the
developer to handle this which seems to go against the php ethos of easy
and fast to develop.
If named arguments could be passed to functions and actually processed
by the php parser, then this would be really great. Especially where
function prototypes have default values in them and you only want to set
one of them. The proposed syntax would be something like this:
function foo ($var1="some value", $var2, $var3="some other value")
{
// function code
}
then to call the function would be like this
foo (var2:="value for argument 2 only");
This would also be great if this feature would extend to the existing
functions in the extensions as well.
mail (to:="[EMAIL PROTECTED]", message:="no message", subject:="subject");
This in my opinion makes the function calls more readable in some
circumstances, particularly when you have to keep going back to the
prototype to figure out what the order of the arguments is. It's kind
of self documenting really when you look at code written in this way.
Bug #2285: default arguments skipping
(http://bugs.php.net/bug.php?id=2285) was filed with a similar
suggestion and the solution suggested was to use associative arrays.
Becuase it was never explained in any of the other reports as to why
this wasn't going to be implemented, why the above not more preferable
to have than always have to implement the same code this:
function foo ($args)
{
// Named Argument Checks
$var1 = "some value";
$var3 = "some other value";
foreach ($args as $key => $value)
{
$$key = $value;
}
// Do function code here
}
foo (array ("var2"=>"some other value again","var1"=>"variable 1"));
Surely forcing developers into using this messy syntax goes against one
of the main strengths of php which is simple code that's easy to read,
understand and develop.
I'm in no wasy saying the above code was hard, just the first example
of named arguments seems to fit more into the php way than the second
example.
If this is to be rejected like the other requests for it, can you
please provide a reason why the array method is more preferable?
--
Edit this bug report at http://bugs.php.net/?id=22216&edit=1
#43277 [Opn->Bgs]: Interfaces behaving too much like classes
ID: 43277 Updated by: [EMAIL PROTECTED] Reported By: krister dot karlstrom at arcada dot fi -Status: Open +Status: Bogus Bug Type: Class/Object related Operating System: Linux/Slackware PHP Version: 5.2.5 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 PHP is class based OOP, not prototype based. Hence in your example there are two conflicting methods. Previous Comments: [2007-11-13 12:19:46] krister dot karlstrom at arcada dot fi Description: I found this "weird" mix-up of the behaviour of interfaces and abstract classes. I think that you should be able to always implement an interface, regardless of how and where some of the implemented methods where declared or defined. The only thing that should matter is that the declared class defines all the methods that the interface requires. The error message from PHP says that it can't inherit the method Test::foo() - an implementation of an interface has nothing to do with inheritance in classes in the OO-model. It shouldn't even try to "inherit" the methods of the interface, just check that the defined class implements all of the required methods. Reproduce code: --- Expected result: I expect this to raise no error, because the class FooBar nicely defines and implements the method foo(), as the interface Test defines. Actual result: -- [error] PHP Fatal error: Can't inherit abstract function Test::foo() (previously declared abstract in Bar) in /var/www/asta.arcada.fi/beta/foobar.php on line 13 -- Edit this bug report at http://bugs.php.net/?id=43277&edit=1
#43167 [Opn->Ver]: ReflectionMethod::isConstructor() does not work for interfaces
ID: 43167
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Verified
Bug Type: Scripting Engine problem
-Operating System: Irrelevant
+Operating System: *
-PHP Version: 5.3CVS-2007-11-01 (CVS)
+PHP Version: 5.2.*
New Comment:
This is discussable as it is not really a constructor here. It simply
forces the protocol for the constructor. We do mark abstract
constructors as ctors though, so we imho should do so in interfaces as
well.
[EMAIL PROTECTED] PHP_5_3]$ php -r 'abstract class t{abstract function
__construct();} ReflectionClass::export("T");'
make: `sapi/cli/php' is up to date.
Class [ abstract class t ] {
@@ Command line code 1-1
- Constants [0] {
}
- Static properties [0] {
}
- Static methods [0] {
}
- Properties [0] {
}
- Methods [1] {
Method [ abstract public method __construct ] {
@@ Command line code 1 - 1
}
}
}
Previous Comments:
[2007-11-01 07:52:22] [EMAIL PROTECTED]
Description:
ReflectionMethod::isConstructor() does not work for methods that are
named __construct() in interfaces.
Reproduce code:
---
getMethod('__construct');
var_dump($constructor->isConstructor());
Expected result:
bool(true)
Actual result:
--
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=43167&edit=1
#43154 [Fbk->Bgs]: __toArray() or __toIterator() Magic Method?
ID: 43154 Updated by: [EMAIL PROTECTED] Reported By: smoseley at transio dot com -Status: Feedback +Status: Bogus Bug Type: Feature/Change Request Operating System: Linux PHP Version: 5.2.4 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 There is also iterator_to_array(). Previous Comments: [2007-10-31 00:27:21] [EMAIL PROTECTED] What's wrong with the Iterator and IteratorAggregate interfaces? [2007-10-31 00:21:24] smoseley at transio dot com Description: Would love to see a __toArray() MM added that would default to an associative array of an object's properties in scope, but that could be overloaded with whatever. It would be very useful in cases where a specific method is required to iterate through an object's properties. Thanks! :) -- Edit this bug report at http://bugs.php.net/?id=43154&edit=1
#43083 [Opn->Bgs]: Protected method access from outside class.
ID: 43083 Updated by: [EMAIL PROTECTED] Reported By: purpurby at gmail dot com -Status: Open +Status: Bogus Bug Type: Class/Object related Operating System: RedHat PHP Version: 5.2.4 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 First part is perfectly right. As binding happens at compile time only relevant part is that C is-a A, hence inside C calls to A's protected members are fine. The other thing is a bit odd since technically C and B are different things. However what you call is inside A and both have A as a common root, hence that is fine as well. Previous Comments: [2007-10-23 14:22:52] purpurby at gmail dot com Description: Availability to call protected method from outside class or its descendants. Reproduce code: --- aa(); $obj2 = new b(); $obj2->aa(); } } $c = new c(); $c->cc(); ?> Expected result: Fatal error: Call to protected method a::aa() from context 'c' Actual result: -- a-aa b-aa -- Edit this bug report at http://bugs.php.net/?id=43083&edit=1
#43039 [Fbk]: Seg Fault (11) when using DB4 handler
ID: 43039
Updated by: [EMAIL PROTECTED]
Reported By: philippe dot gablain at gmail dot com
Status: Feedback
Bug Type: DBM/DBA related
Operating System: Linux Ubuntu 7.10
PHP Version: 5.2.4
New Comment:
What version of db 4.4 is that exactly?
Previous Comments:
[2007-10-21 15:44:11] [EMAIL PROTECTED]
just tried it with db4.4 (default on Ubuntu 7.10) and it crashed,
then I tried with db4.6 which works..
[2007-10-21 15:37:42] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
Works fine in CVS, could be an issue with a buggy db4 library.
[2007-10-19 14:45:08] philippe dot gablain at gmail dot com
Description:
Segmentation fault got anytime I call dba_open() since I upgraded from
Ubuntu 7.04 French to 7.10 French (Apache 2.2.4,PHP5.2.3).
Reproduce code:
---
$dbfile=" some ";
$id = dba_open ($dbfile, "n", "db4"); // tested wl or n
if (!$id) {
echo "dba_open failed\n";
exit;
}
dba_replace ("key", "some value", $id);
echo "\n";
if ($the_key = dba_firstkey($id)) do {
print("$the_key => ");
print dba_fetch($the_key, $id);
print("\n");
} while ($the_key = dba_nextkey($id));
echo "\n";
dba_close ($id);
Expected result:
key => some value
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1216125264 (LWP 1289)]
0x085d7410 in ?? ()
(gdb) bt
#0 0x085d7410 in ?? ()
#1 0xb71f09ad in dba_open_db4 () from
/usr/lib/apache2/modules/libphp5.so
#2 0xb71eefe5 in ?? () from /usr/lib/apache2/modules/libphp5.so
#3 0x08603d1c in ?? ()
#4 0xbfb590f8 in ?? ()
#5 0x0001 in ?? ()
#6 0x in ?? ()
--
Edit this bug report at http://bugs.php.net/?id=43039&edit=1
#42654 [Asn->Csd]: recursiveIteratorIterator modify only part of leaves
ID: 42654
Updated by: [EMAIL PROTECTED]
Reported By: ltaupiac at lfdj dot com
-Status: Assigned
+Status: Closed
Bug Type: SPL related
Operating System: windows
PHP Version: 5CVS-2007-09-13 (snap)
Assigned To: helly
New Comment:
This bug has been fixed in CVS.
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:
[2007-09-13 09:51:36] [EMAIL PROTECTED]
Assigned to the SPL maintainer.
[2007-09-13 09:48:31] ltaupiac at lfdj dot com
Description:
when recursively iterate over recursive array to alter leaves, only
first leaves are altered.
Reproduce code:
---
$data = array ('key1' => 'val1', array('key2' => 'val2'), 'key3' =>
'val3');
$iterator = new RecursiveIteratorIterator(new
RecursiveArrayIterator($data));
foreach($iterator as $foo) {
$key = $iterator->key();
switch($key) {
case 'key1': // first level
case 'key2': // recursive level
echo "update $key";
$iterator->offsetSet($key, 'alter');
}
}
$copy = $iterator->getArrayCopy();
var_dump($copy);
Expected result:
update key1
update key2
array(3) {
["key1"]=>
string(5) "alter"
[0]=>
array(1) {
["key2"]=>
string(4) "alter"
}
["key3"]=>
string(4) "val3"
}
Actual result:
--
update key1
update key2
array(3) {
["key1"]=>
string(5) "alter"
[0]=>
array(1) {
["key2"]=>
string(4) "val2"
}
["key3"]=>
string(4) "val3"
}
--
Edit this bug report at http://bugs.php.net/?id=42654&edit=1
#42703 [Asn->Csd]: Exception raised in an iterator::current() causes segfault in FilterIterator
ID: 42703 Updated by: [EMAIL PROTECTED] Reported By: daan at react dot nl -Status: Assigned +Status: Closed Bug Type: SPL related Operating System: * PHP Version: 5.2CVS-2007-09-18 Assigned To: helly New Comment: This bug has been fixed in CVS. 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: [2007-09-19 10:20:17] [EMAIL PROTECTED] [Switching to Thread -1209043264 (LWP 4604)] 0x081e1730 in spl_dual_it_fetch (intern=0x9935a3c, check_more=1, tsrm_ls=0x97fa050) at /home/jani/src/php-5.2/ext/spl/spl_iterators.c:1128 1128intern->current.data->refcount++; (gdb) bt #0 0x081e1730 in spl_dual_it_fetch (intern=0x9935a3c, check_more=1, tsrm_ls=0x97fa050) at /home/jani/src/php-5.2/ext/spl/spl_iterators.c:1128 #1 0x081e153d in zim_spl_dual_it_rewind (ht=0, return_value=0x9935c44, return_value_ptr=0x0, this_ptr=0x9932d44, return_value_used=1, tsrm_ls=0x97fa050) at /home/jani/src/php-5.2/ext/spl/spl_iterators.c:1161 #2 0x0830279e in zend_call_function (fci=0xbfe7cd74, fci_cache=0xbfe7cd48, tsrm_ls=0x97fa050) at /home/jani/src/php-5.2/Zend/zend_execute_API.c:1004 #3 0x0832b42a in zend_call_method (object_pp=0xbfe7cde0, obj_ce=0x986eb70, fn_proxy=0x986ecb4, function_name=0x85d3639 "rewind", function_name_len=6, retval_ptr_ptr=0x0, param_count=0, arg1=0x0, arg2=0x0, tsrm_ls=0x97fa050) at /home/jani/src/php-5.2/Zend/zend_interfaces.c:88 #4 0x0832bcc1 in zend_user_it_rewind (_iter=0x9935c00, tsrm_ls=0x97fa050) at /home/jani/src/php-5.2/Zend/zend_interfaces.c:252 #5 0x0837fa59 in ZEND_FE_RESET_SPEC_CV_HANDLER (execute_data=0xbfe7d004, tsrm_ls=0x97fa050) at /home/jani/src/php-5.2/Zend/zend_vm_execute.h:19980 #6 0x0833a206 in execute (op_array=0x9933548, tsrm_ls=0x97fa050) at /home/jani/src/php-5.2/Zend/zend_vm_execute.h:92 #7 0x083119f8 in zend_execute_scripts (type=8, tsrm_ls=0x97fa050, retval=0x0, file_count=3) at /home/jani/src/php-5.2/Zend/zend.c:1134 #8 0x082acd9b in php_execute_script (primary_file=0xbfe7f39c, tsrm_ls=0x97fa050) at /home/jani/src/php-5.2/main/main.c:1999 #9 0x08397a92 in main (argc=2, argv=0xbfe7f4f4) at /home/jani/src/php-5.2/sapi/cli/php_cli.c:1140 [2007-09-18 16:02:35] daan at react dot nl Description: When raising an exception in the current() method of an iterator while that iterator is being processed by either an IteratorIterator or FilterIterator causes PHP to crash. Reproduce code: --- $value) echo $value; Expected result: Exception thrown Actual result: -- #0 zim_spl_dual_it_rewind (ht=0, return_value=0xb7827e04, return_value_ptr=0x0, this_ptr=0xb7826d80, return_value_used=1) at /usr/src/php-5.2.4/ext/spl/spl_iterators.c:1128 #1 0x08327528 in zend_call_function (fci=0xbfa93970, fci_cache=0xbfa93950) at /usr/src/php-5.2.4/Zend/zend_execute_API.c:1004 #2 0x083447e0 in zend_call_method (object_pp=0xbfa939f0, obj_ce=0x86c73d0, fn_proxy=0x86c7500, function_name=0x85c5425 "rewind", function_name_len=6, retval_ptr_ptr=0x0, param_count=0, arg1=0x0, arg2=0x0) at /usr/src/php-5.2.4/Zend/zend_interfaces.c:88 #3 0x08344ded in zend_user_it_rewind (_iter=0xb7829124) at /usr/src/php-5.2.4/Zend/zend_interfaces.c:252 #4 0x0839af62 in ZEND_FE_RESET_SPEC_CV_HANDLER (execute_data=0xbfa93bb0) at /usr/src/php-5.2.4/Zend/zend_vm_execute.h:19980 #5 0x0834f5b9 in execute (op_array=0xb782726c) at /usr/src/php-5.2.4/Zend/zend_vm_execute.h:92 #6 0xb77cc44e in xdebug_execute (op_array=0xb782726c) at /tmp/pear/cache/xdebug-2.0.0RC3/xdebug.c:1487 #7 0x083341c4 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/php-5.2.4/Zend/zend.c:1134 #8 0x082f822a in php_execute_script (primary_file=0xbfa96030) at /usr/src/php-5.2.4/main/main.c:1982 #9 0x083b802f in main (argc=2, argv=0xbfa96104) at /usr/src/php-5.2.4/sapi/cli/php_cli.c:1140 -- Edit this bug report at http://bugs.php.net/?id=42703&edit=1
#42987 [Opn->Asn]: Add LSAPI support
ID: 42987
Updated by: [EMAIL PROTECTED]
Reported By: rick dot martinez at gmail dot com
-Status: Open
+Status: Assigned
Bug Type: Feature/Change Request
-Operating System: all
+Operating System: *
-PHP Version: 5.2.4
+PHP Version: 5.2.*
-Assigned To:
+Assigned To: chinstrap
New Comment:
This can imho go into 5.3 and looks pretty good already. You are
however not following our coding standards completely. Read
CODING_STYLE. Especially the following:
- keep { on same line if not beginning of a function or structure
- no // comments allowed
Apart from that you could shorten the code a bit by having /* {{{ */
after the function declaration and not on a separate line when not
adding comments.
As Johannes is the RM for 5.3 he has to decide about this mostly and
finally add the code.
Previous Comments:
[2007-10-16 11:13:00] rick dot martinez at gmail dot com
Description:
It would be great if support for the growing Litespeed web server could
be included with PHP. This especially because it's increasingly
difficult for people to support Litespeed with distributions such as
Debian which would require you to completely recompile the PHP deb
packages just to support the server.
I think the server is popular enough to warrant inclusion of their SAPI
into the PHP core. Many people are enjoying it and its popularity is
increasing.
Link to the SAPI:
http://www.litespeedtech.com/packages/lsapi/php-litespeed-4.1.tgz
--
Edit this bug report at http://bugs.php.net/?id=42987&edit=1
#42976 [Opn->Asn]: ReflectionClass::newInstance[Args]() crashes if ctor takes arg by reference
ID: 42976 Updated by: [EMAIL PROTECTED] Reported By: robin_fernandes at uk dot ibm dot com -Status: Open +Status: Assigned Bug Type: Reproducible crash -Operating System: Windows +Operating System: * -PHP Version: 5CVS-2007-10-15 (snap) +PHP Version: 5.2.4 -Assigned To: +Assigned To: chinstrap Previous Comments: [2007-10-15 18:03:58] felipensp at gmail dot com GDB: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1211603264 (LWP 6092)] 0x0826a03c in _zval_ptr_dtor (zval_ptr=0xbfae34c8) at /home/felipe/php5.2-200710131830/Zend/zend_execute_API.c:412 412 (*zval_ptr)->refcount--; - Backtrace: #0 0x0826a03c in _zval_ptr_dtor (zval_ptr=0xbfae34c8) at /home/felipe/php5.2-200710131830/Zend/zend_execute_API.c:412 #1 0x08156d72 in zim_reflection_class_newInstance (ht=1, return_value=0x847ef88, return_value_ptr=0x0, this_ptr=0x847eee0, return_value_used=0) at /home/felipe/php5.2-200710131830/ext/reflection/php_reflection.c:3452 #2 0x08294748 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfae375c) at /home/felipe/php5.2-200710131830/Zend/zend_vm_execute.h:200 #3 0x082937b9 in execute (op_array=0x847e540) at /home/felipe/php5.2-200710131830/Zend/zend_vm_execute.h:92 #4 0x082761f2 in zend_execute_scripts (type=8, retval=, file_count=3) at /home/felipe/php5.2-200710131830/Zend/zend.c:1134 #5 0x08235251 in php_execute_script (primary_file=0xbfae5b1c) at /home/felipe/php5.2-200710131830/main/main.c:2003 #6 0x082eecf5 in main (argc=2, argv=0xbfae5c34) at /home/felipe/php5.2-200710131830/sapi/cli/php_cli.c:1140 [2007-10-15 17:13:11] robin_fernandes at uk dot ibm dot com Description: In some cases, ReflectionClass::newInstance() and ReflectionClass::newInstanceArgs() can trigger a segmentation fault when the constructor of the reflected class takes arguments by reference. Tested on PHP 5.2.5-dev (cli) (built: Oct 15 2007 12:04:27) on Win XP. Reproduce code: --- newInstance($x); // causes crash var_dump($x); $x = "x.original"; $rc->newInstanceArgs(array($x)); // causes crash var_dump($x); ?> Expected result: string(9) "x.changed" string(9) "x.changed" string(10) "x.original" Actual result: -- string(9) "x.changed" *CRASH* -- Edit this bug report at http://bugs.php.net/?id=42976&edit=1
#37814 [Opn->WFx]: Php shoul have class friends
ID: 37814
Updated by: [EMAIL PROTECTED]
Reported By: henke dot andersson at comhem dot se
-Status: Open
+Status: Wont fix
Bug Type: Feature/Change Request
-Operating System: Linux Redhat 9
+Operating System: *
-PHP Version: 6CVS-2006-06-15 (CVS)
+PHP Version: *
New Comment:
We decided against those complex features.
Previous Comments:
[2007-08-06 22:29:49] michael at chunkycow dot com dot au
The whole C++ friends thing is a mess, use an interface between your
super friendly classes and simply don`t use it if the classes aren`t
joined at the hip, this would even help to keep nice low coupling and
aid re-use.
Private inner classes have some merit but are not a cure for common
sense.
[2006-06-15 10:33:27] henke dot andersson at comhem dot se
Description:
Php should have a friend structure for classes, like c++.
That way some normaly private things can be used by selected other
classes and functions.
An alternative would be to do it like Java with inner classes, but
personaly I think that while inner classes could be usefull in php,
friend classes should also exist like in c++.
Reproduce code:
---
privatefunction();
}
}
class B {
friend class A;
friend function C;
private function privatefunction() {
echo 'privatefunction!';
}
}
function C(B $b) {
$b->privatefunction();
}
$b=new B();
A::callB($b);
C($b);
Expected result:
Class A and function C should be able to call B::privatefunction.
Actual result:
--
Since this functionality doesn't exist the code wont even compile.
--
Edit this bug report at http://bugs.php.net/?id=37814&edit=1
#41942 [Opn->Bgs]: array() does not implement Traversable
ID: 41942
Updated by: [EMAIL PROTECTED]
Reported By: justin dot hendrickson+bugs dot php dot net at gmail
dot co
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: Any
PHP Version: 5.2.3
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
Arrays are no objects thus they cannot implement an interface.
Previous Comments:
[2007-07-09 18:55:11] justin dot hendrickson+bugs dot php dot net at
gmail dot co
Description:
Passing an array as a parameter with a type hint of Traversable causes
a fatal error. I'd be nice if the basic array type could implement this
interface so it can be used like this.
It appears this request is a duplicate of 33891, however it doesn't not
appear to have any activity for almost 1 year.
Reproduce code:
---
function traversableTest(Traversable $items) {
foreach($items as $item) {
echo $item;
}
}
traversableTest(array('one', 'two', 'three'));
Expected result:
onetwothree
Actual result:
--
Catchable fatal error: Argument 1 passed to traversableTest() must
implement interface Traversable, array given, called in
/home/jhendric/public_html/test.php on line 8 and defined in
/home/jhendric/public_html/test.php on line 2
--
Edit this bug report at http://bugs.php.net/?id=41942&edit=1
#42016 [Opn->Bgs]: Call to a parent's parent non-static method statically is allowed
ID: 42016
Updated by: [EMAIL PROTECTED]
Reported By: reto at buxaprojects dot com
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
-Operating System: FreeBSD
+Operating System: *
-PHP Version: 5.2.3
+PHP Version: *
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
It is just the way it works. If it sees it is coming from the right
context this call version doe snot enforce a static call. Instead it
will simply keep $this and be happy with it.
Previous Comments:
[2007-07-17 08:17:25] reto at buxaprojects dot com
Because a non-static method should not be called statically! This
should also apply for a parents parent class! Class C and B should only
be able to call parent:: . If class C must access the method test() of
class A, class B shouldn't override the method test().
[2007-07-17 07:51:34] [EMAIL PROTECTED]
And why do you think this is a bug?
[2007-07-17 06:24:58] reto at buxaprojects dot com
Description:
I expected, that i cannot call a non-static method in a parent's parent
class with ParentClassName::method() from a child class. But it works
even on E_STRICT. I think this should be a bug!
Reproduce code:
---
class A {
private $myVar;
public function test() {
$this->myVar = 'test';
echo 'A::test()' . "\n";
}
}
class B extends A {
public function test() {
echo 'B::test()' . "\n";
}
}
class C extends B {
public function test()
{
echo 'C::test()' . "\n";
A::test();
}
}
$c = new C;
$c->test();
Expected result:
Non-static method A::test() should not be called statically
Actual result:
--
C::test
A::test
--
Edit this bug report at http://bugs.php.net/?id=42016&edit=1
#41975 [Opn->Bgs]: SELF_FIRST constant missing
ID: 41975
Updated by: [EMAIL PROTECTED]
Reported By: kevin at oceania dot net
-Status: Open
+Status: Bogus
Bug Type: SPL related
Operating System: linux
PHP Version: 5CVS-2007-07-12 (snap)
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
RecursiveDirectoryIterator doesn't know about recursive iteration
process so it does not have a const SELF_FIRST. That is the domain of
RecursiveIteratorIterator. So you have to d:
new RII(new RCI(new RDI(...)))
there is: spl/examples/recursivetreeiterator.inc
which generalizes the handling of the tree graphics. But it works a bit
different. IT is an extended RecursiveIteratorIterator, so infact it
does know what to do with const SELF_FIRST. And it also handles the
caching automatically. Maybe we should put that into the extension
finally.
Previous Comments:
[2007-07-12 07:04:06] kevin at oceania dot net
Description:
When calling parent::SELF_FIRST with recursiveDirectoryIterator fatal
error
Reproduce code:
---
getDepth(); $i++)
{
$cur .= $this->getSubIterator($i)->hasNext() ? " | " : " ";
}
$i = $this->SubIterator($i);
return $cur . ($i->hasNext() ? " | - " : "/ - ").(string)$i;
}
} /*** end of class ***/
$obj = new DirectoryTreeIterator('albums');
Expected result:
directory list
Actual result:
--
Fatal error: Undefined class constant 'SELF_FIRST' in /www/web/test.php
on line 9
--
Edit this bug report at http://bugs.php.net/?id=41975&edit=1
#41678 [Opn->Bgs]: ArrayObject::getArrayCopy() gives strange results
ID: 41678
Updated by: [EMAIL PROTECTED]
Reported By: killgec at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: SPL related
-Operating System: winXp
+Operating System: *
PHP Version: 5.2.3
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
These strange chars are actually zero's. And that is simply the way PHP
encodes public and protected member variables.
Previous Comments:
[2007-06-13 12:10:31] killgec at gmail dot com
Description:
ArrayObject::getArrayCopy() returns not only public properties of an
object, but private and protected properties, too. These last two have
strange "inner-style" keys with illegal characters.
Documentation says that ArrayObject::getArrayCopy() returns array
created of public properties:
http://www.php.net/~helly/php/ext/spl/classArrayObject.html
Reproduce code:
---
class A {
public $a = 1;
protected $b = 2;
private $c = 3;
}
$a = new A();
$ao = new ArrayObject($a);
print_R($ao->getArrayCopy());
var_dump((array)$ao);
Expected result:
Array
(
[a] => 1
)
array(3) {
["a"]=>
int(1)
}
Actual result:
--
Array
(
[a] => 1
[< 1 illegal character here>*< 1 illegal character here>b] => 2
[< 1 illegal character here>A< 1 illegal character here>c] => 3
)
array(3) {
["a"]=>
int(1)
["< 1 illegal character here>*< 1 illegal character here>b"]=>
int(2)
["< 1 illegal character here>A< 1 illegal character here>c"]=>
int(3)
}
literally:
Array
(
[a] => 1
[�*�b] => 2
[�A�c] => 3
)
array(3) {
["a"]=>
int(1)
["�*�b"]=>
int(2)
["�A�c"]=>
int(3)
}
--
Edit this bug report at http://bugs.php.net/?id=41678&edit=1
#41648 [Opn->Bgs]: Turning fatal non-object/undefined errors into exceptions
ID: 41648
Updated by: [EMAIL PROTECTED]
Reported By: e dot a dot m dot huijbers at student dot tue dot nl
-Status: Open
+Status: Bogus
Bug Type:Feature/Change Request
PHP Version: 5.2.3
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
Test your code and use defensive coding techniques as in using
is_object here. Fatal errors also cannot be caught and passed to user
code in any way, that's why they are fatal.
Previous Comments:
[2007-06-11 10:24:20] e dot a dot m dot huijbers at student dot tue dot
nl
Description:
This bug report is in response to BUG#40014 (among others), wherein it
was said that uncatchable non-object/undefined function errors would not
be turned into exceptions, because that would require engine rewrites.
That bug has been closed, otherwise I would have posted there. I think
I have a solution that can be implemented without too much trouble,
increasing PHP's robustness in the area of exception handling.
(Why I would like this fixed; we're running a large system with a lot
of plug-ins. It's very frustrating that a simple error in one of the
plug-ins, like this:
---
$object = functionThatUsuallyReturnsAnObjectButNotThisTime();
$object->doSomething();
---
Brings the *whole system* down, even when we surround calls to plugins
with try/catch blocks).
To turn these errors into exceptions would allow them to be caught,
thereby affecting now the whole system, but just the plug-in itself.
All the tools to do this are trivially available. Solution:
---
if (!is_object($object)) throw new Exception("Not an object");
$object->doSomething();
---
The solution is quite easy, and works! However, having to write this
code for all thousands of method calls in any given production system is
very cumbersome to say the least, and would make PHP a very unattractive
language to use.
IMO, the PHP parser should emit code, equivalent to the above, on every
method call. If it did that, such "irrecoverable errors" would, in fact,
become recoverable, without requiring extra work on the part of the
user, and without changing any of the semantics of the involved
constructs (the method call).
The only extra work is a trivial modification of the parser/bytecode
emitter, but it would make writing large-scale systems a lot more
reliable and attractive.
For the people worried about performance, because there always are:
I would argue that the runtime of a typical PHP application is not
dominated by function calls, but by I/O operations (to the database,
over the wire, ...). In case where the extra check would notable affect
performance (i.e., in tight inner loops) an alternative call syntax
might be provided, that foregoes the extra is_object() check. This still
keeps all modifications in the parser. Note the change it will never
influence correctness, and increase reliability. One might argue that
these properties are far more important than performance.
For example, something like this could be introduced:
---
$object->doSomething(); /* With safety check */
$object-^doSomething(); /* Without safety check */
/* This is not proposed syntax, just an example. The real decision is
of course up to the language designers. */
---
(And please, please, do not tell me "this is not a bug". I have a lot
of respect for the people that design PHP, but the current behaviour
leaves a whole lot to be desired, and I highly doubt one could argue
that the current behaviour is intended. It is an artifact of some
underlying technical issues, sure, but that does not make it correct
behaviour.)
--
Edit this bug report at http://bugs.php.net/?id=41648&edit=1
#41614 [Opn->Bgs]: php 5.2.3
ID: 41614 Updated by: [EMAIL PROTECTED] Reported By: spetznaz at lnxclan dot com -Status: Open +Status: Bogus Bug Type: Unknown/Other Function -Operating System: RedHat es4 +Operating System: * -PHP Version: 5.2.3 +PHP Version: * New Comment: Nearly all changes we do during development of a new version a required for a specific demanding reason (often security). And actually running into this kind of problem is your very own issue. You should either help PHP development directly - guess after all it is open source - and if you are not willing to help then at least you should test new versions during their release candidate phase. Those phases are publicly announced and feedback is always been taken seriously. But then that would be helping PHP of course. Previous Comments: [2007-06-06 20:54:04] spetznaz at lnxclan dot com Bogus? It is NOT bogus! WE SPEND HOURS ON THIS CRAP ALL THE TIME THIS IS NOT BOGUS! Ask ANYONE who has been dealing with php for 1 year or more and tell me if this is bogus. The bug I am reporting is the inability of the dev team to adhere to standards that results in wasted time and money to support software that could be a great tool if the people that write it would take a little time to think about things before they release them. Compair php to any other app out there. No one else does this but php and I would bet my life on it that we are not the only people that get pissed off about this issue. At the least, make some docs! I dont hate php, I hate the way it is released. [2007-06-06 20:38:27] [EMAIL PROTECTED] . [2007-06-06 20:36:33] spetznaz at lnxclan dot com Description: Description: New versions of PHP mess everything up almost every time. Reproduce code: --- #!/bin/bash echo List the worst programmer that works on php read first echo Fire $first, and blame most of this crap on him. echo "" while echo List the next worst programmer; read dorks do echo Fire $dorks and replace with good programmer; echo "" done Expected result: I expect to see things compile like they did in version 5.2.2. Well, to tell the truth, now I expect to fight with php every time there is a new version... Wasted hours/days. Actual result: -- Nothing works and php does not log anything. Nothing. No docs, no logs... nothing. The result again is that we spend hours trying to get php to install and work. Only php gives us this many problems and takes this much time. Why? Because the dev team does not care about the people that use this software. If they did, they would not sneak new stuff in a version that will make php not work like it did. One word... deprecation. Learn it. Use it. This should have been called php 6.0 not 5.2.3. 5.x.x should compile, install and work the same. -- Edit this bug report at http://bugs.php.net/?id=41614&edit=1
#41525 [Asn->Csd]: ReflectionParameter::getPosition() not available
ID: 41525
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Assigned
+Status: Closed
Bug Type: Class/Object related
-Operating System: Gentoo
+Operating System: *
PHP Version: 5.2.2
Assigned To: helly
New Comment:
This bug has been fixed in CVS.
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:
[2007-05-29 08:26:10] [EMAIL PROTECTED]
getPosition() & getDeclaringFunction() are still ifdefed out
[2007-05-29 06:58:03] [EMAIL PROTECTED]
Description:
The reflection documentation states that there is a method
getPosition() on instances of ReflectionParameter since 5.1.3, but it
does not exist (at least here).
Reproduce code:
---
[EMAIL PROTECTED] ~ $ php -a
Interactive shell
php > function foo($param) {}
php > $fkt = new ReflectionFunction("foo");
php > $pars = $fkt->getParameters();
php > $par = $pars[0];
php > var_dump($par->getPosition());
---
[EMAIL PROTECTED] ~ $ php -a
Interactive shell
php > var_dump(get_class_methods("ReflectionParameter"));
Actual result:
--
Fatal error: Call to undefined method
ReflectionParameter::getPosition() in php shell code on line 1
Call Stack:
60.5766 68372 1. {main}() php shell code:0
---
array(12) {
[0]=>
string(6) "export"
[1]=>
string(11) "__construct"
[2]=>
string(10) "__toString"
[3]=>
string(7) "getName"
[4]=>
string(19) "isPassedByReference"
[5]=>
string(17) "getDeclaringClass"
[6]=>
string(8) "getClass"
[7]=>
string(7) "isArray"
[8]=>
string(10) "allowsNull"
[9]=>
string(10) "isOptional"
[10]=>
string(23) "isDefaultValueAvailable"
[11]=>
string(15) "getDefaultValue"
}
--
Edit this bug report at http://bugs.php.net/?id=41525&edit=1
#41461 [Opn->Bgs]: Odd E_STRICT notice raised when using Interfaces
ID: 41461 Updated by: [EMAIL PROTECTED] Reported By: ralph at smashlabs dot com -Status: Open +Status: Bogus Bug Type: Class/Object related -Operating System: Linux +Operating System: * -PHP Version: 5.2.2 +PHP Version: * 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 PHP follows strict is_a inheritance. By the way, it is called signature and even if you could change it it would not solve the problem. And anyway it would break inheritance rules. Previous Comments: [2007-05-21 23:06:13] ralph at smashlabs dot com Description: When an interface is a parent of a class, the interface is implying a specific profile for a given function (here its __get) even though it is not defined in the interface itself. This is making it impossible to overload and/or change the profile of the function in a descendant class. Reproduce code: --- The following will produce this notice: Strict Standards: Declaration of Z_Concrete::__get() should be compatible with that of Z_Abstract::__get() in xxx on line 16 http://bugs.php.net/?id=41461&edit=1
#41162 [Opn->Csd]: Interface methods not implementable using __call
ID: 41162
Updated by: [EMAIL PROTECTED]
Reported By: bugs dot php dot net dot nsp at cvogt dot org
-Status: Open
+Status: Closed
Bug Type: Class/Object related
-Operating System: Windows XP Professional SP2
+Operating System: *
-PHP Version: 5.2.1
+PHP Version: *
New Comment:
Sorry for the type, it should read "mixing".
Once again. Interfaces are declared stuff - __call is not.
Since PHP does not have templates and will never have them that is the
end of the story.
Well you could experiment with pecl/runkit' runkit_method_add().
Previous Comments:
[2007-05-01 21:30:19] bugs dot php dot net dot nsp at cvogt dot org
Isn't __call a reasonable way to implement methods? Sorry to re-open
this one, but I am not convinced of the opposite yet. But I am open for
an explanation.
[2007-04-22 15:06:59] bugs dot php dot net dot nsp at cvogt dot org
Thank you for the quick reply and the proposed generic function body.
What do you mean by "You would be missing two completely different
things, descriptive and non descriptive semantic elements."?
I could use
function () {
$args = func_get_args(); return $this->__call(__FUNCTION__, $args);
}
(which fixes 2 bugs in your suggestion) but I would prefer an
abstraction over copy&paste.
[2007-04-22 13:21:55] [EMAIL PROTECTED]
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 would be missing two completely different things, descriptive and
non descriptive semantic elements.
What you can do is providing the implementation of the interface
methods all with the same body:
function () {
return $this->__call(array($this, __FUNCTION__), func_get_args());
}
where and have to be replaced with the method name
in question and its parameters respectively.
[2007-04-22 13:11:39] bugs dot php dot net dot nsp at cvogt dot org
Description:
When implementing an interface one cannot use __call to implement
methods as this will lead to a FATAL ERROR. However it would be quite
convenient if one could do this. It would e.g. allow to generically pass
on method calls to an object that is stored in a local variable and
implements the interface.
Reproduce code:
---
interface MyInterface{
public function myMethod();
}
class MyImplementation implements MyInterface{
public function __call( $method, $parameters ){
// do something
}
}
Expected result:
__call takes care of not explicitly implemented methods declared in
MyInterface.
Actual result:
--
Fatal error: Class MyImplementation contains 1 abstract method and
must therefore be declared abstract or implement the remaining methods
(MyInterface::myMethod)
--
Edit this bug report at http://bugs.php.net/?id=41162&edit=1
#41172 [Opn->Fbk]: SimpleXML empty attributes
ID: 41172
Updated by: [EMAIL PROTECTED]
Reported By: fedelman at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: DOM XML related
Operating System: *
PHP Version: 5.2.1
Previous Comments:
[2007-04-23 17:42:26] [EMAIL PROTECTED]
Try: var_dump($oXML[0]);
[2007-04-23 15:41:14] fedelman at gmail dot com
Description:
When I've got a node with one attribute and text, the SimpleXML does
not return the attribute, it only return the text.
Please, see the example.
I think may be it's this is a bug.
Reproduce code:
---
$strXml = "
This is the text
";
$oXML=simplexml_load_string($strXml);
echo "";
var_dump($oXML);
echo "";
Expected result:
object(SimpleXMLElement)#1 (2) {
["@attributes"]=>
array(1) {
["myattr1"]=>
string(17) "This is the value"
}
string(16) "This is the text"
}
Actual result:
--
object(SimpleXMLElement)#1 (1) {
["data"]=>
string(16) "This is the text"
}
--
Edit this bug report at http://bugs.php.net/?id=41172&edit=1
#41172 [Opn]: SimpleXML empty attributes
ID: 41172
Updated by: [EMAIL PROTECTED]
Reported By: fedelman at gmail dot com
Status: Open
Bug Type: DOM XML related
-Operating System: Gentoo Linux
+Operating System: *
PHP Version: 5.2.1
New Comment:
Try: var_dump($oXML[0]);
Previous Comments:
[2007-04-23 15:41:14] fedelman at gmail dot com
Description:
When I've got a node with one attribute and text, the SimpleXML does
not return the attribute, it only return the text.
Please, see the example.
I think may be it's this is a bug.
Reproduce code:
---
$strXml = "
This is the text
";
$oXML=simplexml_load_string($strXml);
echo "";
var_dump($oXML);
echo "";
Expected result:
object(SimpleXMLElement)#1 (2) {
["@attributes"]=>
array(1) {
["myattr1"]=>
string(17) "This is the value"
}
string(16) "This is the text"
}
Actual result:
--
object(SimpleXMLElement)#1 (1) {
["data"]=>
string(16) "This is the text"
}
--
Edit this bug report at http://bugs.php.net/?id=41172&edit=1
#41166 [Opn->Bgs]: fpassthru and the other read-Funktions are very very slow
ID: 41166
Updated by: [EMAIL PROTECTED]
Reported By: alex dot taeffner at vr-web dot de
-Status: Open
+Status: Bogus
Bug Type: Sockets related
-Operating System: Debian Linux
+Operating System: *
-PHP Version: 5.2.1
+PHP Version: *
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
The long time for the original code is obviously a result of running
into a timeout, which has nothing to do with PHP. It appears you need to
figure out how the protocol tells you when the answer is sent out
completely. This has nothing to do with PHP at all.
Previous Comments:
[2007-04-22 20:55:44] alex dot taeffner at vr-web dot de
I've just found out another thing:
If I close the TCP-Connection (Telnet) before I use the command it
works fine.
I mean it like that:
fputs($TS_link, "dbuserid 2\n");
fputs($TS_link, "quit\n");
while(!feof($TS_link)) {
$out .= fgets($TS_link, 1024);
}
print $out;
Works fine!
BUT
fputs($TS_link, "dbuserid 2\n");
while(!feof($TS_link)) {
$out .= fgets($TS_link, 1024);
}
print $out;
lasts very verry long!
My big problem:
I cannot quit before I have read it because I want to read a value of
the answer and use it in the next query.
Is there another way?
[2007-04-22 20:18:50] alex dot taeffner at vr-web dot de
Description:
Every Function which reads the answar of a TCP-Server Completely (since
the last read (Pointer-Position to EOF)) hangs very long while executing
the script.
fputs($TS_link, "help\n");
Well...
If I write
print fread($TS_link, 1024);
The Script returns the LAST line: OK
If I write
fpassthru($TS_link);
The Script loads more than a minute and returns ALL LINES since the
last read.
It doesnt matter if there are yust two lines or een one line or if
there are 100 lines to read.
Even if I write
while (!feof($TS_link)) {
print fgets($TS_link);
}
or
while (!feof($TS_link)) {
print fread($TS_link);
}
It is the same Problem.
It occurs whith every possibility.
--
Edit this bug report at http://bugs.php.net/?id=41166&edit=1
#41162 [Opn->Bgs]: Interface methods not implementable using __call
ID: 41162
Updated by: [EMAIL PROTECTED]
Reported By: bugs dot php dot net dot nsp at cvogt dot org
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: Windows XP Professional SP2
PHP Version: 5.2.1
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 would be missing two completely different things, descriptive and
non descriptive semantic elements.
What you can do is providing the implementation of the interface
methods all with the same body:
function () {
return $this->__call(array($this, __FUNCTION__), func_get_args());
}
where and have to be replaced with the method name
in question and its parameters respectively.
Previous Comments:
[2007-04-22 13:11:39] bugs dot php dot net dot nsp at cvogt dot org
Description:
When implementing an interface one cannot use __call to implement
methods as this will lead to a FATAL ERROR. However it would be quite
convenient if one could do this. It would e.g. allow to generically pass
on method calls to an object that is stored in a local variable and
implements the interface.
Reproduce code:
---
interface MyInterface{
public function myMethod();
}
class MyImplementation implements MyInterface{
public function __call( $method, $parameters ){
// do something
}
}
Expected result:
__call takes care of not explicitly implemented methods declared in
MyInterface.
Actual result:
--
Fatal error: Class MyImplementation contains 1 abstract method and
must therefore be declared abstract or implement the remaining methods
(MyInterface::myMethod)
--
Edit this bug report at http://bugs.php.net/?id=41162&edit=1
#41145 [Opn->Bgs]: Interface, Abstract Class & Methods
ID: 41145
Updated by: [EMAIL PROTECTED]
Reported By: gerald at copix dot org
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: Linux
PHP Version: 5.2.1
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
This kind of inhereitance trickery is only useful and working in
languages that support MI and there you need to have the leave class
reimplement the method or explicitly use one of the base class'
implementation regardless of whether you provide new code or not. This
is the case because both the abstract class and the interface are two
independant origins of the method. Thus they are considered different.
What you can do instead is having a basic interface that only contains
the shared method. Doing so is absolutely correct because as you say
they are the same protocol entity. And if you were not able to ürovide a
shared base for them, than indeed the methods are different.
Previous Comments:
[2007-04-20 08:00:05] gerald at copix dot org
Description:
When we want to implement an interface in a child class that extends an
abstract class that contains an abstract method that is in the
interface, we get an error.
This kind of bug has already been submited in #35057 and was marked as
bogus because AClasse::show obviously is not the same as IClasse::show.
But in the code we only say that IClasse::show is the same as
AClasseConcrete::show.
To me, the IClasse should not care how AClasseConcrete manage to
implements the interface. The important thing is that
AClasseConcrete::show IS the same as IClasse::show.
I've checked the documentation and was not able to find this exact case
and I've try this concept in other langages (like Java) with success.
I think at least it should be discussed.
If it has been discussed already, I'm really sorry for the time I made
you spent on this.
Greatings
Reproduce code:
---
interface IClasse {
public function show ();
}
abstract class AClasse {
abstract public function show ();
}
class AClasseConcrete extends AClasse implements IClasse {
public function show (){
echo "Everything is ok";
}
}
$classe = new AClasseConcrete ();
$classe->show ();
Expected result:
"Everything is ok"
Actual result:
--
Fatal error: Can't inherit abstract function IClasse::show()
(previously declared abstract in AClasse) in
/home/geraldc/workspace/Copix_3/www/syntax_playground.php
--
Edit this bug report at http://bugs.php.net/?id=41145&edit=1
#41124 [Opn->WFx]: set an
ID: 41124 Updated by: [EMAIL PROTECTED] Reported By: mmassonnet at gmail dot com -Status: Open +Status: Wont fix Bug Type: Feature/Change Request Operating System: * PHP Version: 5.2.1 Previous Comments: [2007-04-17 17:25:25] [EMAIL PROTECTED] If at all we *could* do somethign that is XML compliant like ". I find this really handy and I had like to use something the like without small tags. Could you add an equal alias with long tags only, e.g. ? Regards, Mike -- Edit this bug report at http://bugs.php.net/?id=41124&edit=1
#41124 [Opn]: set an
ID: 41124 Updated by: [EMAIL PROTECTED] Reported By: mmassonnet at gmail dot com Status: Open Bug Type: Feature/Change Request -Operating System: +Operating System: * PHP Version: 5.2.1 New Comment: If at all we *could* do somethign that is XML compliant like ". I find this really handy and I had like to use something the like without small tags. Could you add an equal alias with long tags only, e.g. ? Regards, Mike -- Edit this bug report at http://bugs.php.net/?id=41124&edit=1
#41109 [Opn->Csd]: recursiveiterator.inc says "implements" Iterator instead of "extends"
ID: 41109
Updated by: [EMAIL PROTECTED]
Reported By: diogo86 at gmail dot com
-Status: Open
+Status: Closed
Bug Type: SPL related
Operating System: *
PHP Version: 5.2.1
Assigned To: helly
New Comment:
This bug has been fixed in CVS.
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:
[2007-04-17 02:10:22] diogo86 at gmail dot com
Description:
The interface RecursiveIterator "implements" Iterator, where the syntax
requires it to "extends".
Reproduce code:
---
interface RecursiveIterator implements Iterator
{
/** @return whether the current element has children
*/
function hasChildren();
/** @return the sub iterator for the current element
* @note The returned object must implement RecursiveIterator.
*/
function getChildren();
}
Expected result:
interface RecursiveIterator extends Iterator
{
/** @return whether the current element has children
*/
function hasChildren();
/** @return the sub iterator for the current element
* @note The returned object must implement RecursiveIterator.
*/
function getChildren();
}
Actual result:
--
The interface RecursiveIterator at
ext/spl/internals/recursiveiterator.inc is using the wrong syntax
"implements" instead of "extends", just like the OuterIterator correctly
does for example.
It works anyway but also affects the documentation generated by
doxygen.
--
Edit this bug report at http://bugs.php.net/?id=41109&edit=1
#41106 [Opn->Fbk]: Simple Expression But Doing Wrong Calculation
ID: 41106 Updated by: [EMAIL PROTECTED] Reported By: neel dot basu dot z at gmail dot net -Status: Open +Status: Feedback Bug Type: Math related Operating System: Windows PHP Version: 5.1.6 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Previous Comments: [2007-04-16 18:05:29] neel dot basu dot z at gmail dot net I am Using php 5.1.6 [2007-04-16 18:03:16] neel dot basu dot z at gmail dot net Description: Simple Expression but wrong output. Reproduce code: --- Evaluates to Zero $res2 = (2.2-0.1)-2.1;// = 2.1-2.1 -> Also Evaluates to Zero echo $res1."\t".gettype($res1); echo "\n"; echo $res2."\t".gettype($res2); ?> Expected result: 0 double 0 double Actual result: -- -2.22044604925E-016 double 0 double -- Edit this bug report at http://bugs.php.net/?id=41106&edit=1
#41096 [Opn->Bgs]: Warning: SimpleXMLElement::children() expects at most 1 parameter, 2 given
ID: 41096
Updated by: [EMAIL PROTECTED]
Reported By: mistknight at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: SimpleXML related
Operating System: kubuntu 6.10 edgy
PHP Version: 5.2.1
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The second parameter is available since 5.2.0. So if itis not existing,
you must be using 5.0.* or 5.1.*.
Previous Comments:
[2007-04-16 03:54:56] mistknight at gmail dot com
Description:
I'm using PHP 5.2.0 and I'm getting this warning:
Warning: SimpleXMLElement::children() expects at most 1 parameter, 2
given
on this line of code:
$content = (array)$news->children('content',TRUE);
The problem seems like it's transient sometimes appearing and sometimes
not :-( I downloaded PHP 5.2.1 and it's not happening but I can't really
be sure weather it's solved or not. Especially since i can't find any
mention of it in the bug tracking system!
I can always suppress the warning and everything would work fine. But
it just doesn't seem right to me. Hope someone can shed some light on
this.
--
Edit this bug report at http://bugs.php.net/?id=41096&edit=1
#41090 [Opn->Bgs]: can't override inherited private methods
ID: 41090
Updated by: [EMAIL PROTECTED]
Reported By: ozone at cname dot com
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: linux
PHP Version: 5.2.1
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
Calling scope matters
Previous Comments:
[2007-04-15 01:12:20] ozone at cname dot com
Description:
The page on Visibility states: "Private limits visibility only to the
class that defines the item." Apparently, private methods may not be
superseded by a child of that class; in the following code, a new object
e inherits the __constructor() which calls "$this->df", but because f()
is declared private, it is silently not overridden. This behavior may
not constitute a "bug" in the context of PHP inheritance, but it
deserves a warning message and/or some mention in the documentation.
Note that if f() is declared protected (or public) in both classes,
inheritance works as expected; if the two f()s are declared with
differing protection, an error message results, which is somewhat ironic
considering the above-described silent failure mode.
Reproduce code:
---
class d {
function __construct() {
$this->f();
}
private function f() {
echo "d->f()\n";
}
}
class e extends d {
private function f() {
echo "e->f()\n";
}
}
$t = new e();
Expected result:
e->f()
(Because $this refers to an instance of e when it is executed.)
Actual result:
--
d->f()
--
Edit this bug report at http://bugs.php.net/?id=41090&edit=1
#41012 [Opn->WFx]: exception handling
ID: 41012
Updated by: [EMAIL PROTECTED]
Reported By: perching_eagle at yahoo dot com
-Status: Open
+Status: Wont fix
Bug Type: *Compile Issues
-Operating System: windows xp
+Operating System: *
-PHP Version: 5.2.1
+PHP Version: *
New Comment:
Even though exceptions might be normalities in java and other languages
they keep having anexceptional role in PHP and stay theway they are. In
fact PHP is not a pure OO based language and needs to be able to deal
with its core errors in a non object oriented way. Further more PHP is
not perectly designed for applications have long run times but for web
share nothing web applications where the runtime depends on the time a
script needs to finish a request. For that reason a core error simply
needs to be logged rather than having a control mechanism that
reinitializes whatever should be running.
Previous Comments:
[2007-04-10 02:46:01] perching_eagle at yahoo dot com
correction=
for the first line of the python code in the post before this one.
# add qoutes to the parameter in the function 'input()'
num=input("enter a number, do not enter zero:")
the c programming language and other procedural languages can catch
errors just like object oriented laguages that use exceptions, if the
"try" keyword cannot force the compiler to overlook errors, then you
have to use an "if" statement, just like in "c" and actually write more
code. but if the "try" can suppress errors, you don't have to include
"if" statements and the "throw" keyword, you just write "catch"
statements that can catch each exception and error at runtime, and then
you can continue you code without stopping it or allow the program to
stop after sending a customized message on your site, rather than have
your site or program crash. you just explicitly throw an exception that
closes the program, after sending a customized message for fatal errors
simple.
**
to [EMAIL PROTECTED], a zero division error is an exception, it is not a
fatal error, fatal errors require that you reset the program.they are
errors that should not be caught such as linkage errors and thread death
errors and some machine errors. the program should be allowed to end
gracefully but could still catch them if you wish.
[2007-04-10 02:19:36] perching_eagle at yahoo dot com
well the logic behind exceptions is to help you handle ALL types of
errors and i will show you a similar example in python.
python code:
num=input('enter a number, do not enter zero:)
try:
print 34/int(num)
except ZeroDivisionError:
print "error,you entered zero"
(if you enter 2) output: 17
(if you enter 0) output: error, you entered zero
#java does exactly the same thing.
simple code, i didn't have to explicitly throw any exception (using the
throw keyword) or include an "if" statement. this obeys the rule of keep
things simple, and the "try" keyword actually does something, as opposed
to being a mere decoration as it is now in PHP.
[2007-04-08 15:11:42] [EMAIL PROTECTED]
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
Fatal errors are not exceptions and therefor try {} does nothing to
catch them.
[2007-04-06 21:00:29] perching_eagle at yahoo dot com
//this error is illegal
however zend engine will flag the error in the second try block
(an abnormal behavior) instead of ignoring it.
note: when flagging other posters comments as bogus, give logical
reasons for doing so.
[2007-04-06 20:27:20] perching_eagle at yahoo dot com
why is not a bug?
this is an abnormal behavior, that restricts how you use the exception
class. if the "try block" can't force an erroreneous code to compile,
why do you have the "try" keyword anyway? the "throw" keyword could be
used outside a "try block" and also in a "catch block" or anywhere else
in the program. in a nutshell, the "try" keyword has no function at all
in php, if it does, what is it?
the documentation at php.net does not explain the function of the "try"
keyword in php.
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/41012
--
Edit this bug report at http://bugs.php.net/?id=41012&edit=1
#40442 [Asn->Csd]: [PATCH] ArrayObject::offsetExists broke in 5.2.1, works in 5.2.0
ID: 40442
Updated by: [EMAIL PROTECTED]
Reported By: olivier at elma dot fr
-Status: Assigned
+Status: Closed
Bug Type: SPL related
Operating System: *
PHP Version: 5.2.1
Assigned To: helly
New Comment:
This bug has been fixed in CVS.
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.
thanks forthe patch
Previous Comments:
[2007-04-02 12:08:42] olivier at elma dot fr
AFAIK it does not change anything...
[2007-03-28 20:16:16] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2007-03-28 08:48:42] [EMAIL PROTECTED]
Marcus. any news?
[2007-02-27 10:10:41] olivier at elma dot fr
Just to add the "quick and dirty" patch I use to correct the issue:
--- php-5.2.1/ext/spl/was.spl_array.c 2007-02-09 12:10:18.0
+0100
+++ new.php-5.2.1/ext/spl/spl_array.c 2007-02-09 12:06:33.0
+0100
@@ -525,7 +525,7 @@
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "z",
&index) == FAILURE) {
return;
}
- RETURN_BOOL(spl_array_has_dimension_ex(0, getThis(), index, 1
TSRMLS_CC));
+ RETURN_BOOL(spl_array_has_dimension_ex(0, getThis(), index, 0
TSRMLS_CC));
} /* }}} */
/* {{{ proto mixed ArrayObject::offsetGet(mixed $index)
[2007-02-12 09:10:23] olivier at elma dot fr
Description:
With 5.2.0 ArrayObject::offsetExists will return "true" if the
offsetExists whether its value is empty or not.
This feature is not working anymore with 5.2.1 as it checks for the
emptyness of the value too.
Reproduce code:
---
offsetSet('property', 0);
if (!$a->offsetExists('property')) {
echo "does not exist\n";
} else {
echo "ok\n";
}
?>
Expected result:
ok
Actual result:
--
does not exist
--
Edit this bug report at http://bugs.php.net/?id=40442&edit=1
#40442 [Asn->Fbk]: The patch I use to correct the issue
ID: 40442
Updated by: [EMAIL PROTECTED]
Reported By: olivier at elma dot fr
-Status: Assigned
+Status: Feedback
Bug Type: SPL related
-Operating System: Debian Unstable (not relevant)
+Operating System: *
PHP Version: 5.2.1
Assigned To: helly
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
Previous Comments:
[2007-03-28 08:48:42] [EMAIL PROTECTED]
Marcus. any news?
[2007-02-27 10:10:41] olivier at elma dot fr
Just to add the "quick and dirty" patch I use to correct the issue:
--- php-5.2.1/ext/spl/was.spl_array.c 2007-02-09 12:10:18.0
+0100
+++ new.php-5.2.1/ext/spl/spl_array.c 2007-02-09 12:06:33.0
+0100
@@ -525,7 +525,7 @@
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "z",
&index) == FAILURE) {
return;
}
- RETURN_BOOL(spl_array_has_dimension_ex(0, getThis(), index, 1
TSRMLS_CC));
+ RETURN_BOOL(spl_array_has_dimension_ex(0, getThis(), index, 0
TSRMLS_CC));
} /* }}} */
/* {{{ proto mixed ArrayObject::offsetGet(mixed $index)
[2007-02-12 09:10:23] olivier at elma dot fr
Description:
With 5.2.0 ArrayObject::offsetExists will return "true" if the
offsetExists whether its value is empty or not.
This feature is not working anymore with 5.2.1 as it checks for the
emptyness of the value too.
Reproduce code:
---
offsetSet('property', 0);
if (!$a->offsetExists('property')) {
echo "does not exist\n";
} else {
echo "ok\n";
}
?>
Expected result:
ok
Actual result:
--
does not exist
--
Edit this bug report at http://bugs.php.net/?id=40442&edit=1
#40872 [Asn->Csd]: inconsistency in offsetSet, offsetExists treatment of string enclosed integers
ID: 40872
Updated by: [EMAIL PROTECTED]
Reported By: piter75 at gmail dot com
-Status: Assigned
+Status: Closed
Bug Type: SPL related
-Operating System: Ubuntu Feisty, Windows XP
+Operating System: *
PHP Version: 5.2.1
Assigned To: helly
New Comment:
This bug has been fixed in CVS.
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:
[2007-03-20 20:00:11] piter75 at gmail dot com
Description:
ArrayIterator's methods offsetSet and offsetGet treat the string
enclosed integers ('1', '2', ) as integers, but offsetExists treats
them as strings and returns false even if the value exists at the
specified offset.
Reproduce code:
---
id = $id;
}
}
class ProjectsList extends ArrayIterator {
public function add(Project $item) {
$this->offsetSet($item->id, $item);
}
}
$projects = new ProjectsList();
$projects->add(new Project('1'));
$projects->add(new Project(2));
var_dump($projects->offsetExists(1));
var_dump($projects->offsetExists('2'));
?>
Expected result:
boolean true
boolean true
Actual result:
--
boolean true
boolean false
--
Edit this bug report at http://bugs.php.net/?id=40872&edit=1
#40733 [Asn->Fbk]: Undefined symbol: spl_ce_RuntimeException
ID: 40733 Updated by: [EMAIL PROTECTED] Reported By: alan dot mcfarlane at gmail dot com -Status: Assigned +Status: Feedback Bug Type: MySQLi related -Operating System: FreeBSD 6.0 +Operating System: * PHP Version: 5.2.1 Assigned To: helly New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Previous Comments: [2007-03-20 11:43:38] darren dot pilgrim at gmail dot com There appears to be some sensitivity to the order of modules in extensions.ini. If extensions.ini is sorted, spl.so comes after mysqli.so and the error occurs. If spl.so is moved to preceed mysqli.so, the error does not occur. [2007-03-06 12:41:03] [EMAIL PROTECTED] Marcus, optional extension dependency is missing. Though I honestly do not understand why on earth MySQLi uses SPL exception class. IMO this is counter-intuitive and makes users to guess what is the parent class of mysqli exception - whether it's Exception or RuntimeException? [2007-03-06 07:40:16] alan dot mcfarlane at gmail dot com Configure: -- './configure' '--enable-versioning' '--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php' '--disable-a ll' '--enable-libxml' '--with-libxml-dir=/usr/local' '--enable-reflection' '--program-prefix=' '--enable-fastcgi' '--with-apxs2=/usr/local/sbin/apxs' '--with-regex=php' '--with-zend-vm=CALL' '--prefix=/usr/local' Both PHP and all the extensions were built using the standard FreeBSD ports structure. Note the problem does NOT manifest itself on any of my 64-bit boxes. [2007-03-05 21:23:46] [EMAIL PROTECTED] We need your configure line and whether you compile the extension shared or not. [2007-03-05 21:23:03] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. 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/40733 -- Edit this bug report at http://bugs.php.net/?id=40733&edit=1
#40837 [Opn->Bgs]: static and non-static functions can't have the same name
ID: 40837
Updated by: [EMAIL PROTECTED]
Reported By: nick dot telford at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: Irrelevant
PHP Version: 5.2.1
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
.
Previous Comments:
[2007-03-16 16:44:17] nick dot telford at gmail dot com
Description:
When declaring two functions in a class (methods) non-static and static
functions may not use the same names.
While I understand this, this is essentially wrong since static methods
and non-static methods are entirely different.
This also leads me on to another bug/feature suggestion I'm about to
file about not being able to overload static attributes with
__set/__get.
Reproduce code:
---
class Example {
public static function test() {}
public function test() {}
}
$example = new Example();
$example->test();
Example::test();
Expected result:
No errors, all methods called correctly.
Actual result:
--
PHP errors with: Fatal error: Cannot redeclare Example::test()
--
Edit this bug report at http://bugs.php.net/?id=40837&edit=1
#40826 [Opn->Bgs]: I cant able to assign alias name to my directory
ID: 40826 Updated by: [EMAIL PROTECTED] Reported By: ashokmca dot g at gmail dot com -Status: Open +Status: Bogus Bug Type: Apache related Operating System: windows xp PHP Version: 5.2.1 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Contact Microsoft support - have luck. Previous Comments: [2007-03-15 18:43:38] ashokmca dot g at gmail dot com Description: My folder f:/work/learning/ i need to used this way http://localhost/first/ i want to assign first as to f:/work/learning/ please assist me need help urgent -- Edit this bug report at http://bugs.php.net/?id=40826&edit=1
#40014 [Opn->Csd]: "try, catch" -- Let's Empower It, Please!!!
ID: 40014
Updated by: [EMAIL PROTECTED]
Reported By: marcus3v at hotmail dot com
-Status: Open
+Status: Closed
Bug Type:Feature/Change Request
PHP Version: 6CVS-2007-01-03 (CVS)
New Comment:
First my answer was a canned reply with an additional explanation.
Second E_ERRORS will never be handable in user mode. No matter what or
how happens. So the only thing that can be done is changing particular
E_ERRORs into E_RECOVERABLE_ERRORs. But only if we can make the engine
stay in a recoverable state after the error in question.
Third my answer still holds. Simply provide an error handler that
converts the errors to exceptions and be done.
Previous Comments:
[2007-03-15 02:32:57] [EMAIL PROTECTED]
Actually, since this is not an E_RECOVERABLE_ERROR, but instead an
E_ERROR, the error handler approach won't work
method();
} catch (Exception $e) {
echo 'caught';
}
?>
results in a fatal error.
I'm NOT saying making that an E_RECOVERABLE is the right approach,
as it leaves the engine in an unstable state, just that an error
handler is impossible for this particular issue. Probably "Won't
fix" is more appropriate than "Bogus"
[2007-03-15 00:24:54] marcus3v at hotmail dot com
Hey, dear [EMAIL PROTECTED],
Does you can read?!... I have posted under "Feature/Change Request"
category, not "Bug"!!!... It appears that you, not me, should read
things more carefully!!!...
[2007-03-13 22:28:36] [EMAIL PROTECTED]
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
Just register an error handler that throws an exception.
[2007-03-09 22:37:57] bronner dot mike at gmail dot com
Same here, have been getting that behavior as well. Keeping fatal
errors from users would be nice. It would also let us exit gracefully,
and not leave the users hanging.
[2007-01-03 20:44:54] marcus3v at hotmail dot com
Description:
Hey, men!
What about to enhance the "try, catch" Statement so that the code
inside "try" would transparently cause a Fatal Error that, then, is
handled through the "catch" Blocks -- just as occurs in JavaScript?!
Reproduce code:
---
try {
/*@@*/ echo("[global] -- causing a Fatal Error...");
$nonObjVar->method(); //## "nonObjVar" isn't defined
}
catch(Exception $error) {
/*@@*/ echo("[global] -- some handling being executed...");
//## some handling...
}
/*@@*/ echo("[global] -- [end]");
Expected result:
The output would be the following:
# [global] -- causing a Fatal Error...
# [global] -- some handling being executed...
# [global] -- [end]
Actual result:
--
Obviously, the output with the current implementation is the
following:
# [global] -- causing a Fatal Error...
# ( PHP Notice ) undefined Variable: nonObjVar
# ( PHP Fatal Error ) call to member a Funcion ( "method()" ) on a
non-Object
--
Edit this bug report at http://bugs.php.net/?id=40014&edit=1
#40014 [Opn->Bgs]: "try, catch" -- Let's Empower It, Please!!!
ID: 40014
Updated by: [EMAIL PROTECTED]
Reported By: marcus3v at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type:Feature/Change Request
PHP Version: 6CVS-2007-01-03 (CVS)
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
Just register an error handler that throws an exception.
Previous Comments:
[2007-03-09 22:37:57] bronner dot mike at gmail dot com
Same here, have been getting that behavior as well. Keeping fatal
errors from users would be nice. It would also let us exit gracefully,
and not leave the users hanging.
[2007-01-03 20:44:54] marcus3v at hotmail dot com
Description:
Hey, men!
What about to enhance the "try, catch" Statement so that the code
inside "try" would transparently cause a Fatal Error that, then, is
handled through the "catch" Blocks -- just as occurs in JavaScript?!
Reproduce code:
---
try {
/*@@*/ echo("[global] -- causing a Fatal Error...");
$nonObjVar->method(); //## "nonObjVar" isn't defined
}
catch(Exception $error) {
/*@@*/ echo("[global] -- some handling being executed...");
//## some handling...
}
/*@@*/ echo("[global] -- [end]");
Expected result:
The output would be the following:
# [global] -- causing a Fatal Error...
# [global] -- some handling being executed...
# [global] -- [end]
Actual result:
--
Obviously, the output with the current implementation is the
following:
# [global] -- causing a Fatal Error...
# ( PHP Notice ) undefined Variable: nonObjVar
# ( PHP Fatal Error ) call to member a Funcion ( "method()" ) on a
non-Object
--
Edit this bug report at http://bugs.php.net/?id=40014&edit=1
#40733 [Fbk]: Undefined symbol: spl_ce_RuntimeException
ID: 40733 Updated by: [EMAIL PROTECTED] Reported By: alan dot mcfarlane at gmail dot com Status: Feedback Bug Type: MySQLi related Operating System: FreeBSD 6.0 PHP Version: 5.2.1 -Assigned To: +Assigned To: helly New Comment: We need your configure line and whether you compile the extension shared or not. Previous Comments: [2007-03-05 21:23:03] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2007-03-05 20:01:47] [EMAIL PROTECTED] Please report this to the PHP ports maintainers. Not a PHP problem => bogus [2007-03-05 19:51:50] alan dot mcfarlane at gmail dot com Description: There appears to be a problem with one of the extensions - possibly un undefined symbol: The following extensions are active (in order): session mysqli zip pdf json hash gmp filter fileinfo curl posix sockets openssl ldap simplexml bz2 snmp gettext iconv dom tokenizer xmlreader readline imap xml exif mhash mcrypt mysql mbstring xmlwriter zlib pcre spl sqlite ctype ftp gd xsl Reproduce code: --- echo phpversion(); Expected result: 5.2.1 Actual result: -- PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20060613/mysqli.so' - /usr/local/lib/php/20060613/mysqli.so: Undefined symbol "spl_ce_RuntimeException" in Unknown on line 0 5.2.1 -- Edit this bug report at http://bugs.php.net/?id=40733&edit=1
#40733 [Bgs->Fbk]: Undefined symbol: spl_ce_RuntimeException
ID: 40733 Updated by: [EMAIL PROTECTED] Reported By: alan dot mcfarlane at gmail dot com -Status: Bogus +Status: Feedback Bug Type: MySQLi related Operating System: FreeBSD 6.0 PHP Version: 5.2.1 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2007-03-05 20:01:47] [EMAIL PROTECTED] Please report this to the PHP ports maintainers. Not a PHP problem => bogus [2007-03-05 19:51:50] alan dot mcfarlane at gmail dot com Description: There appears to be a problem with one of the extensions - possibly un undefined symbol: The following extensions are active (in order): session mysqli zip pdf json hash gmp filter fileinfo curl posix sockets openssl ldap simplexml bz2 snmp gettext iconv dom tokenizer xmlreader readline imap xml exif mhash mcrypt mysql mbstring xmlwriter zlib pcre spl sqlite ctype ftp gd xsl Reproduce code: --- echo phpversion(); Expected result: 5.2.1 Actual result: -- PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20060613/mysqli.so' - /usr/local/lib/php/20060613/mysqli.so: Undefined symbol "spl_ce_RuntimeException" in Unknown on line 0 5.2.1 -- Edit this bug report at http://bugs.php.net/?id=40733&edit=1
#40711 [Asn->Bgs]: RecursiveIteratorIterator unable to successfully clean up after itself
ID: 40711 Updated by: [EMAIL PROTECTED] Reported By: hannes dot magnusson at gmail dot com -Status: Assigned +Status: Bogus Bug Type: Reproducible crash -Operating System: FreeBSD +Operating System: * -PHP Version: 5CVS-2007-03-03 (CVS) +PHP Version: * Assigned To: helly 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 First thanks for filing this because I found an error in the class layout. RecursiveFilterIterator::accept must be abstract. And instead you want to use ParentIterator (PI). Another issue is actually in your code. RecursiveIteratorIterator (RII) does not return parents until you specify so by changing its mode (for instance RII::SELF_FIRST). The next issue in the code is that PI::getChildren returns a RecursiveIterator (RI) since it calls RDI::geChildren. This is then passed to PI::__construct becuase it needs to keep the structure. Now in you rcode RFI::__construct you create another RDI. That is the ctor receives a PI that contains an RDI instance and creates a new RDI from it. While doing so the inner RDI is being rewound to its first element which is ".". Now as far as I can tell there will be a recursion somehow with this approach. For me it actually aborts with an exception message like, too many open files. Given the fact that we don't fix recursions I'd say this is expected behavior. If you feel different reopen this report. The correct code to get the directories is below: funcs->dtor(sub_iter TSRMLS_CC); [New LWP 100098] (gdb) bt #0 0x081d6e23 in spl_RecursiveIteratorIterator_free_storage (_object=0x850464c, tsrm_ls=0x84e82b0) at /usr/src/php/5.2/ext/spl/spl_iterators.c:719 #1 0x0836d384 in zend_objects_store_free_object_storage (objects=0x84f2618, tsrm_ls=0x84e82b0) at /usr/src/php/5.2/Zend/zend_objects_API.c:89 #2 0x0833d2db in shutdown_executor (tsrm_ls=0x84e82b0) at /usr/src/php/5.2/Zend/zend_execute_API.c:299 #3 0x0834c77e in zend_deactivate (tsrm_ls=0x84e82b0) at /usr/src/php/5.2/Zend/zend.c:860 #4 0x082f5354 in php_request_shutdown (dummy=0x0) at /usr/src/php/5.2/main/main.c:1311 #5 0x083bd0d8 in main (argc=2, argv=0xbfbfe960) at /usr/src/php/5.2/sapi/cli/php_cli.c:1294 -- Edit this bug report at http://bugs.php.net/?id=40711&edit=1
#40707 [Opn]: checking for db4 major version... Header contains different version
ID: 40707 Updated by: [EMAIL PROTECTED] Reported By: BLentz at channing-bete dot com Status: Open Bug Type: Compile Failure Operating System: Multiple Linux PHP Version: 5.2.1 New Comment: The message 'checking for db4 major version... configure: error: Header contains different version' sounds as if you have different mahor versions of db on your system. Try "rpm -qa|grep 'db[1-4]'" to check whether you have the correct devel packages for the db version you want to use. Also check whether you are using the correct include paths. Previous Comments: [2007-03-03 15:49:35] BLentz at channing-bete dot com Description: Operating systems: Fedora Core 5 and Aurora Linux 2.0 (Fedora Core for SPARC) Berkeley DB versions: 4.3.29 and 4.2.52 (respectively) Header locations: /usr/include/db.h -> /usr/include/db4/db.h Library locations: /usr/lib/libdb.so -> /lib/libdb-4.[3|2].so Berkeley DB installation: via RPM, including -devel packages. No other versions are installed (either via RPM or via source). PHP_LIBDIR is being incorrectly set by the configure script as "lib64" seems like a bad default in the absence of a user-configured value. config.nice contains both: '--libdir=/usr/lib64' \ and '--with-libdir=lib64' \ even though they were not set in the ./configure line (below). The line 27480 test can be compiled by hand using $THIS_INCLUDE=/usr/include/db.h. However, it segfaults on both systems when executed. The line 27495 test can be run through cpp and does successfully return "yes" (DB_VERSION_MAJOR == 4). I was ready to blame my operating system installs until I saw this on two machines/architectures... I don't know where the lib64 is coming from as it does not appear in the output of libtool --config | grep lib64, and this system is running in i386 mode, as reported by uname -a. Reproduce code: --- ./configure --host=sparc-unknown-linux-gnu --build=sparc-unknown-linux-gnu --target=sparc64-redhat-linux --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --cache-file=../config.cache --with-libdir=lib64 --with-config-file-path=/etc --with-config-file-scan-dir=/etc/php.d --disable-debug --with-pic --disable-rpath --without-pear --with-bz2 --with-exec-dir=/usr/bin --with-freetype-dir=/usr --with-png-dir=/usr --enable-gd-native-ttf --without-gdbm --with-gettext --with-gmp --with-iconv --with-jpeg-dir=/usr --with-openssl --with-png --with-pspell --with-expat-dir=/usr --with-pcre-regex --with-zlib --with-layout=GNU --enable-exif --enable-ftp --enable-magic-quotes --enable-sockets --enable-sysvsem --enable-sysvshm --enable-sysvmsg --enable-track-vars --enable-trans-sid --enable-yp --enable-wddx --with-kerberos --enable-ucd-snmp-hack --with-unixODBC=shared,/usr --enable-memory-limit --enable-shmop --enable-calendar --enable-dbx --enable-dio --with-mime-magic=/etc/httpd/conf/magic --without-sqlite --with-libxml-dir=/usr --with-xml --enable-force-cgi-redirect --enable-pcntl --with-imap=shared --with-imap-ssl --enable-mbstring=shared --enable-mbstr-enc-trans --enable-mbregex --with-ncurses=shared --with-gd=shared --enable-bcmath=shared --enable-dba=shared --with-db4 --with-xmlrpc=shared --with-ldap=shared --with-mysql=shared,/usr --with-mysqli=shared,/usr/bin/mysql_config --enable-dom=shared --with-dom-xslt=/usr --with-dom-exslt=/usr --with-pgsql=shared --with-snmp=shared,/usr --enable-soap=shared --with-xsl=shared,/usr --enable-xmlreader=shared --enable-xmlwriter=shared --enable-fastcgi --enable-pdo=shared --with-pdo-odbc=shared,unixODBC,/usr --with-pdo-mysql=shared,/usr --with-pdo-pgsql=shared,/usr --with-pdo-sqlite=shared,/usr --with-apxs2=/usr/sbin/apxs Expected result: A usable build of PHP. If I add --libdir=/usr/lib --with-libdir=lib to the configure line, I can get one step closer to getting PHP to compile (now I'm getting "utf8_mime2text() has new signature, but U8T_CANONICAL is missing."; separate issue, I guess) Actual result: -- STDOUT: checking for QDBM support... no checking for GDBM support... no checking for NDBM support... no checking for db4 major version... configure: error: Header contains different version config.log: configure:26767: checking for QDBM support configure:27102: checking for GDBM support configure:27423: checking for NDBM support configure:27528: checking for db4 major version -- Edit this bug report at http://bugs.php.net/?id=40707&edit=1
#40679 [Opn->Bgs]: problems with $class_name in __autoload
ID: 40679
Updated by: [EMAIL PROTECTED]
Reported By: habeck at gmx dot de
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: *
PHP Version: 5.2.1
Assigned To: helly
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
Ok read this again. It is all perfectly fine and there is no crash.
There is only an E_ERROR. That is because you explicitly set class name
to '' - RTFM.
Previous Comments:
[2007-03-03 11:21:24] [EMAIL PROTECTED]
The crash is not good but you should really read the documentation.
I'll fix the crash. Not your problem though.
[2007-03-03 05:08:36] habeck at gmx dot de
There are three files:
autoload-file (test.php):
sayHallo();
?>
class-file (blah.php):
var = simplexml_load_file($var, '',
LIBXML_NOCDATA+LIBXML_COMPACT);
}
function sayHallo()
{
print('hallo world!');
}
}
?>
xml-file (config.xml):
error comment:
I have tried to find out where the error occurs and it seems that the
empty second parameter in the function call "simplexml_load_file"
overrides the variable value of $class_name.
[2007-03-01 11:08:45] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2007-03-01 10:56:35] habeck at gmx dot de
same error on windows 2003 with apache 2.0.59
[2007-03-01 10:03:41] habeck at gmx dot de
Description:
I have also problems with __autoload on windows 2003 apache 2.2.4/php
5.2.1. The following function does not what it did in apache 2.0.x and
earlier versions of php:
function __autoload($class_name) {
require_once(KH_APP_LIBPATH.$class_name.'.php');
}
The errormessage:
PHP Fatal error: require_once(): Failed opening required
'D:/xxx/xxx/.php' (include_path='./;D:/xxx/xxx/') in
D:\xxx\xxx\index.php on line 6
So there seems to be no value for $classname.
Reproduce code:
---
function __autoload($class_name) {
require_once(KH_APP_LIBPATH.$class_name.'.php');
}
Expected result:
Opening the classfile: D:/xxx/xxx/blah.php
Actual result:
--
PHP Fatal error: require_once(): Failed opening required
'D:/xxx/xxx/.php' (include_path='./;D:/xxx/xxx/') in
D:\xxx\xxx\index.php on line 6
--
Edit this bug report at http://bugs.php.net/?id=40679&edit=1
#40679 [Opn]: problems with $class_name in __autoload
ID: 40679
Updated by: [EMAIL PROTECTED]
Reported By: habeck at gmx dot de
Status: Open
Bug Type: Unknown/Other Function
-Operating System: windows 2003 / apache 2.2.4
+Operating System: *
PHP Version: 5.2.1
-Assigned To:
+Assigned To: helly
New Comment:
The crash is not good but you should really read the documentation.
I'll fix the crash. Not your problem though.
Previous Comments:
[2007-03-03 05:08:36] habeck at gmx dot de
There are three files:
autoload-file (test.php):
sayHallo();
?>
class-file (blah.php):
var = simplexml_load_file($var, '',
LIBXML_NOCDATA+LIBXML_COMPACT);
}
function sayHallo()
{
print('hallo world!');
}
}
?>
xml-file (config.xml):
error comment:
I have tried to find out where the error occurs and it seems that the
empty second parameter in the function call "simplexml_load_file"
overrides the variable value of $class_name.
[2007-03-01 11:08:45] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2007-03-01 10:56:35] habeck at gmx dot de
same error on windows 2003 with apache 2.0.59
[2007-03-01 10:03:41] habeck at gmx dot de
Description:
I have also problems with __autoload on windows 2003 apache 2.2.4/php
5.2.1. The following function does not what it did in apache 2.0.x and
earlier versions of php:
function __autoload($class_name) {
require_once(KH_APP_LIBPATH.$class_name.'.php');
}
The errormessage:
PHP Fatal error: require_once(): Failed opening required
'D:/xxx/xxx/.php' (include_path='./;D:/xxx/xxx/') in
D:\xxx\xxx\index.php on line 6
So there seems to be no value for $classname.
Reproduce code:
---
function __autoload($class_name) {
require_once(KH_APP_LIBPATH.$class_name.'.php');
}
Expected result:
Opening the classfile: D:/xxx/xxx/blah.php
Actual result:
--
PHP Fatal error: require_once(): Failed opening required
'D:/xxx/xxx/.php' (include_path='./;D:/xxx/xxx/') in
D:\xxx\xxx\index.php on line 6
--
Edit this bug report at http://bugs.php.net/?id=40679&edit=1
#40693 [Opn->WFx]: reimplementation of strtok_r in TSRM/tsrm_strtok_r.c
ID: 40693
Updated by: [EMAIL PROTECTED]
Reported By: stefan dot teleman at gmail dot com
-Status: Open
+Status: Wont fix
Bug Type: Strings related
-Operating System: Solaris 10
+Operating System: *
PHP Version: 5.2.1
New Comment:
Usually reimplementation of a c library function means that we rely on
very specific functionality. Otfen in this cases many implementations
are simply plain wrong. This is true for a bunch of stuff where
werequire the C99 compliant implementation.
Previous Comments:
[2007-03-02 17:22:40] stefan dot teleman at gmail dot com
Description:
TSRM/tsrm_strtok_r.c reimplements strtok_r(3C) (php-5.2.0 and
php-5.2.1).
Please don't do this on Solaris. There is no reason to reimplement a
Standard C Library function.
diff -wu output included below.
Reproduce code:
---
--- tsrm_strtok_r.c.orig2000-09-11 11:15:29.0 -0400
+++ tsrm_strtok_r.c 2007-03-02 03:25:44.953128000 -0500
@@ -16,6 +16,9 @@
char *tsrm_strtok_r(char *s, const char *delim, char **last)
{
+#if defined(SOLARIS)
+return strtok_r(s, delim, last);
+#else
char *token;
if (s == NULL) {
@@ -41,6 +44,7 @@
*last = s + 1;
}
return token;
+#endif
}
#if 0
--
Edit this bug report at http://bugs.php.net/?id=40693&edit=1
#40604 [Opn->Bgs]: Objects disappear from the global scope
ID: 40604 Updated by: [EMAIL PROTECTED] Reported By: dagdamor at simps dot ru -Status: Open +Status: Bogus Bug Type: Class/Object related Operating System: Windows PHP Version: 5.2.1 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php the object gets destroyed before you get output - well actually you don't produce output Previous Comments: [2007-02-23 08:49:07] dagdamor at simps dot ru Description: Objects seem to disappear from the global scope when you try to access them from the output buffer callback function. Regular variables (i.e. not objects) don't disappear and work alright. After some additional research I've noticed that if your PHP program has many objects in the global scope, some of them don't disappear, while others do. Looks very strange... I hope this is not documentation misinterpretation, because I used global variables, objects including in OB callbacks in PHP4, and it worked fine. In other words, I hope this is not "You can't use global variables there" case. Reproduce code: --- Expected result: OK Actual result: -- Error -- Edit this bug report at http://bugs.php.net/?id=40604&edit=1
#40568 [Opn]: filemtime shifted by one hour on win32
ID: 40568 Updated by: [EMAIL PROTECTED] Reported By: JPlissonneauDuquene at bellhelicopter dot textr Status: Open Bug Type: Filesystem function related Operating System: Windows XP PHP Version: 5.2.1 New Comment: They should fix the design then. And not wrongly implement stuff and make everybody follow their errors. Previous Comments: [2007-02-20 22:28:59] JPlissonneauDuquene at bellhelicopter dot textr Description: Hi, PHP filemtime/fileatime/filectime (and maybe stat itself) functions should use GetFileTime() Win32API (or GetFileAttributesEx()), not stat() to retrieve the actual times from files. Otherwise the returned time is shifted by one hour in some conditions. This (mis)behaviour is actually DOCUMENTED by Microsoft, so it does not qualify for "bogus - fix microsoft libraries" bug rejection -- Microsoft already fixed their documentation and even indicated that "This behavior is by design." References: http://support.microsoft.com/kb/158588 http://support.microsoft.com/kb/190315 http://msdn2.microsoft.com/en-gb/library/ms724290.aspx http://us3.php.net/manual/en/function.stat.php#58404 http://www.codeproject.com/datetime/dstbugs.asp Thanks! Reproduce code: --- Expected result: D:\test>php test.php 2007-02-20T15:14:45-0500 1172002485 summer_file 1150893296 1150893296 winter_file 1166704496 1166704496 D:\test>dir 06/21/2006 08:34 AM 0 summer_file 12/21/2006 07:34 AM 0 winter_file Actual result: -- # NOTE - run tests in order. Test 1 will create the files. # Do NOT remove the files before tests 2-4. # test 1. Winter time, DST adj. checked D:\test>php test.php 2007-02-20T17:07:47-0500 1172009267 summer_file 1150893296 1150893296 winter_file 1166704496 1166704496 # test 2. Winter time, DST adj. unchecked D:\test>php test.php 2007-02-20T17:08:05-0500 1172009285 summer_file 1150893296 1150896896 winter_file 1166704496 1166704496 # note summer_file timestamp is now 1 hour later # test 3. Summer time, DST adj. unchecked D:\test>php test.php 2007-08-20T18:08:34-0400 1187647714 summer_file 1150893296 1150896896 winter_file 1166704496 1166704496 # same as test 2. # note that time /t or GUI clock will show 17:08, while # PHP time reports 18:08, but this is another bug. # test 4. Summer time, DST adj. now checked D:\test>php test.php 2007-08-20T18:11:04-0400 1187647864 summer_file 1150893296 1150896896 winter_file 1166704496 1166708096 # note that winter_file timestamp is now 1 hour later # time /t and GUI clock jumped 1 hour later (18:11) when # checking automatic DST adj. D:\test>dir *_file # after test1 06/21/2006 08:34 AM 0 summer_file 12/21/2006 07:34 AM 0 winter_file # after test2 06/21/2006 08:34 AM 0 summer_file 12/21/2006 07:34 AM 0 winter_file # after test3 06/21/2006 08:34 AM 0 summer_file 12/21/2006 07:34 AM 0 winter_file # after test4 06/21/2006 09:34 AM 0 summer_file 12/21/2006 08:34 AM 0 winter_file -- Edit this bug report at http://bugs.php.net/?id=40568&edit=1
#40548 [Asn->Csd]: SplFileInfo::getOwner/getGroup give a warning on broken symlink
ID: 40548 Updated by: [EMAIL PROTECTED] Reported By: info at adaniels dot nl -Status: Assigned +Status: Closed Bug Type: SPL related Operating System: Linux/Ubuntu PHP Version: 5.2.1 Assigned To: helly New Comment: This bug has been fixed in CVS. 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. Throwsexception now Previous Comments: [2007-02-20 06:27:53] judas dot iscariote at gmail dot com I expect an Exception in that case.. [2007-02-19 20:58:04] info at adaniels dot nl Description: SplFileInfo::getOwner() and SplFileInfo::getGroup() give a warning on broken symlink. This is probably due the fact that the function follows the symlink. Reproduce code: --- system: ln -s nothing /broken getOwner(); echo $fi->getGroup(); ?> Expected result: rootroot Actual result: -- Warning: SplFileInfo::getOwner() [function.SplFileInfo-getOwner]: stat failed for /broken in /home/arnold/projects/jasny/jasny-explorer/webroot/index.php on line 6 Warning: SplFileInfo::getGroup() [function.SplFileInfo-getGroup]: stat failed for /broken in /home/arnold/projects/jasny/jasny-explorer/webroot/index.php on line 7 -- Edit this bug report at http://bugs.php.net/?id=40548&edit=1
#40546 [Asn->Csd]: SplFileInfo::getPathInfo() throws an execption if directory is in root dir.
ID: 40546
Updated by: [EMAIL PROTECTED]
Reported By: info at adaniels dot nl
-Status: Assigned
+Status: Closed
Bug Type: SPL related
Operating System: Linux/Ubuntu
PHP Version: 5.2.1
Assigned To: helly
New Comment:
This bug has been fixed in CVS.
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:
[2007-02-19 19:54:30] info at adaniels dot nl
Description:
SplFileInfo::getPathInfo() throws an execption if directory is in root
dir.
Reproduce code:
---
getPathInfo()->getFilename();
?>
Expected result:
/
Actual result:
--
Fatal error: Uncaught exception 'RuntimeException' with message 'Cannot
create SplFileInfo for empty path' in
/home/arnold/projects/jasny/jasny-explorer/webroot/index.php:6 Stack
trace: #0
/home/arnold/projects/jasny/jasny-explorer/webroot/index.php(6):
SplFileInfo->getPathInfo() #1 {main} thrown in
/home/arnold/projects/jasny/jasny-explorer/webroot/index.php on line 6
--
Edit this bug report at http://bugs.php.net/?id=40546&edit=1
#40477 [Bgs->Csd]: object's read property handler not used in zend_print_zval_r_ex
ID: 40477
Updated by: [EMAIL PROTECTED]
Reported By: piotrek dot pokora at gmail dot com
-Status: Bogus
+Status: Closed
Bug Type: Variables related
Operating System: *
PHP Version: 5.2.*
-Assigned To:
+Assigned To: helly
New Comment:
This bug has been fixed in CVS.
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.
The above closes the bug
Previous Comments:
[2007-02-15 18:44:41] [EMAIL PROTECTED]
PHP 5.3 will and PHP 6 has already a handler to solve the issue. As
long as we are speaking of internal stuff that means the only thing we
have to do is check whether the mentioned helper function uses that new
handler in PHP 6. Care to do so?
[2007-02-15 10:12:21] piotrek dot pokora at gmail dot com
>> Is this a list for reporting ZEND bugs?
>No, this is a list when I'm ready to explain any question regarding
Zend
>Engine sources to a person who haven't ever heard of respect.
Please, forgive me. But don't you think that documentation privided by
ZEND clearly states:
"read_property - returns zval *, containing the value of the
property. Is used when value of the property should be retrieved for
reading."
It doesn't tell about any exceptions.
I will be more than glad to ask you about such exceptions at pecl-dev
list but unfortunatelly I didn't get any confirmation after using ( few
times ) submit form at http://pecl.php.net/support.php#lists.
If I can not subscribe to this list with this form , please subscribe
me using my mail.
I am looking forward for detailed clarification.
[2007-02-15 09:48:33] [EMAIL PROTECTED]
>> [EMAIL PROTECTED]
> Is this a list for reporting ZEND bugs?
No, this is a list when I'm ready to explain any question regarding
Zend Engine sources to a person who haven't ever heard of respect.
[2007-02-15 09:36:25] [EMAIL PROTECTED]
Stop ranting and grasp the facts.
[2007-02-15 09:32:19] piotrek dot pokora at gmail dot com
> [EMAIL PROTECTED]
Is this a list for reporting ZEND bugs?
http://cvs.php.net/viewvc.cgi/ZendEngine2/zend.c?revision=1.393&view=markup
function: static void print_hash(HashTable *ht, int indent, zend_bool
is_object TSRMLS_DC)
printing value:
ZEND_PUTS("] => ");
zend_print_zval_r(*tmp, indent+PRINT_ZVAL_INDENT TSRMLS_CC);
ZEND_PUTS("\n");
`tmp` pointer is not a pointer for a zval returned by ANY
read_property. Neither standard nor user defined one.
If you are going to keep this bug with bogus status, I am going to
submit another one.
Logic and consistency is broken here. And this is absolutely a bug.
Behaviour of this function's part is unchanged since ZEND1 engine.
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/40477
--
Edit this bug report at http://bugs.php.net/?id=40477&edit=1
#40477 [Bgs]: object's read property handler not used in zend_print_zval_r_ex
ID: 40477
Updated by: [EMAIL PROTECTED]
Reported By: piotrek dot pokora at gmail dot com
Status: Bogus
Bug Type: Variables related
-Operating System: debian/linux
+Operating System: *
-PHP Version: 5.2.1
+PHP Version: 5.2.*
New Comment:
PHP 5.3 will and PHP 6 has already a handler to solve the issue. As
long as we are speaking of internal stuff that means the only thing we
have to do is check whether the mentioned helper function uses that new
handler in PHP 6. Care to do so?
Previous Comments:
[2007-02-15 10:12:21] piotrek dot pokora at gmail dot com
>> Is this a list for reporting ZEND bugs?
>No, this is a list when I'm ready to explain any question regarding
Zend
>Engine sources to a person who haven't ever heard of respect.
Please, forgive me. But don't you think that documentation privided by
ZEND clearly states:
"read_property - returns zval *, containing the value of the
property. Is used when value of the property should be retrieved for
reading."
It doesn't tell about any exceptions.
I will be more than glad to ask you about such exceptions at pecl-dev
list but unfortunatelly I didn't get any confirmation after using ( few
times ) submit form at http://pecl.php.net/support.php#lists.
If I can not subscribe to this list with this form , please subscribe
me using my mail.
I am looking forward for detailed clarification.
[2007-02-15 09:48:33] [EMAIL PROTECTED]
>> [EMAIL PROTECTED]
> Is this a list for reporting ZEND bugs?
No, this is a list when I'm ready to explain any question regarding
Zend Engine sources to a person who haven't ever heard of respect.
[2007-02-15 09:36:25] [EMAIL PROTECTED]
Stop ranting and grasp the facts.
[2007-02-15 09:32:19] piotrek dot pokora at gmail dot com
> [EMAIL PROTECTED]
Is this a list for reporting ZEND bugs?
http://cvs.php.net/viewvc.cgi/ZendEngine2/zend.c?revision=1.393&view=markup
function: static void print_hash(HashTable *ht, int indent, zend_bool
is_object TSRMLS_DC)
printing value:
ZEND_PUTS("] => ");
zend_print_zval_r(*tmp, indent+PRINT_ZVAL_INDENT TSRMLS_CC);
ZEND_PUTS("\n");
`tmp` pointer is not a pointer for a zval returned by ANY
read_property. Neither standard nor user defined one.
If you are going to keep this bug with bogus status, I am going to
submit another one.
Logic and consistency is broken here. And this is absolutely a bug.
Behaviour of this function's part is unchanged since ZEND1 engine.
[2007-02-15 09:03:05] [EMAIL PROTECTED]
[EMAIL PROTECTED]
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/40477
--
Edit this bug report at http://bugs.php.net/?id=40477&edit=1
#39836 [Asn->Csd]: SplObjectStorage empty after unserialize
ID: 39836 Updated by: [EMAIL PROTECTED] Reported By: doublecompile at gmail dot com -Status: Assigned +Status: Closed Bug Type: Feature/Change Request Operating System: * -PHP Version: 5.2.0 +PHP Version: 5.2.1 Assigned To: helly New Comment: This bug has been fixed in CVS. 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: [2006-12-16 13:56:05] [EMAIL PROTECTED] Works in HEAD now, except for unicode mode. Support in 5.2 might be added as well. The patch at least works. [2006-12-16 12:31:37] [EMAIL PROTECTED] Actually this is a feature request. Overloaded objects are typically not serializable even though PHP in theory has everything to allow that. [2006-12-14 22:12:46] doublecompile at gmail dot com Description: I serialized a SplObjectStorage instance containing several objects. After unserialization, the SplObjectStorage object contained nothing. It doesn't say in the SPL documentation that SplObjectStorage cannot be serialized. Reproduce code: --- example = 'testing'.$i; $storage->attach( $test ); } echo "Before: ".count($storage).""; $str = serialize($storage); $storage2 = unserialize( $str ); echo "After: ".count($storage2).""; ?> Expected result: Before: 5 After: 5 Actual result: -- Before: 5 After: 0 -- Edit this bug report at http://bugs.php.net/?id=39836&edit=1
#40398 [Opn->Bgs]: parent and self callback functions erroneously called statically
ID: 40398
Updated by: [EMAIL PROTECTED]
Reported By: levi at alliancesoftware dot com dot au
-Status: Open
+Status: Bogus
Bug Type:Scripting Engine problem
PHP Version: 5CVS-2007-02-08 (CVS)
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
Use: call_user_func_array(array($this, 'parent::__construct'), $args);
Previous Comments:
[2007-02-08 05:28:10] levi at alliancesoftware dot com dot au
Description:
parent::func() uses a static function call syntax but is 'special' in
that you are allowed to use it to call nonstatic functions without
generating any warnings.
Callbacks with E_STRICT on don't recognise the 'special' nature of
'parent' and 'self'. (happens with call_user_func(),
call_user_func_array(), array_map() etc)
This means that it is impossible to call a parent method through a
callback without generating a warning.
Therefore, code such as:
public function __construct(/* variable argument list */) {
$args = func_get_args();
call_user_func_array('parent', '__construct), $args);
/* ... extra initialisation here ... */
}
will not work with E_STRICT
Note: Related to #36011, but not quite the same (this one involves
inheritance)
Reproduce code:
---
#!/usr/local/src/php5/php-5.2.CVS-cgi/sapi/cgi/php -q
g(3);
?>
Expected result:
33
Actual result:
--
PHP Strict Standards: Non-static method [...] cannot be called
statically, assuming $this from compatible context Descendent in
/home/levi/public_html/test2.php5 on line [...]
(See code for which lines generate the warning)
--
Edit this bug report at http://bugs.php.net/?id=40398&edit=1
#40348 [Opn->Bgs]: Reading of private/protected properties should be allowed for Reflection API
ID: 40348 Updated by: [EMAIL PROTECTED] Reported By: thc at forestfactory dot de -Status: Open +Status: Bogus Bug Type: Class/Object related -Operating System: any +Operating System: * -PHP Version: 5.2.0 +PHP Version: * 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 Use var_dump Previous Comments: [2007-02-04 06:54:30] thc at forestfactory dot de Description: "Fixing" "bug" #37816 in PHP 5.2.0 made Reflection more or less useless for the one purpose I used it for: reverse-engineering and debugging. While I can understand that there might be a reason for disallowing "setValue" on private/protected properties, why shouldn't I be allowed to read the value of a property? I wrote a nice debugger/reflection class for 5.1.x which stopped working now. And what will I do? I will use print_r() or var_export() and parse the output using regular expressions or something to get the value. So what is the point of this? I still get the value. You just made my code less readable and more performance consuming IMHO this was never a bug! And as #24852 mentions it isn't a bug that print_r() gives access to values of non-public properties Regards Thomas -- Edit this bug report at http://bugs.php.net/?id=40348&edit=1
#40073 [Opn->Csd]: exif_read_data dies on certain images
ID: 40073 Updated by: [EMAIL PROTECTED] Reported By: camka at email dot ee -Status: Open +Status: Closed Bug Type: EXIF related Operating System: * PHP Version: 5.2.1RC2 Assigned To: helly New Comment: This bug has been fixed in CVS. 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: [2007-01-09 17:52:17] [EMAIL PROTECTED] Fixed in head [2007-01-09 17:50:18] [EMAIL PROTECTED] It is broken, still the server should not crash. Fix is coming. [2007-01-09 14:40:23] [EMAIL PROTECTED] According to a few exif tools this image is either invalid or has corrupted exif information. [2007-01-09 11:44:00] [EMAIL PROTECTED] Marcus, I've fixed the segfault, but the result EXIF data is still b0rked, please see if we can do anything about it. [2007-01-09 11:07:03] camka at email dot ee Description: PHP dies on certain files format while reading exif data with exif_read_date because of some maximum directory nesting level reached. The function should return FALSE and let the program flow further. Otherwice misformated image processing may kill script and break the program logic. Even if i suppress warnings with @ sign, i still cannot manage to let the program go further after unsuccessfull reading exif data. broken file: http://www.hot.ee/camka/orig.phpJCN9Ir.jpg Tried with 5.1.6, 5.2.0 and latest snapshot of 5.2.1. P.S. All editors successfully show EXIF data for current file, so maybe it's not misformatted exif data but exif extension cannot process some newer exif formats? Reproduce code: --- x16BF in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal format code 0x0020, suppose BYTE in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal pointer offset(x10F + x10A = x219 > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal format code 0x0014, suppose BYTE in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal pointer offset(x110 + x12A = x23A > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal format code 0x0011, suppose BYTE in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal pointer offset(x112 + x13E = x250 > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0003=UndefinedTa): Illegal pointer offset(x11AFF1A + x1 = x11BFF1A > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0005=UndefinedTa): Illegal pointer offset(x11B + x14F = x26A > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0005=UndefinedTa): Illegal pointer offset(x128 + x157 = x27F > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0003=UndefinedTa): Illegal pointer offset(x131FF97 + x2 = x133FF97 > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal pointer offset(x132 + x57C = x6AE > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal format code 0x0014, suppose BYTE in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal pointer offset(x213 + x168 = x37B > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0003=UndefinedTa): Illegal pointer offset(xA401FF9C + x2 = xA403FF9C > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0005=UndefinedTa): Illegal pointer offset(xA406 + x17C = xA582 > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0003=UndefinedTa): Illegal pointer offset(xA408FF9F + x1 = xA409FF9F > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0007=UndefinedTa): Illegal format code 0x0104, suppose BYTE in exif.php on line 2 PHP Warning: exif_re
#40073 [Opn]: exif_read_data dies on certain images
ID: 40073 Updated by: [EMAIL PROTECTED] Reported By: camka at email dot ee Status: Open Bug Type: EXIF related Operating System: * PHP Version: 5.2.1RC2 Assigned To: helly New Comment: Fixed in head Previous Comments: [2007-01-09 17:50:18] [EMAIL PROTECTED] It is broken, still the server should not crash. Fix is coming. [2007-01-09 14:40:23] [EMAIL PROTECTED] According to a few exif tools this image is either invalid or has corrupted exif information. [2007-01-09 11:44:00] [EMAIL PROTECTED] Marcus, I've fixed the segfault, but the result EXIF data is still b0rked, please see if we can do anything about it. [2007-01-09 11:07:03] camka at email dot ee Description: PHP dies on certain files format while reading exif data with exif_read_date because of some maximum directory nesting level reached. The function should return FALSE and let the program flow further. Otherwice misformated image processing may kill script and break the program logic. Even if i suppress warnings with @ sign, i still cannot manage to let the program go further after unsuccessfull reading exif data. broken file: http://www.hot.ee/camka/orig.phpJCN9Ir.jpg Tried with 5.1.6, 5.2.0 and latest snapshot of 5.2.1. P.S. All editors successfully show EXIF data for current file, so maybe it's not misformatted exif data but exif extension cannot process some newer exif formats? Reproduce code: --- x16BF in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal format code 0x0020, suppose BYTE in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal pointer offset(x10F + x10A = x219 > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal format code 0x0014, suppose BYTE in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal pointer offset(x110 + x12A = x23A > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal format code 0x0011, suppose BYTE in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal pointer offset(x112 + x13E = x250 > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0003=UndefinedTa): Illegal pointer offset(x11AFF1A + x1 = x11BFF1A > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0005=UndefinedTa): Illegal pointer offset(x11B + x14F = x26A > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0005=UndefinedTa): Illegal pointer offset(x128 + x157 = x27F > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0003=UndefinedTa): Illegal pointer offset(x131FF97 + x2 = x133FF97 > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal pointer offset(x132 + x57C = x6AE > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal format code 0x0014, suppose BYTE in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal pointer offset(x213 + x168 = x37B > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0003=UndefinedTa): Illegal pointer offset(xA401FF9C + x2 = xA403FF9C > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0005=UndefinedTa): Illegal pointer offset(xA406 + x17C = xA582 > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0003=UndefinedTa): Illegal pointer offset(xA408FF9F + x1 = xA409FF9F > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0007=UndefinedTa): Illegal format code 0x0104, suppose BYTE in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0007=UndefinedTa): Illegal pointer offset(x8769 + x184 = x88ED > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0004=UndefinedTa): Illegal pointer offset(x7C7 + x288 = xA4F > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x=Undef
#40073 [Csd->Opn]: exif_read_data dies on certain images
ID: 40073 Updated by: [EMAIL PROTECTED] Reported By: camka at email dot ee -Status: Closed +Status: Open Bug Type: EXIF related -Operating System: WinXP, Linux +Operating System: * PHP Version: 5.2.1RC2 Assigned To: helly New Comment: It is broken, still the server should not crash. Fix is coming. Previous Comments: [2007-01-09 14:40:23] [EMAIL PROTECTED] According to a few exif tools this image is either invalid or has corrupted exif information. [2007-01-09 11:44:00] [EMAIL PROTECTED] Marcus, I've fixed the segfault, but the result EXIF data is still b0rked, please see if we can do anything about it. [2007-01-09 11:07:03] camka at email dot ee Description: PHP dies on certain files format while reading exif data with exif_read_date because of some maximum directory nesting level reached. The function should return FALSE and let the program flow further. Otherwice misformated image processing may kill script and break the program logic. Even if i suppress warnings with @ sign, i still cannot manage to let the program go further after unsuccessfull reading exif data. broken file: http://www.hot.ee/camka/orig.phpJCN9Ir.jpg Tried with 5.1.6, 5.2.0 and latest snapshot of 5.2.1. P.S. All editors successfully show EXIF data for current file, so maybe it's not misformatted exif data but exif extension cannot process some newer exif formats? Reproduce code: --- x16BF in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal format code 0x0020, suppose BYTE in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal pointer offset(x10F + x10A = x219 > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal format code 0x0014, suppose BYTE in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal pointer offset(x110 + x12A = x23A > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal format code 0x0011, suppose BYTE in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal pointer offset(x112 + x13E = x250 > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0003=UndefinedTa): Illegal pointer offset(x11AFF1A + x1 = x11BFF1A > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0005=UndefinedTa): Illegal pointer offset(x11B + x14F = x26A > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0005=UndefinedTa): Illegal pointer offset(x128 + x157 = x27F > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0003=UndefinedTa): Illegal pointer offset(x131FF97 + x2 = x133FF97 > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal pointer offset(x132 + x57C = x6AE > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal format code 0x0014, suppose BYTE in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0002=UndefinedTa): Illegal pointer offset(x213 + x168 = x37B > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0003=UndefinedTa): Illegal pointer offset(xA401FF9C + x2 = xA403FF9C > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0005=UndefinedTa): Illegal pointer offset(xA406 + x17C = xA582 > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0003=UndefinedTa): Illegal pointer offset(xA408FF9F + x1 = xA409FF9F > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0007=UndefinedTa): Illegal format code 0x0104, suppose BYTE in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0007=UndefinedTa): Illegal pointer offset(x8769 + x184 = x88ED > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x0004=UndefinedTa): Illegal pointer offset(x7C7 + x288 = xA4F > x16BF) in exif.php on line 2 PHP Warning: exif_read_data(orig.phpJCN9Ir.jpg): Process tag(x=UndefinedTa): Illegal format code 0x4C4F, suppose BYTE in exif.php on li
#39996 [Opn->Csd]: Wrong PHPDoc comment for SplFileInfo::getType()
ID: 39996
Updated by: [EMAIL PROTECTED]
Reported By: mail at bastian-fenske dot de
-Status: Open
+Status: Closed
Bug Type:SPL related
PHP Version: 5.2.0
New Comment:
This bug has been fixed in CVS.
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.
Thanksfor noting this
Previous Comments:
[2006-12-31 16:27:40] mail at bastian-fenske dot de
Description:
Only a little bug in the @return comment in /pecl/spl/spl.php:
/** @return The current entry's size in bytes .
*/
function getType() {/**/}
Basti
--
Edit this bug report at http://bugs.php.net/?id=39996&edit=1
#39836 [Opn]: SplObjectStorage empty after unserialize
ID: 39836 Updated by: [EMAIL PROTECTED] Reported By: doublecompile at gmail dot com Status: Open Bug Type: SPL related Operating System: * PHP Version: 5.2.0 Assigned To: helly New Comment: Works in HEAD now, except for unicode mode. Support in 5.2 might be added as well. The patch at least works. Previous Comments: [2006-12-16 12:31:37] [EMAIL PROTECTED] Actually this is a feature request. Overloaded objects are typically not serializable even though PHP in theory has everything to allow that. [2006-12-14 22:12:46] doublecompile at gmail dot com Description: I serialized a SplObjectStorage instance containing several objects. After unserialization, the SplObjectStorage object contained nothing. It doesn't say in the SPL documentation that SplObjectStorage cannot be serialized. Reproduce code: --- example = 'testing'.$i; $storage->attach( $test ); } echo "Before: ".count($storage).""; $str = serialize($storage); $storage2 = unserialize( $str ); echo "After: ".count($storage2).""; ?> Expected result: Before: 5 After: 5 Actual result: -- Before: 5 After: 0 -- Edit this bug report at http://bugs.php.net/?id=39836&edit=1
