[PHP-DOC] #40223 [Opn]: ReflectionMethod is not an subclass of ReflectionFunction
ID: 40223
Updated by: [EMAIL PROTECTED]
Reported By: baldurien at bbnwn dot eu
Status: Open
Bug Type: Documentation problem
-Operating System: Windows XP SP2
+Operating System: *
-PHP Version: 5.2.0
+PHP Version: *
New Comment:
Method and Functions are in no way derived. Thus the following design
approach was taken:
class ReflectionMethod extends ReflectionFunctionAbstract implements
Reflector
class ReflectionFunction extends ReflectionFunctionAbstract implements
Reflector
Previous Comments:
[2007-01-24 19:47:02] [EMAIL PROTECTED]
The documentation is wrong, both ReflectionMethod & ReflectionFunction
extend abstract class called "ReflectionFunctionAbstract".
[2007-01-24 19:46:19] [EMAIL PROTECTED]
(reclassified as documentation problem)
The docs are wrong (and really outdated).
ReflectionMethod and ReflectionFunction both extend
ReflectionFunctionAbstract.
(see: php --rc ReflectionMethod && php --rc
ReflectionFunction or php --re reflection)
[2007-01-24 19:39:00] baldurien at bbnwn dot eu
Description:
The doc (http://fr.php.net/manual/en/language.oop5.reflection.php)
state that ReflectioMethod be a ReflectionFunction.
class ReflectionFunction implements Reflector { }
class ReflectionMethod extends ReflectionFunction { }
But this is not how it works in PHP : when using type hinting, any
ReflectionMethod passed to a function or method that expect a
ReflectionFunction fails instead of working like with normal type
hinting.
Reproduce code:
---
class Foo {
public function bar(ReflectionFunction $fct) {
...
}
}
$c = new ReflectionClass('Foo');
$foo = new Foo();
$foo->bar($c->getMethod('bar'));
Expected result:
This should work because ReflectionMethod is a sub class of a
ReflectionFunction, and type hinting normally allows such thing (or the
documentation
[http://fr.php.net/manual/en/language.oop5.typehinting.php] should say
it clearly...)
Actual result:
--
[E_RECOVERABLE_ERROR] Argument 1 passed to Foo::bar() must be an
instance of ReflectionFunction, instance of ReflectionMethod given,
called in ... on line ... and defined' in ...
--
Edit this bug report at http://bugs.php.net/?id=40223&edit=1
[PHP-DOC] #30185 [Asn->Opn]: Documentation for native interfaces
ID: 30185 Updated by: [EMAIL PROTECTED] Reported By: sigsby at mopo3 dot com -Status: Assigned +Status: Open Bug Type: Documentation problem Operating System: NA PHP Version: 5.0.1 Assigned To: helly New Comment: I already did my part, see http://php.net/~helly Previous Comments: [2005-09-19 14:25:02] [EMAIL PROTECTED] Assigned to the SPL maintainer.. :) [2005-04-05 17:08:37] [EMAIL PROTECTED] Documentation is available at http://www.php.net/~helly/php/ext/spl/ , it should be probably incorporated to the manual. [2004-09-21 20:21:35] sigsby at mopo3 dot com Description: I contacted support about where to find documentation for the PHP 5 native interfaces. Gabor Hojtsy [EMAIL PROTECTED] replied saying that this is supposed to be covered in an appendix in the documentation, but it is apparently not complete. I was asked to open a bug report so the progress of this documentation can be tracked. Here ya go! -- Edit this bug report at http://bugs.php.net/?id=30185&edit=1
[PHP-DOC] #33355 [Opn->Csd]: SPL throws E_STRICT warnings as exceptions
ID: 33355
Updated by: [EMAIL PROTECTED]
Reported By: jr at terragate dot net
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: *
-PHP Version: 5*
+PHP Version: 5.0.4
Assigned To: helly
New Comment:
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation
better.
For the sake of old damaged code i turned of exception capturing for
E_STRICT.
Previous Comments:
[2005-08-16 11:45:38] jr at terragate dot net
At least it should be documented that you cannot pass an
object to a SPL class constructor that will cause execution
of PHP 4 code that will raise any E_STRICT or E_WARNING
message.
Furthermore, IMHO, this issue have still to be fixed in some
way as its takes much from SPLs potential and seems to be
inconsistent from a PHP developers point of view.
Example: Browse a WebDAV share
This could be easily done with (Recursive)DirectoryIterator
but the only available WebDAV stream Wrapper ( http://
pear.php.net/package/HTTP_WebDAV_Client ) is written in PHP
4.
So you could simply write a new PHP 5 Wrapper but most of
XML/HTTP/Network stuff have to be done from scratch as
almost all available classes for it are still PHP 4.
After looking into PHP internals I figured out that the is_a
deprecation warning seems to be the only E_STRICT message in
the code that isn't issued at compile time.
Thus handling is_a at compile time (as its done with
instanceof) would be another way to fix the issue but
requires some changes to the lexer and parser.
I am willing to do this if there is a chance that such a
modification have a chance of being applied.
[2005-06-16 19:38:30] [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
In this case i don't see any motivation to change since you shouldn't
be using is_a() anyway.
However the point is that unfortunatley some php internal api's do not
support detailed error informations. In fact no php internal code can
deliver detailed exceptions with the exception being a few xml and spl
classes. Thus it is not a problem of SPL which here only makes use of
other api's.
The reason SPL now needs to throw on warnings is that some of the
warnings mean that the object cannot be initialized thus being in an
invalid state so that it needs to be assuered that the constructor
fails so that the object cannot be used.
Since i cannot distunguish the cause of the error i am forced to throw
on any error. Actually i could limit it to E_WARNING but then again i'd
need to change a lot of php internal things.
[2005-06-15 17:14:00] jr at terragate dot net
Description:
Currently SPL sets the error_handling to EH_THROW which will
cause any E_WARNING or E_STRICT message to be thrown as
exception regardless of error_reporting's settings.
This renders most code with compatibility in mind (e.g.
PEAR) useless in SPL context since there is no way to ignore
non fatal warnings.
At least E_STRICT messages shouldn't be thrown if it is
disabled in error_reporting.
But this might still be confusing. E_STRICT massages should
be treated as compile time warnings (as in most other
languages). They shouln't affect the control flow if not
explicitly requested.
Generally the same applies to E_WARNING and E_USER_WARNING
as long as there is no way to disable EH_THROW in user space
php code.
IMHO EH_THROW should be completly disabled or the error mode
should be made controlable:
// ignore warnings from this wrapper
error_mode(EH_NORMAL);
$it = new DirectoryIterator('legacywrapper://path/');
// I want to stop on some warnings
error_mode(EH_THROW);
try {
$it = new DirectoryIterator('legacywrapper://path/');
} catch(Exception $e) {
// parse exception which might contain an E_WARNING
message
// this is not really OO but it works
...
if($criticalWarning) {
// bail out
throw new AMoreAppropriateException();
} else {
// non critical warning trying again with EH_NORMAL
// using normal php error/warning handling here
...
}
}
As long as all warnings are thrown as 'Exception' the
EH_THROW mode can't be used as different warnings cannot be
easily distinguished.
Reproduce code:
---
Expected result:
-
[PHP-DOC] #31102 [Csd]: Exception not handled when thrown inside __autoload()
ID: 31102 Updated by: [EMAIL PROTECTED] Reported By: php_nospam at ramihyn dot sytes dot net Status: Closed Bug Type: Documentation problem -Operating System: Windows 2000 SP4 +Operating System: * PHP Version: 5.0.2 -Assigned To: +Assigned To: helly New Comment: For further details on exceptions in __autoload() see: http://cvs.php.net/co.php/ZendEngine2/tests/bug31102.phpt?r=HEAD Previous Comments: [2004-12-29 17:15:59] [EMAIL PROTECTED] This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. "Exceptions thrown in __autoload function cannot be catched in the 'catch' block and result in fatal error." [2004-12-16 13:04:08] [EMAIL PROTECTED] hehe, perhaps. But we should mention this in the __autoload documentation though. [2004-12-16 12:57:48] php_nospam at ramihyn dot sytes dot net Your statement about that "last resort" is *not* documented. The Zend Engine 2 changes list says: The __autoload() interceptor function will be automatically called when an undeclared class is to be instantiated. The name of that class will be passed to the __autoload() interceptor function as its only argument. What __autoload() does is breaking the Exception handling, so I consider this as a bug. [2004-12-16 12:28:12] php_nospam at ramihyn dot sytes dot net Maybe you should rename the function to __lastresort() ;-) __autoload() sounds like autorun to me. [2004-12-15 23:59:35] php_nospam at ramihyn dot sytes dot net Also notice: the message isn't "Class 'Bug' not found" but an unhandled exception. 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/31102 -- Edit this bug report at http://bugs.php.net/?id=31102&edit=1
[PHP-DOC] #30741 [Opn->Bgs]: Interfaces must appear before use
ID: 30741
Updated by: [EMAIL PROTECTED]
Reported By: chris at experiencetours dot com dot au
-Status: Open
+Status: Bogus
Bug Type: Documentation problem
Operating System: Linux
PHP Version: 5.0.2
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
We decided on this behavior
Previous Comments:
[2004-11-10 09:42:53] [EMAIL PROTECTED]
It is written at
http://www.php.net/manual/en/migration5.incompatible.php :
"In some cases classes must be declared before used. It only happens
only if some of the new features of PHP 5 are used. Otherwise the
behaviour is the old."
Thus I think this bug can be marked as bogus.
[2004-11-10 08:11:32] [EMAIL PROTECTED]
This is expected behavior, but should be mentioned in PHP 5's migration
guide (http://de.php.net/manual/en/migration5.oop.php)
[2004-11-10 01:43:26] chris at experiencetours dot com dot au
Description:
I am not sure if this is a bug or a documentation issue, but if an
instance of a class is created before the Interface definition, the
class will be undefined. Although this is not directly covered in the
manual, it is inconsistent with functions, which can be reference
before they are defined.
./configure --with-apache=/usr/local/src/apache/apache_1.3.31
--with-libxml-dir=/usr/local/libxml2 --enable-calendar
--with-openssl=/usr --wi
th-pear --with-zlib --enable-ftp --with-bz2 --with-ldap --with-pdflib
--without-mysql --with-pgsql --with-pspell
Reproduce code:
---
$concreteType = new ConcreteType();
echo $concreteType->getText();
$c2 = new ContreteType2();
echo $c2->getText();
interface IType
{
public function getText();
}
abstract class AbstractType implements IType
{
}
class ConcreteType extends AbstractType
{
public function getText()
{
return "Hello World!!!";
}
}
class ConcreteType2 implements IType
{
public function getText()
{
return "Hello World!!!";
}
}
Expected result:
"Hello World!!!""Hello World!!!"
Actual result:
--
Fatal error: Class 'ConcreteType' not found in
/usr/local/apache/htdocs/bookallot/test.php on line 1
--
Edit this bug report at http://bugs.php.net/?id=30741&edit=1
[PHP-DOC] #30588 [Opn]: foreach on $this shows private/protected
ID: 30588
Updated by: [EMAIL PROTECTED]
Reported By: auroraeosrose at hotmail dot com
Status: Open
-Bug Type: *General Issues
+Bug Type: Documentation problem
-Operating System: WinXP SP2
+Operating System: *
-PHP Version: 5CVS-2004-10-27 (dev)
+PHP Version: 5.*
New Comment:
Foreach uses the current visibility. That is private and protected
inside the class and from outside the class only the public member
variables.
Previous Comments:
[2004-10-27 20:11:49] auroraeosrose at hotmail dot com
Description:
I have no idea whether this should be classified as an engine problem,
or a documentation problem.
When using BASIC foreach over an object inside a class method, (no
fancy spl stuff) it does not behave as documented on php.net - showing
only public properties. Foreach will have access to all properties
that the function/method it's used in has access to. This means
private and protected variables can be foreached inside the class. Now
this might be useful in some cases, but for me it's a headache because
there is no way to tell whether a property is protected/private/public
without using reflection - which is way too much overhead when you just
want to unset all the public properties in a class. Right now I have to
use a seperate function to do the unsetting, but it's a pain.
In conclusion: either foreach needs to be changed or the docs need to
be changed. If foreach CAN access all properties a function/method has
access to, there should be a QUICK, EASY way to find out if a property
is public/private/protect (e.g. is_public) so reflection doesn't have
to be hauled out just to find out that information.- I could play with
spl's arrayobject a bit but it still doesn't address the
documentation/behavior mismatch.
P.S. get_object_vars is affect by this as well
Reproduce code:
---
$item)
{
echo 'property '.$key.' = '.$item."\n";
}
}
}
$obj = new test();
$obj->loop();
foreach($obj as $key => $item)
{
echo 'property '.$key.' = '.$item."\n";
}
?>
Expected result:
property fruit = orange
property fruit = orange
Actual result:
--
property fruit = orange
property veggie = carrot
property meat = beef
property fruit = orange
--
Edit this bug report at http://bugs.php.net/?id=30588&edit=1
[PHP-DOC] #26930 [Bgs]: Inheritance of static functions
ID: 26930
Updated by: [EMAIL PROTECTED]
Reported By: reckert at informationsgesellschaft dot com
Status: Bogus
Bug Type: Documentation problem
Operating System: *
PHP Version: *
Assigned To: helly
New Comment:
Fixed in documentation (bla dot)
Previous Comments:
[2004-09-30 18:22:57] kell_pt at users dot sf dot net
I also filed a bug regarding this problem.
It's not so much a problem as how it works, but how it SHOULD work. It
is counter-intuitive the way inheritance works on static methods, and
should be addressed at least with a mention in the manual.
[2004-05-21 10:17:05] [EMAIL PROTECTED]
Dynamic binding has nothing to do with the caller of a
method/function, it is based on the [runtime] class of the
object instance whose method is being called.
Static methods do no operate on object instances, so
dynamic binding is impossible. No compiled OO language
does this. For PHP, it would also break BC.
[2004-05-21 05:23:42] kell_pt at users dot sf dot net
I beg to differ. If you call b::callInit() and b:: has init()
redefined, it SHOULD call the b::init when refering to self, regardless
of where that "self" is included.
Basically, "self" must take in consideration the caller. This is not
the only hint that the class mechanism is flawed in what concerns to
static methods / properties. Static data and methods should follow the
same concepts from class instances - it's how OOP works - change that
and you can't really claim it's OOP. :)
[2004-01-16 05:08:56] [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
inside callInit self === a
[2004-01-16 04:58:48] reckert at informationsgesellschaft dot com
Description:
In a static function X a call to another static function in the same
class uses the version of the function in the class where X is
implemented, not the one for which X was called for.
Reproduce code:
---
class a {
static function init() {
echo 'a::init()';
}
static function callInit() {
self::init();
// do something important
}
}
class b extends a {
static function init() {
echo 'b::init()';
}
}
b::callInit();
Expected result:
b::init()
Actual result:
--
a::init()
Shouldn't inheritance work the same way as for normal methods?
Thanks for comments,
Ralph
--
Edit this bug report at http://bugs.php.net/?id=26930&edit=1
[PHP-DOC] #29960 [Opn]: DirectoryIterator::fileType
ID: 29960
Updated by: [EMAIL PROTECTED]
Reported By: asgarbutt at ucdavis dot edu
Status: Open
-Bug Type: *Directory/Filesystem functions
+Bug Type: Documentation problem
-Operating System: Windows XP Professional SP 2
+Operating System: *
PHP Version: 5.0.1
New Comment:
DirectoryIterator has no file*() functions
Previous Comments:
[2004-09-03 00:37:46] asgarbutt at ucdavis dot edu
Found a better link to the SPL. It is still not complete, but it is
much more thorough that the documentation provided on
http://www.php.net/manual/en/function.directoryiterator-filetype.php
It can be found here at :
http://www.php.net/~helly/php/ext/spl/index.html
Sorry about the bug post.
[2004-09-03 00:27:08] asgarbutt at ucdavis dot edu
In my description, i wrote the wrong quote. It should be ...
Fatal error: Call to undefined method DirectoryIterator::fileType() in
C:\Apache2\htdocs\imagearchive\test.php on line 40
as stated in the Actual result section.
[2004-09-03 00:15:34] asgarbutt at ucdavis dot edu
Description:
When utilizing the new DirectoryIterator of PHP5 (5.0.1) I get the
following message.
Fatal error: Call to undefined method DirectoryIterator::fileExt() in
C:\Apache2\htdocs\imagearchive\test.php on line 40
The function is listed in the documentation but only minimumly.
Reproduce code:
---
$sPath = 'C:\Apache2\htdocs'
foreach (new DirectoryIterator($sPath) as $oFile) {
if ($oFile->isFile()) {
echo 'isFile => '.$oFile->isFile().'';
echo 'getFilename => '.$oFile->getFilename().'';
echo 'fileType => '.$oFile->fileType().'';
}
}
Expected result:
isFile => 1
getFilename => apache_pb.gif
fileType => .gif (or something similar)
Actual result:
--
isFile => 1
getFilename => apache_pb.gif
Fatal error: Call to undefined method DirectoryIterator::fileType() in
C:\Apache2\htdocs\imagearchive\test.php on line 40
--
Edit this bug report at http://bugs.php.net/?id=29960&edit=1
[PHP-DOC] #27555 [Opn->Fbk]: Unable to modify $_SESSION from __destruct()
ID: 27555
Updated by: [EMAIL PROTECTED]
Reported By: jaanus at heeringson dot com
-Status: Open
+Status: Feedback
Bug Type: Documentation problem
Operating System: Linux 2.4.24
PHP Version: 5CVS-2004-03-10 (dev)
-Assigned To:
+Assigned To: helly
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Previous Comments:
[2004-07-08 05:17:08] mikey-spam at mookins dot com
I am on Windows 2000, using PHP5 RC3. Having same problems.
I also believe that the modules should be shutdown after __destruct()
I am wondering if this is going to be fixed or is it not being
classified as a bug? [EMAIL PROTECTED] seems to think it's expected
behaviour but I never thought it would be which is why I am here after
googling about it.
__destruct() is a user definable method. All aspects of user programs
should have all the resources available to them from the start of the
script right through to the end.
Refcounting of whatever it was that they suggested is not an option, in
fact, I don't even know what that is.
-Mikey
[2004-06-15 11:07:03] dcaironi at yahoo dot com
I agree with fschaper.
The ability to modify the $_SESSION variable in the destructor could be
very useful, for example to have your class automatically serialized in
session; this, with a factory pattern (getInstance method, that
unserialized the class if exists in session), allow to have a "session
object", sort of.
for example
Class Test{
function __destruct(){
$_SESSION['test'] = serialize($this);
}
static function getInstance(){
$instance = unserialize($_SESSION['test']);
if(!isset($instance) || !is_a$instance,"test")){
$instance = new Test();
}
return $instance;
}
}
Actually, this was possible with php 4.x using
register_shutdown_function, that (in fact) allows to simulate the
destructor behaviour...
[2004-06-15 11:06:59] dcaironi at yahoo dot com
I agree with fschaper.
The ability to modify the $_SESSION variable in the destructor could be
very useful, for example to have your class automatically serialized in
session; this, with a factory pattern (getInstance method, that
unserialized the class if exists in session), allow to have a "session
object", sort of.
for example
Class Test{
function __destruct(){
$_SESSION['test'] = serialize($this);
}
static function getInstance(){
$instance = unserialize($_SESSION['test']);
if(!isset($instance) || !is_a$instance,"test")){
$instance = new Test();
}
return $instance;
}
}
Actually, this was possible with php 4.x using
register_shutdown_function, that (in fact) allows to simulate the
destructor behaviour...
[2004-06-01 17:22:22] fschaper at intux dot org
Why not to call the destructors before the modules are shut down? I
wrote a short patch for this and it works out fine (That does not mean
however that it does not break something ,) ).
http://www.intux.org/download/patches/patch_php_cvs_01_06_04.rar
[2004-03-11 04:34:16] [EMAIL PROTECTED]
It's still not documented, leave it as an open doc bug.
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/27555
--
Edit this bug report at http://bugs.php.net/?id=27555&edit=1
[PHP-DOC] #29045 [Sus]: gzopen for URL
ID: 29045
Updated by: [EMAIL PROTECTED]
Reported By: fcartegnie at nordnet dot fr
Status: Suspended
Bug Type: Documentation problem
-Operating System: Linux
+Operating System: *
-PHP Version: 4.3.6
+PHP Version: 4.3.7
Assigned To: pollita
New Comment:
You cannot drop STREAM_MUST_SEEK because the handler uses
seek. In case of http or ftp or what ever forward streams a temporary
file is created automatically so it still works as expected.
Previous Comments:
[2004-07-07 22:17:42] [EMAIL PROTECTED]
Wez needs to chime in on this...
I stated that it wouldn't work for http (with or without the patch)
because I thought we had disabled shrinking the chunk_size to 1 while
reading into the HTTP headers (for performance reasons). Looking back
at the code I see that the temporary shift into small chuck sizes *IS*
enabled when the STREAM_WILL_CAST flag is set (which it is for the zlib
fopen wrapper).
Maybe it was the conditional set based on the option flag that was the
compromise... in which case I'd say: Go ahead and use
fopen('compress.zlib://http://blah...',... but the patch provided for
gzopen() seems completely unnecessary.
[2004-07-07 16:16:46] [EMAIL PROTECTED]
compress.zlib://http://host.file.gz should work fine in php 4, not?
include "compress.zlib://file.php.gz"; works too ;-)
[2004-07-07 16:12:31] [EMAIL PROTECTED]
compress.zlib://host/path isn't actually valid.
What is valid however (as of PHP5) is:
$fp = fopen('http://host/path/file.gz', 'r');
/* Maybe a small fread() here to consume gzip headers, I don't recall
if they're sent with deflated content */
stream_filter_append($fp, 'zlib.inflate');
Note: For PHP 5.0 you need PECL package zlib_filter, it'll be rolled
into the core in PHP 5.1 .
The patch supplied above needs further review as I see a big potential
for zlib stream errors with the read buffer blocks that come in with
the headers.
[2004-07-07 14:39:51] fcartegnie at nordnet dot fr
compress.zlib://http:// seems to work
Maybe we could add some deprecation/pointer info in the documentation
of gzopen()
Changing for documentation problem
[2004-07-07 14:33:40] fcartegnie at nordnet dot fr
I did not see this syntax in the documentation.
fopen("compress.zlib://host.com/file.gz")
How would you specify HTTP or FTP ?
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/29045
--
Edit this bug report at http://bugs.php.net/?id=29045&edit=1
[PHP-DOC] #27555 [Opn->Bgs]: Unable to modify $_SESSION from __destruct()
ID: 27555 Updated by: [EMAIL PROTECTED] Reported By: jaanus at heeringson dot com -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: Linux 2.4.24 PHP Version: 5CVS-2004-03-10 (dev) 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 destructor is executed too late in the shutdown sequence. If you want a destructor to modify some $_SESSION then you need to manually refcount and free all references using unset() before the script terminates. Previous Comments: [2004-03-11 03:16:29] [EMAIL PROTECTED] Destructors are run (when not unset-ing yourself) after the session module finalizes the session so everything done in constructors has no effect. I agree it's not optimal behavior, but I don't think we need to classify it as a bug. It is not documented though so I'm making this a documentation problem. [2004-03-11 02:35:15] jaanus at heeringson dot com Yes, but that is not the issue here, is it? What this bug is about is the unability to add session variables from __destruct(). Obviously you have to reload the page to se the effect on the real session. The [destructor] => Yes will NEVER appear in $_SESSION. [2004-03-10 19:50:59] [EMAIL PROTECTED] If you put something like "echo 'this happens now';" line in the __destruct() call you will see that it's executed AFTER your print_r() line. This is correct behaviour. [2004-03-10 18:42:06] jaanus at heeringson dot com Description: Unable to add session variables from the __destruct() handler in a class. The $_SESSION variable can be accessed and viewed in the __destruct() handler though. Reproduce code: --- Expected result: Array ( [destructor] => Yes [working] => Yes ) Actual result: -- Array ( [working] => Yes ) -- Edit this bug report at http://bugs.php.net/?id=27555&edit=1
[PHP-DOC] #23786 [Opn->Asn]: pg_put_line invalidates all active large object resources
ID: 23786 Updated by: [EMAIL PROTECTED] Reported By: dave at codewhore dot org -Status: Open +Status: Assigned Bug Type: Documentation problem Operating System: Linux 2.4 PHP Version: 4CVS-2003-05-23 (stable) Assigned To: helly Previous Comments: [2003-05-24 00:54:12] dave at codewhore dot org I'm moving this to the documentation category, since I haven't been able to prove that the invalidation of open large object handles is actually a ext/pgsql problem (and not just intrinsic to the Postgres server/protocol/client-library). [2003-05-23 15:55:02] dave at codewhore dot org Hi: Use of the pg_put_line() function causes most large object operations, including pg_lo_read and pg_lo_tell, to subsequently fail. A test script demonstrates this: I would expect to see: resource(4) of type (pgsql link) resource(5) of type (pgsql result) resource(6) of type (pgsql large object) resource(7) of type (pgsql result) bool(true) bool(true) int(0) bool(true) Instead, I get: resource(4) of type (pgsql link) resource(5) of type (pgsql result) resource(6) of type (pgsql large object) resource(7) of type (pgsql result) bool(true) bool(true) int(-1) Warning: pg_lo_close(): Unable to close PostgreSQL large object descriptor 0. in /home/dave/test.php on line 14 bool(false) The pg_copy_from and pg_copy_to functions, strangely enough, don't exhibit this behavior. If this is something intrinsic to the design of Postgres' wire protocol (e.g. not a PHP bug - I don't know if it is or not), it'd be worth leaving a nice big warning in the docs for pg_put_line/pg_lo_open. Thanks in advance, - Dave -- Edit this bug report at http://bugs.php.net/?id=23786&edit=1
[PHP-DOC] #24657 [Opn]: php.ini location different for CLI
ID: 24657 Updated by: [EMAIL PROTECTED] Reported By: phyre at rogers dot com Status: Open Bug Type: Documentation problem Operating System: Linux PHP Version: 4.3.2 New Comment: man php Previous Comments: [2003-07-15 00:59:21] [EMAIL PROTECTED] I'm marking this as a documentation problem, as you can use php-cli.ini for specific settings for CLI. (Actually you can use php-.ini). I couldn't find docs for this though on line. [2003-07-14 23:10:36] phyre at rogers dot com Description: So, as many people I'm sure do, I require much different options (ie: safe mode, etc) for running under my web server than running from the command line, yet I can only choose one ini file. Various add-ons such as ZendDebugger I don't like starting up from the CLI. I assume it wouldn't be hard to add a --with-cli-config-file-path which works for the CLI only? I place php.ini in my apache config directory, which has restrictive rights. Hence, an end user can't load it. So PHP needs to be compiled in two pieces (I need to then make another build and ONLY install the CLI). Seems like this could be a simple fix and it seems to make sense. By default, it should point to the normal config path (--with-config-file-path). -- Edit this bug report at http://bugs.php.net/?id=24657&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #24499 [Opn]: Notice: Undefined property: stdClass::
ID: 24499
Updated by: [EMAIL PROTECTED]
Reported By: wks at wks dot ch
Status: Open
-Bug Type: PostgreSQL related
+Bug Type: Documentation problem
Operating System: FreeBSD 4.5
PHP Version: 5.0.0b1 (beta1)
New Comment:
Make it a doc problem since you obviously didn't read the docs. And
close it since it's all your fault :-)
What you're missing
class {
private $id;
function getId() {
$this->id = 1;
return $this->id;
}
}
Previous Comments:
[2003-07-04 11:35:57] wks at wks dot ch
Description:
In a class, if 'private' is used instead of 'var' for a variable
declaration then it fails with the Notice:
Undefined property: stdClassr'.
This still occurs if you make '$record = pg_fetch_object($q); return
$record->id;'
Reproduce code:
---
id;
}
}
$id = new Id();
echo $id->getId();
?>
Expected result:
1
Actual result:
--
Notice: Undefined property: stdClass::$id in /path/id_test.php on line
11
--
Edit this bug report at http://bugs.php.net/?id=24499&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #24105 [Opn->Csd]: class member functions aren't first class data objects
ID: 24105
Updated by: [EMAIL PROTECTED]
Reported By: knotwell at ix dot netcom dot com
-Status: Open
+Status: Closed
Bug Type:Documentation problem
PHP Version: 4.3.1
New Comment:
No, you're not requesting introspection here (btw. we will have that in
php5). What you want are function pointers. and your second example is
only the problem rewritten. Look at sniper's mail for the solution. If
you want to pass object and method the notation is
array($obj,$methodname).
Previous Comments:
[2003-06-10 00:42:02] knotwell at ix dot netcom dot com
So the methodology for this is (what I presume to be)introspection, if
possible, I'd suggest the addition to the documentation address the
following similar case as well:
class z {
function b($x,$y) {
return $x*$y;
}
}
$a = new z;
$b = $a->b;
$b(3,4) --> an error from the runtime system.
[2003-06-09 23:28:34] [EMAIL PROTECTED]
It's by design.
You're supposed to pass a string there, see below:
$specializedFn($specializedFnData);
}
class z {
var $x = 10;
var $y = 4;
function _mult($me) {
return($me->x * $me->y);
}
function aStupidlyContrivedExample() {
return generic_data_handler('_mult', $this);
}
}
$a = new z;
print $a->_mult($a);
// an error from the runtime system
print $a->aStupidlyContrivedExample();
?>
[2003-06-09 19:32:10] knotwell at ix dot netcom dot com
I've checked the documentation, but it doesn't address this
issue. As a result, I'm unsure if this is a bug or by design.
Anyhow, it appears class functions aren't first class data objects.
I've included a short example leading to a
"Call to undefined function" message as a example:
x * $me->y);
}
function aStupidlyContrivedExample() {
return generic_data_handler($this->_mult,$this);
}
}
$a = new z;
print $a->_mult($a);
// an error from the runtime system
print $a->aStupidlyContrivedExample();
?>
Apologies in advance if this is common knowledge or not a bug.
--
Edit this bug report at http://bugs.php.net/?id=24105&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #23826 [Opn->Csd]: ob_end_clean() returns error notice when buffer is empty
ID: 23826 Updated by: [EMAIL PROTECTED] Reported By: jc at mega-bucks dot co dot jp -Status: Open +Status: Closed Bug Type: Documentation problem -Operating System: Red Hat Linux 8.0 +Operating System: ANY PHP Version: 4.3.2RC4 -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 1) It is a notice and not an error 2) this notice tells you: you are doing unnecessary stuff 3) to clear all buffers do: while(@ob_end_clean()); Previous Comments: [2003-05-27 10:12:58] [EMAIL PROTECTED] Why do you want to check before calling ob_end_clean()? It seems you simply want to call that then why not @ob_end_clean()? [2003-05-27 03:19:41] jc at mega-bucks dot co dot jp Ok. I understand the "bug fix" but that fix now causes another problem ... I have a custom error handler with the following code: $buffer = ob_get_contents(); ob_end_clean(); The call to ob_end_clean() will throw a notice if the buffer if empty, which will cause the error handler to either fail or call itself again (possibly infinitely?). So just to be clear, it seems you are saying that *technically* calling ob_end_clean() on an empty buffer is incorrect? If this is so, what is the proprer way of checking if the buffer is empty before calling ob_end_clean()? If there is a way of checking wether the buffer is empty or not then all is fine, if not then there is a problem ;) [2003-05-27 03:10:02] [EMAIL PROTECTED] You don't need to submit anymore bug reports.. And I meant with that crash preventing that it now throws an error and returns false, reviously when it didn't check the buffer, it just crashed. (that was the fix) [2003-05-27 02:23:47] jc at mega-bucks dot co dot jp >The notice was added to prevent it from crashing with empty buffers I must be missing something ... how does throwing a notice prevent anything from crashing? Or do you mean there is absolutely no way to check that the output buffer is empty *except* to call ob_end_clean() and check to see if a notice was thrown or not? If that's the case then ... ouch. >Docs should mention this though. That would be nice ;) Does re-categorizing it as a documentation problem mean that someone will get around to it or should I submit a new documentation bug report? Thanks! [2003-05-27 02:17:44] [EMAIL PROTECTED] The notice was added to prevent it from crashing with empty buffers. Just use @ in front of it if it bothers you. Docs should mention this though. 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/23826 -- Edit this bug report at http://bugs.php.net/?id=23826&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #19077 [Ana->Csd]: dba_open fails
ID: 19077
Updated by: [EMAIL PROTECTED]
Reported By: wboring at qualys dot com
-Status: Analyzed
+Status: Closed
Bug Type: Documentation problem
Operating System: Redhat 6.2 kernel 2.2.10
PHP Version: 4.2.2
Assigned To: helly
New Comment:
Documentation was updated some time ago...
Previous Comments:
[2002-09-09 17:20:34] [EMAIL PROTECTED]
Yes, that's true..reclassified as documentation problem.
[2002-09-09 17:17:20] wboring at qualys dot com
If its not a bug in php, someone should not this anomaly in the php
docs, so other don't make the same mistake. There is no info on any of
the docs that say you need to "manually" semaphore access to the db
file.
I guess this means that only 1 script can access the db at 1 time,
which means slow. *sigh* I wish I could use a real DB.
[2002-09-09 17:12:39] [EMAIL PROTECTED]
There can only be one writer at the time. This really isn't bug in
PHP..just do what Wez proposed. (use the semaphores)
[2002-09-09 15:10:24] wboring at qualys dot com
Ok So I modified the dba_gdbm.c's dba_open call to output a little
debugging information
if(dbf) {
info->dbf = malloc(sizeof(dba_gdbm_data));
memset(info->dbf, 0, sizeof(dba_gdbm_data));
((dba_gdbm_data *) info->dbf)->dbf = dbf;
php_error(E_WARNING, "gdbm_open worked, %s\n",
gdbm_strerror(gdbm_errno));
return SUCCESS;
} else {
php_error(E_WARNING, "gdbm_open failed %s\n",
gdbm_strerror(gdbm_errno));
return FAILURE;
}
The error I am always getting is
PHP Warning: gdbm_open failed Can't be writer
from the gdbm_open call.
[2002-09-09 14:55:10] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
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.
If PHP really is bailing out when dba_open fails, we
need a backtrace to be able to determine the cause.
However, from what you describe, I don't think that this
crash is actually the cause of your problem - it's a
side-effect...
dba works by passing the calls through to your dbm style
library. Since the default for gdbm is to open the db in
locking mode (and that's what we're using), it sounds like
this is either an issue with gdbm itself or perhaps even
with your kernel.
It's doesn't say anywhere in the docs for gdbm that
multiple writers will block when accessing the database,
so I would expect to get those intermittent errors you
reported. (not a bug).
So it seems that you need to manually ensure that writers
will block - rather than use flock to protect your db, try
using a semaphore from the sysvsem extension (much more
reliable).
Other things to try are upgrading (or perhaps downgrading)
your gdbm installation and see if that makes a difference.
(See if there are any known issues with gdbm too).
--Wez.
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/19077
--
Edit this bug report at http://bugs.php.net/?id=19077&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20822 [Asn->Csd]: getimagesize() returning null instead of false
ID: 20822 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: Documentation problem Operating System: linux PHP Version: 4.2.3 Assigned To: john New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. In 4.2.3 there was just another possibility to return NULL. Now all current versions (4.2.3-cvs, 4.3.0-cvs, cvs) return FALSE in *every* case. If someone does not want the error messages from file in/output start another bugreport please. But i suggest to have them in because they show the reason why GetImagesize() fails. At least until we output specific messages inside image.c itself. Previous Comments: [2002-12-05 03:37:13] [EMAIL PROTECTED] didnt read the other email's :) anyway returning false on everything and removing that E_ERROR does the trick :) thanks php team! [2002-12-05 03:34:16] [EMAIL PROTECTED] unless getimagesize() started to take more than one parameter, i have everything necessery i pretty much get an error if the filesize of the file is 0 bytes, and get NULL if the file is not an image (maybe i dont get it always - but the plaintext files i tried always returned NULL for me the manual should specify the result as NULL or FALSE, but i dont think your comment here is correct - atleast not to my testing. perhaps if you replace null with false, and vice versa, because i do get null with valid parameters. cheers [2002-12-05 01:42:08] [EMAIL PROTECTED] getimagesize() returns NULL only in one case and that being if invalid parameters are passed to the functions. For example calling getimagesize() without any parameters. Invalid files and so on, result in the documentated FALSE return value. [2002-12-04 20:54:17] [EMAIL PROTECTED] maybe its also worth mentioning that getimagesize() spews out an error if the filesize() of the file is 0 bytes :/ - this isnt so nice :/ [2002-12-04 20:47:55] [EMAIL PROTECTED] cutting out from the php manual: If accessing the filename image is impossible, or if it isn't a valid picture, getimagesize() will return FALSE and generate a warning. ... when getimagesize() in fact returns NULL (atleast in 4.2.3 (debian unstable tree)) -- Edit this bug report at http://bugs.php.net/?id=20822&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20663 [Opn]: trigger_error silently truncates the error to 1024 chars.
ID: 20663
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: Any
PHP Version: 4.2.0
New Comment:
The following fix is against ZE2:
cvs -z3 -q diff zend.c (in directory S:\php4-HEAD\Zend)
Index: zend.c
===
RCS file: /repository/ZendEngine2/zend.c,v
retrieving revision 1.193
diff -u -r1.193 zend.c
--- zend.c 30 Nov 2002 11:20:25 - 1.193
+++ zend.c 30 Nov 2002 16:55:20 -
@@ -703,8 +703,6 @@
}
-#define ZEND_ERROR_BUFFER_SIZE 1024
-
ZEND_API void zend_error(int type, const char *format, ...)
{
va_list args;
@@ -775,18 +773,7 @@
ALLOC_INIT_ZVAL(z_error_filename);
ALLOC_INIT_ZVAL(z_error_lineno);
ALLOC_INIT_ZVAL(z_context);
- z_error_message->value.str.val = (char *)
emalloc(ZEND_ERROR_BUFFER_SIZE);
-
-#ifdef HAVE_VSNPRINTF
- z_error_message->value.str.len =
vsnprintf(z_error_message->value.str.val, ZEND_ERROR_BUFFER_SIZE,
format, args);
- if (z_error_message->value.str.len > ZEND_ERROR_BUFFER_SIZE-1)
{
- z_error_message->value.str.len =
ZEND_ERROR_BUFFER_SIZE-1;
- }
-#else
- strncpy(z_error_message->value.str.val, format,
ZEND_ERROR_BUFFER_SIZE);
- /* This is risky... */
- /* z_error_message->value.str.len =
vsprintf(z_error_message->value.str.val, format, args); */
-#endif
+ z_error_message->value.str.len =
vspprintf(&z_error_message->value.str.val, 0, format, args);
z_error_message->type = IS_STRING;
z_error_type->value.lval = type;
Previous Comments:
[2002-11-26 17:36:19] [EMAIL PROTECTED]
trigger_error silently truncates your error after 1024 chars
(ZEND_ERROR_BUFFER_SIZE in the source). I didn't see this documented
anywhere, so I'm reporting it as a documentation problem. I'd rather
it be changed to take unlimited length strings than documented, but
documenting it would be a good first step.
--
Edit this bug report at http://bugs.php.net/?id=20663&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #14219 [Opn->Csd]: Various documentation suggestions
ID: 14219 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: General PHP Version: 4.1.1 -Assigned To: +Assigned To: helly New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip *First of all db is deprecated. *dblist() just returns a simple string that describes the external library being used. Add in the docs already. => Allways use dba !!! *i will try to gather some information together with Wez since he knows more about the library functions bein used. Gernerally flatfile support for dba is better than flatfile support in db. *there will be an emulation from dba to db in php > 4.3 when we will remove db. *since php 4.3 dba does locking as documented (needs to be updated on php.net). Earlier version only do locking for gdbm. Previous Comments: [2002-04-06 05:45:49] [EMAIL PROTECTED] /usr/local/bin/php gets built automatically starting with 4.2.0 or 4.3.0. dblist() exists in the source, so I guess it works :) The following two suggestions remain: * the DBM function section should elaborate a bit on the internal flatfile database: does it use hashing? is the key or data size restricted? * the relationship between the DBM and DBA functions should be made clearer. When should one use which? Do the DBA functions do automatical locking like the DBM functions? The two should be cross linked at the very least. [2002-02-24 07:37:22] [EMAIL PROTECTED] * Fixed the libSWF-issue in CVS * Fixed the string-issue in CVS [2001-11-25 20:59:52] [EMAIL PROTECTED] The PHP manual is of exceptional high quality and the following are mere suggestions, not real bugs: * the SWF function section should have a link to the Ming function section * the string function section should have a link to the regexp function section * It should be explained somewhere how one can produce a /usr/local/bin/php parser for use as an external cgi handler or as standalone script engine. If it is automatically generated by make, then it didn't turn up in my /usr/local/bin. * the DBM function section should elaborate a bit on the internal flatfile database: does it use hashing? is the key or data size restricted? * the dblist() function doesn't exist for me. I compiled with --with-gdbm. Typo? * the relationship between the DBM and DBA functions should be made clearer. When should one use which? Do the DBA functions do automatical locking like the DBM functions? The two should be cross linked at the very least. Thanks for a excellent product, Axel -- Edit this bug report at http://bugs.php.net/?id=14219&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #19669 [Opn->Bgs]: Incomplete documentation for dba_replace
ID: 19669 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Documentation problem -Operating System: linux +Operating System: ANY -PHP Version: 4.2.1 +PHP Version: ANY 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 the way such libraries work :-( Previous Comments: [2002-10-15 09:06:02] [EMAIL PROTECTED] I discoverd today that this problem is not actually a problem, but is inherent to the way gdbm (and probably other dbm-style databases) works. If the value of the new entry is longer or shorter than that of the old one, gdbm will insert a new key/value pair, but will not delete the old one, probably for the sake of performance. Only when an optimize is done on the database file, the old key/value pair will be deleted. Gdbm will return the correct value however, even if there seem to be two entries (as seen with less filename.db). [2002-09-30 05:51:49] [EMAIL PROTECTED] I'm using three gdbm databases which are read and written to by both a C daemon and a php-script. [2002-09-30 05:45:05] [EMAIL PROTECTED] which ext/dba backend are you refering to? gdbm, db2, db3? [2002-09-30 03:34:16] [EMAIL PROTECTED] I think it might be worth mentioning in the documentation for the dba_replace function that to actually replace an entry in a *DBM-type database, you need to pad the value to the exact lenght of the value to be replaced. This seems to go for both entries shorter and longer than the replacing value. I also added a comment to the documention to this extent but this is, in my opinion, cardinal to the differance between dba_replace and dba_insert so it might be worth mentioning. Also, data corruption and infinite growth of the data file will result if the length is not padded. -- Edit this bug report at http://bugs.php.net/?id=19669&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20094 [Opn->Csd]: image_type_to_mime_type() missing from docs
ID: 20094 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type:Documentation problem PHP Version: 4.3.0-pre1 New Comment: Function is added at least in online help. Previous Comments: [2002-10-25 13:06:51] [EMAIL PROTECTED] Please add php_image_type_to_mime_type() to the documentation. array image_type_to_mime_type(int imagetype) Convert internal image_type to mime type -- Edit this bug report at http://bugs.php.net/?id=20094&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #18666 [Opn->Csd]: extendet functionality of getimagesize with php4.3.0?
ID: 18666 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Compaq Tru64 PHP Version: 4CVS-2002-07-31 New Comment: This bug has been fixed in CVS. You can grab a snapshot of the CVS version at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites. Thank you for the report, and for helping us make PHP better. This is documented already Previous Comments: [2002-07-31 09:02:36] [EMAIL PROTECTED] When testing getimagesize with php 4.2.2 I get these results: ( [0] => 194 [1] => 54 [2] => 1 [3] => width="194" height="54" ) Array ( [0] => 280 [1] => 231 [2] => 2 [3] => width="280" height="231" [bits] => 8 [channels] => 3 ) With PHP 4.3.0-dev I get these results: Array ( [0] => 194 [1] => 54 [2] => 1 [3] => width="194" height="54" [bits] => 8 [channels] => 3 [mime] => image/gif ) Array ( [0] => 280 [1] => 231 [2] => 2 [3] => width="280" height="231" [bits] => 8 [channels] => 3 [mime] => image/jpeg ) If this an expected result, it should be documented. If 4.2.0 simply has a bug consider it as closed ;) -- Edit this bug report at http://bugs.php.net/?id=18666&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
