Bug #64793 [Com]: finfo_open raises warning with env magic file
Edit report at https://bugs.php.net/bug.php?id=64793edit=1 ID: 64793 Comment by: weierophin...@php.net Reported by:weierophin...@php.net Summary:finfo_open raises warning with env magic file Status: Not a bug Type: Bug Package:Filesystem function related Operating System: Ubuntu 13.04 PHP Version:5.4.14 Block user comment: N Private report: N New Comment: After receiving the answer to this issue, I decided to run unset MAGIC in my shell, as the implication is that if you do this, PHP will use its own internal magic.mime database. This indeed works. Unfortunately, the documentation is completely wrong, which is why I never determined the correct course of action. It states: Name of a magic database file, usually something like /path/to/magic.mime. If not specified, the MAGIC environment variable is used. If this variable is not set either, /usr/share/misc/magic is used by default. A .mime and/or .mgc suffix is added if needed. Passing NULL or an empty string will be equivalent to the default value. Clearly this is incorrect, as the default is actually to use the magic database PHP bundles. Previous Comments: [2013-05-09 07:50:37] a...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php It's expected that the magic file format change across the libmagic versions. This way you may experience some difference even within the same version, libmagic was upgraded for 5.4.1 and now again in 5.4.15. The recommended way is to use the compiled in magic, passing a magic file from outside you have to care about the version compatibility. The same were obviously the experience if you use the file commando with different magic file versions. [2013-05-08 18:25:28] weierophin...@php.net Description: Using either the system magic file (/usr/share/file/magic.mgc) or the one shipped with PHP (http://lxr.php.net/xref/PHP_5_5/ext/fileinfo/tests/magic? r=12cf930a403d0bbee0c40a5e93554cafd6b0895e), and ensuring that my MAGIC env points to the file, any call to finfo_open() that does not specify a MIME file raises a warning: offset `' invalid. This occurs in 5.3.3 and 5.4.14; I cannot reproduce it in 5.3.21. I've tried a variety of magic files, and not yet found one that works reliably across versions. Test script: --- $finfo = finfo_open(FILEINFO_MIME_TYPE); Expected result: (no error) Actual result: -- finfo_open(): Warning: offset `' invalid -- Edit this bug report at https://bugs.php.net/bug.php?id=64793edit=1
[PHP-BUG] Bug #64793 [NEW]: finfo_open raises warning with env magic file
From: weierophinney Operating system: Ubuntu 13.04 PHP version: 5.4.14 Package: Filesystem function related Bug Type: Bug Bug description:finfo_open raises warning with env magic file Description: Using either the system magic file (/usr/share/file/magic.mgc) or the one shipped with PHP (http://lxr.php.net/xref/PHP_5_5/ext/fileinfo/tests/magic? r=12cf930a403d0bbee0c40a5e93554cafd6b0895e), and ensuring that my MAGIC env points to the file, any call to finfo_open() that does not specify a MIME file raises a warning: offset `' invalid. This occurs in 5.3.3 and 5.4.14; I cannot reproduce it in 5.3.21. I've tried a variety of magic files, and not yet found one that works reliably across versions. Test script: --- $finfo = finfo_open(FILEINFO_MIME_TYPE); Expected result: (no error) Actual result: -- finfo_open(): Warning: offset `' invalid -- Edit bug report at https://bugs.php.net/bug.php?id=64793edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64793r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64793r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64793r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64793r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64793r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64793r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64793r=needscript Try newer version: https://bugs.php.net/fix.php?id=64793r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64793r=support Expected behavior: https://bugs.php.net/fix.php?id=64793r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64793r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64793r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64793r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64793r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64793r=dst IIS Stability: https://bugs.php.net/fix.php?id=64793r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64793r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64793r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64793r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64793r=mysqlcfg
[PHP-BUG] Bug #60321 [NEW]: ob_get_status(true) no longer returns an array when buffer is empty
From: weierophinney Operating system: Linux 64bit PHP version: 5.4.0RC1 Package: Output Control Bug Type: Bug Bug description:ob_get_status(true) no longer returns an array when buffer is empty Description: Prior to 5.4.0RC1, ob_get_status(true) would always return an array, even if no buffers were present. With 5.4.0RC1, it now returns boolean false. Test script: --- $return = ob_get_status(true); var_export($return); Expected result: array( ) Actual result: -- false -- Edit bug report at https://bugs.php.net/bug.php?id=60321edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60321r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60321r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60321r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60321r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60321r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60321r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60321r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60321r=needscript Try newer version: https://bugs.php.net/fix.php?id=60321r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60321r=support Expected behavior: https://bugs.php.net/fix.php?id=60321r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60321r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60321r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60321r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60321r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60321r=dst IIS Stability: https://bugs.php.net/fix.php?id=60321r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60321r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60321r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60321r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60321r=mysqlcfg
[PHP-BUG] Bug #60322 [NEW]: ob_get_clean() now raises an E_NOTICE if no buffers exist
From: weierophinney
Operating system: Linux 64bit
PHP version: 5.4.0RC1
Package: Output Control
Bug Type: Bug
Bug description:ob_get_clean() now raises an E_NOTICE if no buffers exist
Description:
Prior to 5.4.0RC1, when calling ob_get_clean() with no buffers present, no
errors
were raised. Starting with 5.4.0RC1, the function now raises an E_NOTICE in
such
situations.
Test script:
---
ini_set('display_errors', true);
error_reporting(-1);
$return = ob_get_clean();
Expected result:
(no output)
Actual result:
--
Notice: ob_get_clean(): failed to delete buffer. No buffer to delete
--
Edit bug report at https://bugs.php.net/bug.php?id=60322edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60322r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60322r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60322r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60322r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60322r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60322r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60322r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60322r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60322r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60322r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60322r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60322r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60322r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60322r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60322r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60322r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60322r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60322r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60322r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60322r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60322r=mysqlcfg
Bug #48795 [Com]: Building intl 64-bit fails on OS X
Edit report at https://bugs.php.net/bug.php?id=48795edit=1
ID: 48795
Comment by: weierophin...@php.net
Reported by:gwy...@php.net
Summary:Building intl 64-bit fails on OS X
Status: Verified
Type: Bug
Package:Compile Failure
Operating System: OS X 10.5 10.6; Linux
PHP Version:5.3 SVN; 5.4.0RC1
Block user comment: N
Private report: N
New Comment:
I can confirm Stas's suggestion (s/CC/CXX/ in BUILD_* vars) works with 5.4.0RC1
on linux 64-bit.
Previous Comments:
[2011-11-11 11:30:21] ahar...@php.net
tl;dr: Debian Testing and Ubuntu 11.10 have the same problem with
./configure --enable-intl --with-curl.
Effectively the same issue (required C++ linkage not occurring) is now
happening on Ubuntu 11.10 (x86-64) and Debian Testing (armv7l) with
PHP 5.3 SVN and PHP 5.4.0RC1 when compiling with both intl and curl
enabled (note that a compile with just --enable-intl succeeds). It's
notable that both these distributions feature the new Debian
multiarch support. Both libcurl and libicu are the normal packaged
versions.
With ./configure --enable-intl --with-curl, the result of
the compile (on the Ubuntu box, although the Debian errors are
effectively the same, just with different architecture-specific paths)
is this:
/usr/bin/ld: ext/intl/msgformat/msgformat_helpers.o: undefined reference to
symbol '__gxx_personality_v0@@CXXABI_1.3'
/usr/bin/ld: note: '__gxx_personality_v0@@CXXABI_1.3' is defined in DSO
/usr/lib/x86_64-linux-gnu/libstdc++.so.6 so try adding it to the linker command
line
/usr/lib/x86_64-linux-gnu/libstdc++.so.6: could not read symbols: Invalid
operation
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php-cgi] Error 1
Diffing the Makefile produced by --enable-intl alone with the
--enable-intl --with-curl combination produces the following
(excluding rules directly related to compiling objects within
ext/curl):
@@ -75,9 +76,9 @@
CXXFLAGS_CLEAN = -g -O2
DEBUG_CFLAGS =
EXTENSION_DIR = /usr/local/lib/php/extensions/no-debug-non-zts-20100525
-EXTRA_LDFLAGS =
-EXTRA_LDFLAGS_PROGRAM =
-EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lrt -lm -ldl -lnsl -lxml2 -lxml2
-ldl -lm -licui18n -licuuc -licudata -ldl -lm -licuio -lxml2 -lcrypt -lxml2
-lxml2 -lxml2 -lcrypt
+EXTRA_LDFLAGS = -L/usr/lib/x86_64-linux-gnu
+EXTRA_LDFLAGS_PROGRAM = -L/usr/lib/x86_64-linux-gnu
+EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lcurl -lrt -lm -ldl -lnsl -lxml2
-lcurl -lxml2 -ldl -lm -licui18n -licuuc -licudata -ldl -lm -licuio -lxml2
-lcrypt -lxml2 -lxml2 -lxml2 -lcrypt
ZEND_EXTRA_LIBS =
INCLUDES = -I/tmp/php-5.4.0RC1/ext/date/lib -I/tmp/php-5.4.0RC1/ext/ereg/regex
-I/usr/include/libxml2 -I/tmp/php-5.4.0RC1/ext/sqlite3/libsqlite
-I$(top_builddir)/TSRM -I$(top_builddir)/Zend
EXTRA_INCLUDES =
@@ -86,13 +87,13 @@
LFLAGS =
LIBTOOL = $(SHELL) $(top_builddir)/libtool --silent --preserve-dup-deps
LN_S = ln -s
-NATIVE_RPATHS =
+NATIVE_RPATHS = -Wl,-rpath,/usr/lib/x86_64-linux-gnu
PEAR_INSTALLDIR = ${exec_prefix}/lib/php
PHP_BUILD_DATE = 2011-11-11
-PHP_LDFLAGS =
+PHP_LDFLAGS = -L/usr/lib/x86_64-linux-gnu
PHP_LIBS =
OVERALL_TARGET =
-PHP_RPATHS =
+PHP_RPATHS = -R /usr/lib/x86_64-linux-gnu
PHP_SAPI = none
PHP_VERSION = 5.4.0RC1
PHP_VERSION_ID = 50400
Stas's suggestion of replacing the $(BUILD_CGI) and $(BUILD_CLI)
instances of $(CC) in the generated Makefile with $(CXX) fixes the
build.
I'm not familiar enough with our build system to know how to fix this,
but we should probably do something if we can for 5.4.0 final: intl
and curl doesn't seem like it would be an unusual combination. Can we
hack the build system to use the C++ compiler preferentially if
ext/intl and ext/curl are enabled, if it can't be fixed properly
(whatever form that takes -- it may even up being an upstream issue)?
[2011-11-06 19:11:09] luke at cywh dot com
Is there going to be a proper fix for this any time soon? I'm having a lot of
trouble getting 5.3.8 to compile on OS X 10.6.8.
[2011-07-01 16:23:27] harald dot lapp at gmail dot com
just setting the EXTRA_LIBS did not work for me, but stas tip made it work.
(PHP
5.3.6, Mac OS X 10.6.7), thanks!
[2010-06-17 19:43:39] henrik at bearwoods dot dk
I have tried the above quick-fixes and have not been able to compile it yet.
Im on a Macbook Pro i5 and 10.6.4 (Maybe the i5 makes a difference)
[2010-05-24 21:19:51] s...@php.net
Also if you change $(CC) to $(CXX) in BUILD_* vars in Makefile it seems to help
too. Looks like if you use C++ anywhere in PHP the linker should be C++ or
library should be added
[PHP-BUG] Bug #53710 [NEW]: Data registered with equal priority not returned in expected order
From: weierophinney
Operating system: Linux 32-bit
PHP version: 5.3.5
Package: SPL related
Bug Type: Bug
Bug description:Data registered with equal priority not returned in expected
order
Description:
SplPriorityQueue does not behave as expected when data is registered with
equal
priority. One would expect one of the following situations:
* The data retain the same order as how they were registered
* The data are ordered based on value
Neither of these are the case, however. From empirical analysis, it appears
that
the following happens:
* The first item registered at that priority will always be the first
returned
* The remaining items are returned in the reverse order in which they were
enqueued.
Test script:
---
$queue = new SplPriorityQueue();
$queue-insert('foo', 100);
$queue-insert('bar', 100);
$queue-insert('baz', 100);
$queue-insert('bat', 100);
foreach ($queue as $data) {
echo $data, \n;
}
Expected result:
// IDEALLY order in which they are registered:
foo
bar
baz
bat
// OR following same rules as priority queue -- higher values == higher
priority
foo
baz
bat
bar
Actual result:
--
foo
bat
baz
bar
--
Edit bug report at http://bugs.php.net/bug.php?id=53710edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53710r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53710r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53710r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53710r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53710r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53710r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53710r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53710r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53710r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53710r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53710r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53710r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53710r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53710r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53710r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53710r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53710r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53710r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53710r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53710r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53710r=mysqlcfg
[PHP-BUG] Bug #51527 [NEW]: is_callable() returning true for non-static callbacks
From: weierophinney
Operating system: Linux
PHP version: 5.3.2
Package: Class/Object related
Bug Type: Bug
Bug description:is_callable() returning true for non-static callbacks
Description:
is_callable() is returning a false-positive for callbacks that reference
non-
static methods. As an example, if I have defined a class 'Foo' with an
instance
(i.e., non-static) method 'bar', and define the callback array('Foo',
'bar'),
is_callable() will falsely return true.
Additionally, if you then pass this callback to call_user_func(), this
latter
function will actually try to call the method statically -- and raise an
E_STRICT about the callback being invalid. If the method has any references
to
$this, it then fails with an E_FATAL, but otherwise it will run the method
as if
it were static.
This behavior is unexpected, and unintuitive. Calling non-static methods as
if
they were static, even when they do not reference $this, violates
visibility. I
would expect is_callable() to return false in these instances, and for
call_user_func() to immediately raise an E_FATAL if the method is not
defined as
static.
Test script:
---
class Foo
{
public function bar()
{
return 'foo bar';
}
}
$callback = array('Foo', 'bar');
if (is_callable($callback)) {
echo call_user_func($callback);
}
Expected result:
No output.
Actual result:
--
PHP Strict Standards: call_user_func() expects parameter 1 to be a valid
callback, non-static method Foo::bar() should not be called statically
Strict Standards: call_user_func() expects parameter 1 to be a valid
callback,
non-static method Test\Foo::bar() should not be called statically
foo bar
--
Edit bug report at http://bugs.php.net/bug.php?id=51527edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51527r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51527r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51527r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51527r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51527r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51527r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51527r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51527r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51527r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51527r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51527r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51527r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51527r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51527r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51527r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51527r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51527r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51527r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51527r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51527r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51527r=mysqlcfg
Bug #51527 [Com]: is_callable() returning true for non-static callbacks
Edit report at http://bugs.php.net/bug.php?id=51527edit=1
ID: 51527
Comment by: weierophin...@php.net
Reported by: weierophin...@php.net
Summary: is_callable() returning true for non-static callbacks
Status: Open
Type: Bug
Package: Class/Object related
Operating System: Linux
PHP Version: 5.3.2
New Comment:
@pajoye: Yes, this particular example was callable. However, if the
method is
actually an instance method, and has references to $this, is_callable()
still
returns true -- making it an invalid test to use to determine whether or
not it's
safe to then call call_user_func(). Instead, to really determine if the
callback
is valid, you have to start doing a bunch of reflection -- checking to
see if the
method is defined and static, or if there is a __callStatic defined that
would
intercept the call.
That's the more serious implication of the behavior, and why it needs to
be
fixed.
Previous Comments:
[2010-04-10 16:29:12] paj...@php.net
It is actually callable. But calling it statically breaks the strict
standards, but the strict standards will break BC in many situations.
I would suggest to make this change in trunk only.
[2010-04-10 16:07:17] weierophin...@php.net
Description:
is_callable() is returning a false-positive for callbacks that reference
non-
static methods. As an example, if I have defined a class 'Foo' with an
instance
(i.e., non-static) method 'bar', and define the callback array('Foo',
'bar'),
is_callable() will falsely return true.
Additionally, if you then pass this callback to call_user_func(), this
latter
function will actually try to call the method statically -- and raise an
E_STRICT about the callback being invalid. If the method has any
references to
$this, it then fails with an E_FATAL, but otherwise it will run the
method as if
it were static.
This behavior is unexpected, and unintuitive. Calling non-static methods
as if
they were static, even when they do not reference $this, violates
visibility. I
would expect is_callable() to return false in these instances, and for
call_user_func() to immediately raise an E_FATAL if the method is not
defined as
static.
Test script:
---
class Foo
{
public function bar()
{
return 'foo bar';
}
}
$callback = array('Foo', 'bar');
if (is_callable($callback)) {
echo call_user_func($callback);
}
Expected result:
No output.
Actual result:
--
PHP Strict Standards: call_user_func() expects parameter 1 to be a
valid
callback, non-static method Foo::bar() should not be called statically
Strict Standards: call_user_func() expects parameter 1 to be a valid
callback,
non-static method Test\Foo::bar() should not be called statically
foo bar
--
Edit this bug report at http://bugs.php.net/bug.php?id=51527edit=1
Bug #51527 [Com]: is_callable() returning true for non-static callbacks
Edit report at http://bugs.php.net/bug.php?id=51527edit=1
ID: 51527
Comment by: weierophin...@php.net
Reported by: weierophin...@php.net
Summary: is_callable() returning true for non-static callbacks
Status: Bogus
Type: Bug
Package: Class/Object related
Operating System: Linux
PHP Version: 5.3.2
New Comment:
@johannes Perhaps an optional strict flag to is_callable() would
address this?
That would keep BC, while allowing for better checking for = PHP-5
apps. Usage
would be:
$callback = array('Foo', 'bar');
if (is_callable($callback, true)) {
// Passed strict check
} else {
// failed strict check
}
Thoughts?
Previous Comments:
[2010-04-10 17:55:25] johan...@php.net
The method can always be called statically. The access to $this might be
forbidden but the method itself can be called. is_callable() doesn't
mean it will execute properly. (the $this error is basically the same as
a call to an undefined funciton in there or such)
To change this the only way would be to forbid calling non-static
methods statically. Maybe this can be done nowadays (we needed the
behavior for PHP 4 compatibility) but that's no bug but requires a RFC
and discussion on internals as this might break quite a few applications
(many PEAR-based things, many legacy applications not fully converted
to PHP 5 )
[2010-04-10 16:43:31] weierophin...@php.net
@pajoye: Yes, this particular example was callable. However, if the
method is
actually an instance method, and has references to $this, is_callable()
still
returns true -- making it an invalid test to use to determine whether or
not it's
safe to then call call_user_func(). Instead, to really determine if the
callback
is valid, you have to start doing a bunch of reflection -- checking to
see if the
method is defined and static, or if there is a __callStatic defined that
would
intercept the call.
That's the more serious implication of the behavior, and why it needs to
be
fixed.
[2010-04-10 16:29:12] paj...@php.net
It is actually callable. But calling it statically breaks the strict
standards, but the strict standards will break BC in many situations.
I would suggest to make this change in trunk only.
[2010-04-10 16:07:17] weierophin...@php.net
Description:
is_callable() is returning a false-positive for callbacks that reference
non-
static methods. As an example, if I have defined a class 'Foo' with an
instance
(i.e., non-static) method 'bar', and define the callback array('Foo',
'bar'),
is_callable() will falsely return true.
Additionally, if you then pass this callback to call_user_func(), this
latter
function will actually try to call the method statically -- and raise an
E_STRICT about the callback being invalid. If the method has any
references to
$this, it then fails with an E_FATAL, but otherwise it will run the
method as if
it were static.
This behavior is unexpected, and unintuitive. Calling non-static methods
as if
they were static, even when they do not reference $this, violates
visibility. I
would expect is_callable() to return false in these instances, and for
call_user_func() to immediately raise an E_FATAL if the method is not
defined as
static.
Test script:
---
class Foo
{
public function bar()
{
return 'foo bar';
}
}
$callback = array('Foo', 'bar');
if (is_callable($callback)) {
echo call_user_func($callback);
}
Expected result:
No output.
Actual result:
--
PHP Strict Standards: call_user_func() expects parameter 1 to be a
valid
callback, non-static method Foo::bar() should not be called statically
Strict Standards: call_user_func() expects parameter 1 to be a valid
callback,
non-static method Test\Foo::bar() should not be called statically
foo bar
--
Edit this bug report at http://bugs.php.net/bug.php?id=51527edit=1
Req #50029 [Com]: Weird invoke issue on class as property
Edit report at http://bugs.php.net/bug.php?id=50029edit=1
ID: 50029
Comment by: weierophin...@php.net
Reported by: marc dot gray at gmail dot com
Summary: Weird invoke issue on class as property
Status: Analyzed
Type: Feature/Change Request
Package: Feature/Change Request
Operating System: Ubuntu 9.04
PHP Version: 5.3.0
New Comment:
I can understand wanting to ensure that collisions between existing
methods and
invokable properties don't occur, but when there aren't any collisions,
it
doesn't make sense.
I'd argue that the following behavior should be implemented:
* If no matching method exists, simply allow invoking.
* If a matching method exists, call the method, and raise either an
E_NOTICE or
E_WARNING indicating the collision.
Right now, it's a fairly big WTF moment -- you expect it to work, and
instead
get an E_FATAL. Copying to a temporary variable is code clutter,
particularly
when you know the object is invokable.
Previous Comments:
[2009-11-02 15:58:23] ka...@php.net
There was lots of discussion about this, because it could override class
methods like:
class Test {
private $closure;
public function __construct() {
$this-closure = function() {
echo 'Hello World';
};
}
public function closure() {
echo 'Hello PHP';
}
public function call() {
$this-closure();
}
}
$test = new Test;
// Call Test::$closure or Test::closure() now?
$test-call();
What you need to do is to copy the instance into a variable like:
$closoure = $this-closure;
$closure();
[2009-10-29 01:15:36] marc dot gray at gmail dot com
Description:
Placing a class with an __invoke method as a property inside another
class seems to nullify the invokeability of the original class.
Tested on:
Ubuntu 9.04, PHP 5.3.0
CentOS 5.3, PHP 5.2.11 ionCube / Suhosin
Reproduce code:
---
class a {
function __construct() { }
function __invoke() { echo(Invoked\n); }
}
$a = new a();
$a();
// Prints: Invoked
class b {
private $x;
function __construct() {
$this-x = new a();
$this-x();
}
}
$b = new b();
// Issues error: undefined method b::x
Expected result:
I expect new b() construct to call the class a invoke
Actual result:
--
Undefined method - it doesn't seem to recognise the invokeable class
property as actually invokeable.
--
Edit this bug report at http://bugs.php.net/bug.php?id=50029edit=1
Bug #51187 [Com]: Segmentation fault with Zend_Form/Zend_View
Edit report at http://bugs.php.net/bug.php?id=51187edit=1 ID: 51187 Comment by: weierophin...@php.net Reported by: bostjan at a2o dot si Summary: Segmentation fault with Zend_Form/Zend_View Status: Feedback Type: Bug Package: Reproducible crash Operating System: Linux PHP Version: Irrelevant New Comment: I understand completely what's happening -- you set the value of the object to the object itself; when rendering, it then attempts to cast the value to a string, which means casting the object to a string... which means rendering the element, which will in turn need to cast the value to a string. It's indeed recursion. I can potentially put in some recursion detection in ZF; I'm not sure if the PHP team wants to investigate the segfault, however. Personally, though, I'd consider fixing the code instead, to ensure you're not overwriting the value passed to the function (which is the real error here). Previous Comments: [2010-03-03 04:54:53] ahar...@php.net You can find instructions on generating a backtrace at http://bugs.php.net/bugs- generating-backtrace.php. [2010-03-03 04:54:52] ahar...@php.net -Status: Open +Status: Feedback [2010-03-03 04:33:33] bostjan at a2o dot si It most certainly is an endless recursion, though it should only lead to memory limit error. How do I acquire a stack track? [2010-03-03 00:37:52] johan...@php.net I assume this is an endless recursion, can you please provide a stacktrack? [2010-03-03 00:37:51] johan...@php.net -Status: Open +Status: Feedback The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51187 -- Edit this bug report at http://bugs.php.net/bug.php?id=51187edit=1
#49069 [NEW]: regression in array_mulitsort()
From: weierophin...@php.net
Operating system: Ubuntu 9.04
PHP version: 5.3.0
PHP Bug Type: Arrays related
Bug description: regression in array_mulitsort()
Description:
Prior to 5.3.0, array_multisort() expected no references; the last array
provided would be assumed to be a reference, and updated by the function
during processing.
Starting in 5.3.0, array_multisort() now expects all arguments to be
passed by reference, raising a warning if it detects any are passed by
copy. This also includes the various sort flags (which simply does not make
sense, since the SORT_* constants are typically passed directly).
In the reproduce code below, if you pass all arguments by reference, you
get the expected result. However, this is a BC break from previous versions
of PHP, as you were not required to pass by reference.
An additional BC break occurs with the results: if you ignore the warning,
the results returned differ from what was returned prior to 5.3 (this is
shown below). You will only get the expected results if, again, all
arguments are passed by reference.
Reproduce code:
---
$array1 = array('foo', 'bar', 'baz');
$array2 = array('baz', 'bar', 'foo');
$array3 = array('Foo', 'Bar', 'Baz');
$sort1a = SORT_ASC;
$sort1b = SORT_STRING;
$sort2a = SORT_ASC;
$sort2b = SORT_REGULAR;
$args = array($array1, $sort1a, $sort1b, $array2, $sort2a, $sort2b,
$array3);
call_user_func_array('array_multisort', $args);
var_export($array3);
Expected result:
array (
0 = 'Bar',
1 = 'Baz',
2 = 'Foo',
)
Actual result:
--
Warning: Parameter 1 to array_multisort() expected to be a reference,
value given in /home/matthew/tmp/test.php on line 23
array (
0 = 'Foo',
1 = 'Bar',
2 = 'Baz',
)
--
Edit bug report at http://bugs.php.net/?id=49069edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49069r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49069r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49069r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49069r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49069r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49069r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49069r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49069r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49069r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49069r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49069r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49069r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49069r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49069r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49069r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49069r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49069r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49069r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49069r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49069r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49069r=mysqlcfg
#49056 [NEW]: parse_ini_file regression in 5.3.0 when using non-ASCII strings as option keys
From: weierophin...@php.net Operating system: Ubuntu 9.04 PHP version: 5.3.0 PHP Bug Type: Filesystem function related Bug description: parse_ini_file regression in 5.3.0 when using non-ASCII strings as option keys Description: In PHP versions 5.3.0, one could specify INI option keys using non-ASCII characters; parse_ini_file would find these without issue. Starting with 5.3.0, such options are silently dropped from the returned array of key/value pairs. The same is true of parse_ini_string(). I have the following extensions enabled: bz2 Core ctype curl date dom ereg fileinfo filter gd gettext hash iconv intl json libxml mhash mysql openssl pcntl pcre PDO pdo_mysql pdo_sqlite Phar posix Reflection session SimpleXML soap sockets SPL SQLite sqlite3 standard tidy tokenizer xml xmlreader xmlwriter zip zlib My php.ini is php.ini-development, with the only changes being to set my include_path and date.timezone. Reproduce code: --- $string =EOT Cooking_furniture=Küchen Möbel (en) Küchen_Möbel=Cooking furniture (en) EOT; $data = parse_ini_string($string); var_export($data); Expected result: array ( 'Cooking_furniture' = 'Küchen Möbel (en)', 'Küchen_Möbel' = 'Cooking furniture (en)', ) Actual result: -- array ( 'Cooking_furniture' = 'Küchen Möbel (en)', ) -- Edit bug report at http://bugs.php.net/?id=49056edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49056r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49056r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49056r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49056r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49056r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49056r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49056r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49056r=needscript Try newer version: http://bugs.php.net/fix.php?id=49056r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49056r=support Expected behavior: http://bugs.php.net/fix.php?id=49056r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49056r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49056r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49056r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49056r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49056r=dst IIS Stability: http://bugs.php.net/fix.php?id=49056r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49056r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49056r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49056r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49056r=mysqlcfg
