Bug #64793 [Com]: finfo_open raises warning with env magic file
Edit report at https://bugs.php.net/bug.php?id=64793&edit=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=64793&edit=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=64793&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64793&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64793&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64793&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64793&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64793&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64793&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64793&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64793&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64793&r=support Expected behavior: https://bugs.php.net/fix.php?id=64793&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64793&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64793&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64793&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64793&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64793&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64793&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64793&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64793&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64793&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64793&r=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=60322&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60322&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60322&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60322&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60322&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60322&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60322&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60322&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60322&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60322&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60322&r=support Expected behavior: https://bugs.php.net/fix.php?id=60322&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60322&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60322&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60322&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60322&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60322&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60322&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60322&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60322&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60322&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60322&r=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=60321&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60321&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60321&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60321&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60321&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60321&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60321&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60321&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60321&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60321&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60321&r=support Expected behavior: https://bugs.php.net/fix.php?id=60321&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60321&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60321&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60321&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60321&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60321&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60321&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60321&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60321&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60321&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60321&r=mysqlcfg
Bug #48795 [Com]: Building intl 64-bit fails on OS X
Edit report at https://bugs.php.net/bug.php?id=48795&edit=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
[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=53710&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53710&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53710&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53710&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53710&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53710&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53710&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53710&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53710&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53710&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53710&r=support Expected behavior: http://bugs.php.net/fix.php?id=53710&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53710&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53710&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53710&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53710&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53710&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53710&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53710&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53710&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53710&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53710&r=mysqlcfg
Bug #51527 [Com]: is_callable() returning true for non-static callbacks
Edit report at http://bugs.php.net/bug.php?id=51527&edit=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=51527&edit=1
Bug #51527 [Com]: is_callable() returning true for non-static callbacks
Edit report at http://bugs.php.net/bug.php?id=51527&edit=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=51527&edit=1
[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=51527&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51527&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51527&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51527&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51527&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51527&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51527&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51527&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51527&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51527&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51527&r=support Expected behavior: http://bugs.php.net/fix.php?id=51527&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51527&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51527&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51527&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51527&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51527&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51527&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51527&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51527&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51527&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51527&r=mysqlcfg
Req #50029 [Com]: Weird invoke issue on class as property
Edit report at http://bugs.php.net/bug.php?id=50029&edit=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=50029&edit=1
Bug #51187 [Com]: Segmentation fault with Zend_Form/Zend_View
Edit report at http://bugs.php.net/bug.php?id=51187&edit=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=51187&edit=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=49069&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49069&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49069&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49069&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49069&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49069&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49069&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49069&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49069&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49069&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49069&r=support Expected behavior: http://bugs.php.net/fix.php?id=49069&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49069&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49069&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49069&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49069&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49069&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49069&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49069&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49069&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49069&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49069&r=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 =<< '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=49056&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49056&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49056&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49056&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49056&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49056&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49056&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49056&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49056&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49056&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49056&r=support Expected behavior: http://bugs.php.net/fix.php?id=49056&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49056&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49056&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49056&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49056&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49056&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49056&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49056&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49056&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49056&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49056&r=mysqlcfg