Bug #60909 [Opn-Csd]: custom error handler throwing Exception + fatal error = no shutdown function
Edit report at https://bugs.php.net/bug.php?id=60909edit=1 ID: 60909 Updated by: dmi...@php.net Reported by:tyr...@php.net Summary:custom error handler throwing Exception + fatal error = no shutdown function -Status: Open +Status: Closed Type: Bug Package:Scripting Engine problem Operating System: linux PHP Version:5.4.0RC6 -Assigned To: +Assigned To:dmitry Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. The same as #61767. Previous Comments: [2012-09-06 10:04:05] dmi...@php.net Automatic comment on behalf of dmi...@zend.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=b29dc146b9311c14186c14bcb1c8ae5288b65d73 Log: - Fixed bug #61767 (Shutdown functions not called in certain error situation) - Fixed bug #60909 (custom error handler throwing Exception + fatal error = no shutdown function) [2012-09-04 16:24:29] bis...@php.net @nikic: I can generate the same path without the first non-fatal error: -- register_shutdown_function(function(){echo(\n\n!!!shutdown!!!\n\n);}); set_error_handler(function($errno, $errstr, $errfile, $errline){throw new Exception(Foo);}); class Bad { public function __toString() { throw new Exception('Oops, I cannot do this'); } } $bad = new Bad(); echo $bad; -- This is on 5.3.10, like @jpauli report, and 5.4.6 as well. The @laruence EG(exception) = NULL patch handles this case as well. AFAIK, that patch is appropriate. [2012-04-20 00:15:50] ni...@php.net I tried adding an EG(exception) = NULL; at the start of php_request_shutdown() and it indeed fixes the issue. Though probably that's not the right way to fix this. [2012-04-19 23:40:57] ni...@php.net So, this is what I think is happening here: 1. The first non-fatal error (here warning) throws an Exception, i.e. sets EG(exception) 2. The second fatal error then causes a zend_bailout() moving us directly to php_request_shutdown() 3. During the shutdown sequence PHP will try to call the shutdown handler using call_user_function(). 4. As EG(exception) is still set, the call is not allows (see http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_execute_API.c#775). [2012-04-19 23:06:26] ni...@php.net Together with https://bugs.php.net/bug.php?id=61767 it is a bit more clear under which circumstances this occurs: 1. A non-fatal error is thrown 2. The error handler throws an Exception 3. A fatal error is thrown In this particular case: 1. require() throws an E_WARNING (Warning: require(notfound.php): failed to open stream: No such file or directory). 2. The error handler throws the Exception 3. require() throws an E_COMPILE_ERROR (Fatal error: require(): Failed opening required 'notfound.php') The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60909 -- Edit this bug report at https://bugs.php.net/bug.php?id=60909edit=1
Bug #61767 [Ana-Csd]: Shutdown functions not called in certain error situation
Edit report at https://bugs.php.net/bug.php?id=61767edit=1 ID: 61767 Updated by: dmi...@php.net Reported by:shiranai7 at hotmail dot com Summary:Shutdown functions not called in certain error situation -Status: Analyzed +Status: Closed Type: Bug Package:Scripting Engine problem Operating System: Win7 PHP Version:5.4.0 Assigned To:dmitry Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2012-09-06 10:04:04] dmi...@php.net Automatic comment on behalf of dmi...@zend.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=b29dc146b9311c14186c14bcb1c8ae5288b65d73 Log: - Fixed bug #61767 (Shutdown functions not called in certain error situation) - Fixed bug #60909 (custom error handler throwing Exception + fatal error = no shutdown function) [2012-09-05 08:20:30] dmi...@php.net I've added a patch that fixes the problem in different way. (bug61767.diff tested with 5.3 only) In case of unhanded exception and following fatal error we just emit additional warning about uncaught exception before the fatal error. This solution doesn't miss exceptions (as another_fix_for_bug61767.patch) and doesn't require significant changes in VM (as bug61767.patch) that would affect PHP performance. Please take a look. [2012-09-05 08:14:53] dmi...@php.net The following patch has been added/updated: Patch Name: bug61767.diff Revision: 1346832893 URL: https://bugs.php.net/patch-display.php?bug=61767patch=bug61767.diffrevision=1346832893 [2012-09-05 03:08:23] larue...@php.net could you please look at this? since it is in shutdown pharse, then I think it's okey to suppress the exception? thanks [2012-05-28 16:49:06] shiranai7 at hotmail dot com Still the same (unexpected) result in 5.4.3. Error handler called Fatal error: Call to a member function foo() on a non-object in ... on line ... 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 https://bugs.php.net/bug.php?id=61767 -- Edit this bug report at https://bugs.php.net/bug.php?id=61767edit=1
Bug #55038 [Com]: inconsistent error-handling for $this
Edit report at https://bugs.php.net/bug.php?id=55038edit=1 ID: 55038 Comment by: dexen dot devries at gmali dot com Reported by:rasmus at mindplay dot dk Summary:inconsistent error-handling for $this Status: Open Type: Bug Package:Class/Object related Operating System: Win7 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Note, the closure and creation of another object instance are irrelevant. Two simpler reproduction scripts -- one uses anonymous function, the other plain function. ?php $foo = function($this) { var_dump($this); // this will work! var_dump($this-bar); // this will blow up }; $foo(new stdclass); ? ?php function bar($this) { var_dump($this); // this will work! var_dump($this-bar); // this will blow up } bar(new stdclass); ? Expected result: both uses of $this and $this-bar behave in similar way. Actual result: PHP complains only on $this-bar. Previous Comments: [2011-06-12 03:53:57] rasmus at mindplay dot dk Description: $this is not generally allowed outside an object context, but sometimes it is. I discovered this while trying to write a cheeky little base-class that would allow you to decorate objects with new methods, at run-time. I would have gotten away with it, too - and I still could of course, only I would have to break from the convention of $this, and naming the context-object something else, which kind of sucks. Test script: --- ?php $foo = function($this) { var_dump($this); // this will work! }; $foo('bar'); // now an object: class Test { public $foo = 'bar'; } $test = new Test; // and another closure: $ouch = function($this) { var_dump($this-bar); // this will blow up }; $ouch($test); Expected result: The two examples should either fail consistently, or succeed consistently. From my point of view, why should I not be allowed to have a local variable named $this if I wanted to? There's nothing special or magical about this variable, besides the fact that it gets automatically assigned on call. Actual result: -- The second example fails. -- Edit this bug report at https://bugs.php.net/bug.php?id=55038edit=1
[PHP-BUG] Bug #63021 [NEW]: var_export() does not export Closures
From: dexen dot devries at gmail dot com Operating system: PHP version: 5.4.6 Package: *Programming Data Structures Bug Type: Bug Bug description:var_export() does not export Closures Description: While var_dump() produces sensible output for Closures, output of the var_export() is pretty much useless. Test script: --- ?php $a = range(1, 3); $foo = function($n) use($a) { return $a[$n]; }; var_dump($foo); var_export($foo); Expected result: object(Closure)#1 (2) { [static]= array(1) { [a]= array(3) { [0]= int(1) [1]= int(2) [2]= int(3) } } [parameter]= array(1) { [$n]= string(10) required } } (((resembling the following:))) object(Closure)#1 (2) { [static]= array(1) { [a]= array(3) { [0]= int(1) [1]= int(2) [2]= int(3) } } [parameter]= array(1) { [$n]= string(10) required } } Actual result: -- object(Closure)#1 (2) { [static]= array(1) { [a]= array(3) { [0]= int(1) [1]= int(2) [2]= int(3) } } [parameter]= array(1) { [$n]= string(10) required } } Closure::__set_state(array( )) -- Edit bug report at https://bugs.php.net/bug.php?id=63021edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63021r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63021r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63021r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63021r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=63021r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=63021r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63021r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63021r=needscript Try newer version: https://bugs.php.net/fix.php?id=63021r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=63021r=support Expected behavior: https://bugs.php.net/fix.php?id=63021r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63021r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63021r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63021r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63021r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=63021r=dst IIS Stability: https://bugs.php.net/fix.php?id=63021r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=63021r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63021r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63021r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63021r=mysqlcfg
Req #47494 [Com]: htmlspecialchars does not throw E_WARNING on multibyte problems
Edit report at https://bugs.php.net/bug.php?id=47494edit=1 ID: 47494 Comment by: lzsiga at freemail dot c3 dot hu Reported by:philipp dot feigl at gmail dot com Summary:htmlspecialchars does not throw E_WARNING on multibyte problems Status: Not a bug Type: Feature/Change Request Package:Strings related Operating System: CentOS5 PHP Version:5.2.8 Block user comment: N Private report: N New Comment: Imho htmlspecialchars should not check for multi-byte validity at all, because it only deals with a few characters that are all in ASCII7, so it could safely ignore every byte between 0x80 and 0xFF. The third parameter could be simply ignored (as if it were 'ISO-8859-1') Previous Comments: [2012-08-30 19:21:49] ni...@php.net @the disappointed user: PHP 5.4 no longer throws said warning (it was just confusing). Instead there are several new options for dealing with incorrect encoding. Of particular interest is ENT_SUBSTITUTE, which will replace invalid code unit sequences with the Unicode Replacement Character (instead of returning a rather unhelpful empty string). This way you can easily spot where the string is incorrectly encoded. Furthermore this option has the additional advantage of being more graceful (it just removed individual incorrectly encoded bytes, not the whole string). Hope this helps you. More info in the docs: http://de2.php.net/htmlspecialchars [2012-08-30 19:01:22] another_disappointed_php_programmer at exam This is very sad. This is a bug, and it's sad that PHP core developers said that it's a feature and it won't be fixed. I'm disappointed. [2012-07-01 15:34:03] ras...@php.net This really isn't a bug. I do agree that the approach isn't ideal, but we shouldn't throw warnings on bad input here because htmlspecialchars() is explicitly designed to clean up bad input and it is run directly on user data most of the time. In order for someone to avoid this warning they would need to first call something like iconv('utf-8','utf-8') to clean up the input data and that doesn't make much sense since htmlspecialchars() essentially does that already. But, in order to help debugging there should be some way to see why an htmlspecialchars() call failed so a last_error() function similar to how it is handled for json decoding would make sense. [2012-07-01 15:12:31] chris at cbsinteractive dot com Happening our production servers, can replicate, PHP 5.3.10, Centos 5.6 [2011-09-27 22:43:02] rudd-o at rudd-o dot com Reported to /r/lolphp here: http://www.reddit.com/r/lolphp/comments/kso6p/if_error_reporting_is_on_htmlspecia lchars_will/ Do you guys realize there is an ENTIRE COMMUNITY of people devoted to the collective practice of FACEPALMING at PHP's fails? Hahaha. 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 https://bugs.php.net/bug.php?id=47494 -- Edit this bug report at https://bugs.php.net/bug.php?id=47494edit=1
Bug-Req #63021 [Opn]: var_export() does not export Closures
Edit report at https://bugs.php.net/bug.php?id=63021edit=1 ID: 63021 Updated by: larue...@php.net Reported by:dexen dot devries at gmail dot com Summary:var_export() does not export Closures Status: Open -Type: Bug +Type: Feature/Change Request Package:*Programming Data Structures PHP Version:5.4.6 Block user comment: N Private report: N New Comment: closure can not be serialized.. change to feature request instead. Previous Comments: [2012-09-06 10:36:21] dexen dot devries at gmail dot com Description: While var_dump() produces sensible output for Closures, output of the var_export() is pretty much useless. Test script: --- ?php $a = range(1, 3); $foo = function($n) use($a) { return $a[$n]; }; var_dump($foo); var_export($foo); Expected result: object(Closure)#1 (2) { [static]= array(1) { [a]= array(3) { [0]= int(1) [1]= int(2) [2]= int(3) } } [parameter]= array(1) { [$n]= string(10) required } } (((resembling the following:))) object(Closure)#1 (2) { [static]= array(1) { [a]= array(3) { [0]= int(1) [1]= int(2) [2]= int(3) } } [parameter]= array(1) { [$n]= string(10) required } } Actual result: -- object(Closure)#1 (2) { [static]= array(1) { [a]= array(3) { [0]= int(1) [1]= int(2) [2]= int(3) } } [parameter]= array(1) { [$n]= string(10) required } } Closure::__set_state(array( )) -- Edit this bug report at https://bugs.php.net/bug.php?id=63021edit=1
Bug #63013 [Fbk-Csd]: Error not thrown with constructor call
Edit report at https://bugs.php.net/bug.php?id=63013edit=1 ID: 63013 User updated by:samu dot voutilainen at gmail dot com Reported by:samu dot voutilainen at gmail dot com Summary:Error not thrown with constructor call -Status: Feedback +Status: Closed Type: Bug Package:*General Issues Operating System: Linux PHP Version:5.4.6 Block user comment: N Private report: N New Comment: error_reporting = E_ALL ~E_DEPRECATED ~E_STRICT display_errors = On Looks like I accidentally didnât have only E_ALL (that should be all errors that exists, no?) Anyway, now Iâm not able to reproduce the problem even with original error_reporting, so I think it comes up randomly. I guess this one can be closed as invalid and if I manage to reproduce it, try to do proper test case. I did spot this before (no errors where shouldâve been, just immediate death), so I think there is something, but need first manage to reproduce it... Previous Comments: [2012-09-06 01:40:33] ahar...@php.net I can't reproduce this either. We'll have to wait for the new example. Can you also provide your display_errors and error_reporting settings, please? [2012-09-05 14:24:35] samu dot voutilainen at gmail dot com I donât get the warnings for the case I had; this simpler example does though. Iâll construct an example with proper namespaces to see if it causes it. [2012-09-05 13:20:23] larue...@php.net PHP will warn you: PHP Warning: Missing argument 1 for AbstractHandler::__construct(), called in /tmp/1.php on line 30 and defined in /tmp/1.php on line 18 PHP Warning: Missing argument 2 for AbstractHandler::__construct(), called in /tmp/1.php on line 30 and defined in /tmp/1.php on line 18 PHP Warning: Missing argument 3 for AbstractHandler::__construct(), called in /tmp/1.php on line 30 and defined in /tmp/1.php on line 18 [2012-09-05 10:41:20] samu dot voutilainen at gmail dot com Also the code I have uses namespaces. [2012-09-05 10:37:20] samu dot voutilainen at gmail dot com Description: When inheriting from a class and calling constructor with invalid arguments, it wonât throw any error, but die silently. There is no information in web server log or PHP-FPMâs logs and nothing is returned to client either. Test script: --- class SlamObject { } class Utility extends SlamObject { } abstract class AbstractHandler extends Utility { protected $version; protected $session; protected $output; public function __construct($session, $output, $version) { $this-session = $session; $this-output = $output; $this-version = $version; } } class Foo extends AbstractClass { } $foo = new Foo(); Expected result: At the point of Foo, fatal error is thrown telling that you called constructor with wrong arguments. Actual result: -- Silent death at this point with no information anywhere. -- Edit this bug report at https://bugs.php.net/bug.php?id=63013edit=1
Req #47494 [Nab]: htmlspecialchars does not throw E_WARNING on multibyte problems
Edit report at https://bugs.php.net/bug.php?id=47494edit=1 ID: 47494 Updated by: ras...@php.net Reported by:philipp dot feigl at gmail dot com Summary:htmlspecialchars does not throw E_WARNING on multibyte problems Status: Not a bug Type: Feature/Change Request Package:Strings related Operating System: CentOS5 PHP Version:5.2.8 Block user comment: N Private report: N New Comment: You assume ASCII7 compatibility for all encodings which is a bad assumption. Previous Comments: [2012-09-06 11:39:19] lzsiga at freemail dot c3 dot hu Imho htmlspecialchars should not check for multi-byte validity at all, because it only deals with a few characters that are all in ASCII7, so it could safely ignore every byte between 0x80 and 0xFF. The third parameter could be simply ignored (as if it were 'ISO-8859-1') [2012-08-30 19:21:49] ni...@php.net @the disappointed user: PHP 5.4 no longer throws said warning (it was just confusing). Instead there are several new options for dealing with incorrect encoding. Of particular interest is ENT_SUBSTITUTE, which will replace invalid code unit sequences with the Unicode Replacement Character (instead of returning a rather unhelpful empty string). This way you can easily spot where the string is incorrectly encoded. Furthermore this option has the additional advantage of being more graceful (it just removed individual incorrectly encoded bytes, not the whole string). Hope this helps you. More info in the docs: http://de2.php.net/htmlspecialchars [2012-08-30 19:01:22] another_disappointed_php_programmer at exam This is very sad. This is a bug, and it's sad that PHP core developers said that it's a feature and it won't be fixed. I'm disappointed. [2012-07-01 15:34:03] ras...@php.net This really isn't a bug. I do agree that the approach isn't ideal, but we shouldn't throw warnings on bad input here because htmlspecialchars() is explicitly designed to clean up bad input and it is run directly on user data most of the time. In order for someone to avoid this warning they would need to first call something like iconv('utf-8','utf-8') to clean up the input data and that doesn't make much sense since htmlspecialchars() essentially does that already. But, in order to help debugging there should be some way to see why an htmlspecialchars() call failed so a last_error() function similar to how it is handled for json decoding would make sense. [2012-07-01 15:12:31] chris at cbsinteractive dot com Happening our production servers, can replicate, PHP 5.3.10, Centos 5.6 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 https://bugs.php.net/bug.php?id=47494 -- Edit this bug report at https://bugs.php.net/bug.php?id=47494edit=1
Req #47494 [Nab]: htmlspecialchars does not throw E_WARNING on multibyte problems
Edit report at https://bugs.php.net/bug.php?id=47494edit=1 ID: 47494 Updated by: ras...@php.net Reported by:philipp dot feigl at gmail dot com Summary:htmlspecialchars does not throw E_WARNING on multibyte problems Status: Not a bug Type: Feature/Change Request Package:Strings related Operating System: CentOS5 PHP Version:5.2.8 Block user comment: N Private report: N New Comment: Also note that many, if not most, apps use this as their only validity filter and if you output invalid UTF-8, for example, it can lead to security problems like the well-known IE 0xE0 XSS exploit. So at some point along the line you have to do a multi-byte check and it may as well be here since we need to do it anyway. Previous Comments: [2012-09-06 15:29:07] ras...@php.net You assume ASCII7 compatibility for all encodings which is a bad assumption. [2012-09-06 11:39:19] lzsiga at freemail dot c3 dot hu Imho htmlspecialchars should not check for multi-byte validity at all, because it only deals with a few characters that are all in ASCII7, so it could safely ignore every byte between 0x80 and 0xFF. The third parameter could be simply ignored (as if it were 'ISO-8859-1') [2012-08-30 19:21:49] ni...@php.net @the disappointed user: PHP 5.4 no longer throws said warning (it was just confusing). Instead there are several new options for dealing with incorrect encoding. Of particular interest is ENT_SUBSTITUTE, which will replace invalid code unit sequences with the Unicode Replacement Character (instead of returning a rather unhelpful empty string). This way you can easily spot where the string is incorrectly encoded. Furthermore this option has the additional advantage of being more graceful (it just removed individual incorrectly encoded bytes, not the whole string). Hope this helps you. More info in the docs: http://de2.php.net/htmlspecialchars [2012-08-30 19:01:22] another_disappointed_php_programmer at exam This is very sad. This is a bug, and it's sad that PHP core developers said that it's a feature and it won't be fixed. I'm disappointed. [2012-07-01 15:34:03] ras...@php.net This really isn't a bug. I do agree that the approach isn't ideal, but we shouldn't throw warnings on bad input here because htmlspecialchars() is explicitly designed to clean up bad input and it is run directly on user data most of the time. In order for someone to avoid this warning they would need to first call something like iconv('utf-8','utf-8') to clean up the input data and that doesn't make much sense since htmlspecialchars() essentially does that already. But, in order to help debugging there should be some way to see why an htmlspecialchars() call failed so a last_error() function similar to how it is handled for json decoding would make sense. 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 https://bugs.php.net/bug.php?id=47494 -- Edit this bug report at https://bugs.php.net/bug.php?id=47494edit=1
Req #62341 [Com]: htmlspecialchars() should work on ascii compatible encodings by default.
Edit report at https://bugs.php.net/bug.php?id=62341edit=1 ID: 62341 Comment by: andreas dot rieber at t-online dot de Reported by:bfanger at gmail dot com Summary:htmlspecialchars() should work on ascii compatible encodings by default. Status: Open Type: Feature/Change Request Package:*Unicode Issues PHP Version:5.4.4 Block user comment: N Private report: N New Comment: I also spotted that problem on an older iso-8859-1 application. I could now convert the database to utf-8 or change ca. 150 places in the old code. Then i checked the problem a bit closer: it is user input, so we don't really know what charset it is. We can only assume it is the charset we published the page in. That might be wrong but with the new htmlspecialchars behavior we would show nothing instead of partly wrong input. I made some tests and it looks like best is to change my code (even for applications which use utf-8) to: htmlspecialchars( $text, 0, iso-8859-1); There must be a better way... To return nothing is not really good. Previous Comments: [2012-07-03 19:39:32] Bonefish26 at aol dot com Everything is fine with htmlspecialcahrs until someone copies data from their auto formatted ms word document and puts it in the update box. Setting the charset option seems to solve the problem. [2012-06-18 14:26:23] ras...@php.net EUC-JP is heavily used, supported by htmlspecialchars and it is not ASCII compatible. [2012-06-17 17:47:34] bfanger at gmail dot com Rereading the manpage more thoroughly, all the info is there. Another nice resource is http://nikic.github.com/2012/01/28/htmlspecialchars-improvements-in- PHP-5-4.html I now disagree with the decision of the empty string, with php flexible typing this should have been false or null. In php5.4 no longer has the weird 'only errors when display_errors is off behavior', but sadly the chosen behaviour is to alway silently supress those errors. If throwing E_WARING is too risky, an E_ENCODING error level would be very welcome addition. ENT_IGNORE: Removes special characters from the string instead of ignoring them. (My previous statement unless ENT_IGNORE is passed. is therefor invalid) Using strtr($text, array('' = 'lt;', '' = 'gt;', '' = 'amp;')); is 35% slower than htmlspecialchars($text, ENT_NOQUOTES, 'ISO-8859-1') which has the same output. The securityrisk applies only to multibyte encoding which always uses 2 or more bytes per characters, like UTF-16 (but UTF-16 and UTF-32 aren't supported by htmlspecialchars, i'm not sure if any of the supported charsets is incompatible with ascii) My framework uses UTF-8 for 95% percent of the time, but to prevent silent trucating i'll have to add 'ISO-8859-1' as encoding. It just feels wrong. The default charset for htmlspecialchars should be ASCII compatible the encodings ISO-8859-1, ISO-8859-15, UTF-8, cp866, cp1251, cp1252, and KOI8-R are effectively equivalent no ifs, no buts. [2012-06-17 10:25:58] bfanger at gmail dot com Updated summary to Secure behavior htmlspecialchars() not reflected in the documentation My initial change request htmlspecialchars() should work on ascii compatible encodings by default no longer applies. After some research agree with the new behavior. [2012-06-17 10:06:34] bfanger at gmail dot com Description: In PHP 5.4 the default encoding for htmlentities is changed to 'UTF-8', When a ISO-8859-1 encoded string with a special character is passed to the htmlspecialchars() it returns an empty string (invalid mutlibyte sequence) This is the new intended (and more secure) behavior, and i agree, but... The old default (ISO-8859-1) worked on both UTF-8, ISO-8859-1 and other ascii compatible encodings, which is reflected in the documentation: Calling htmlspecialchars() is sufficient if the encoding supports all characters in the input string (such us UTF-8 but also ISO-8859-1 on ISO-8859-1 only input). htmlentities() needs to be called only if the output encoding doesn't support all characters in the input string. This is no longer the case, unless ENT_IGNORE is passed. Solution: Drop the paragraph from the documentation. PS: You might wan't to add a paragraph that incorrect encoded text will cause htmlspecialschars() to return an empty string. -- Edit this bug report at https://bugs.php.net/bug.php?id=62341edit=1
Req #62341 [Opn]: htmlspecialchars() should work on ascii compatible encodings by default.
Edit report at https://bugs.php.net/bug.php?id=62341edit=1 ID: 62341 Updated by: ras...@php.net Reported by:bfanger at gmail dot com Summary:htmlspecialchars() should work on ascii compatible encodings by default. Status: Open Type: Feature/Change Request Package:*Unicode Issues PHP Version:5.4.4 Block user comment: N Private report: N New Comment: The problem with setting it to 8859-1 is that it lets everything through. If your page is actually in UTF-8 it means you are now vulnerable to 0xE0 XSS invalid UTF-8 style attacks. In PHP 5.4 we have addressed this by adding an ENT_SUBSTITUTE option that lets you substitute any invalid chars instead of returning an empty string. Previous Comments: [2012-09-06 15:36:43] andreas dot rieber at t-online dot de I also spotted that problem on an older iso-8859-1 application. I could now convert the database to utf-8 or change ca. 150 places in the old code. Then i checked the problem a bit closer: it is user input, so we don't really know what charset it is. We can only assume it is the charset we published the page in. That might be wrong but with the new htmlspecialchars behavior we would show nothing instead of partly wrong input. I made some tests and it looks like best is to change my code (even for applications which use utf-8) to: htmlspecialchars( $text, 0, iso-8859-1); There must be a better way... To return nothing is not really good. [2012-07-03 19:39:32] Bonefish26 at aol dot com Everything is fine with htmlspecialcahrs until someone copies data from their auto formatted ms word document and puts it in the update box. Setting the charset option seems to solve the problem. [2012-06-18 14:26:23] ras...@php.net EUC-JP is heavily used, supported by htmlspecialchars and it is not ASCII compatible. [2012-06-17 17:47:34] bfanger at gmail dot com Rereading the manpage more thoroughly, all the info is there. Another nice resource is http://nikic.github.com/2012/01/28/htmlspecialchars-improvements-in- PHP-5-4.html I now disagree with the decision of the empty string, with php flexible typing this should have been false or null. In php5.4 no longer has the weird 'only errors when display_errors is off behavior', but sadly the chosen behaviour is to alway silently supress those errors. If throwing E_WARING is too risky, an E_ENCODING error level would be very welcome addition. ENT_IGNORE: Removes special characters from the string instead of ignoring them. (My previous statement unless ENT_IGNORE is passed. is therefor invalid) Using strtr($text, array('' = 'lt;', '' = 'gt;', '' = 'amp;')); is 35% slower than htmlspecialchars($text, ENT_NOQUOTES, 'ISO-8859-1') which has the same output. The securityrisk applies only to multibyte encoding which always uses 2 or more bytes per characters, like UTF-16 (but UTF-16 and UTF-32 aren't supported by htmlspecialchars, i'm not sure if any of the supported charsets is incompatible with ascii) My framework uses UTF-8 for 95% percent of the time, but to prevent silent trucating i'll have to add 'ISO-8859-1' as encoding. It just feels wrong. The default charset for htmlspecialchars should be ASCII compatible the encodings ISO-8859-1, ISO-8859-15, UTF-8, cp866, cp1251, cp1252, and KOI8-R are effectively equivalent no ifs, no buts. [2012-06-17 10:25:58] bfanger at gmail dot com Updated summary to Secure behavior htmlspecialchars() not reflected in the documentation My initial change request htmlspecialchars() should work on ascii compatible encodings by default no longer applies. After some research agree with the new behavior. 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 https://bugs.php.net/bug.php?id=62341 -- Edit this bug report at https://bugs.php.net/bug.php?id=62341edit=1
Req #28261 [Com]: Lifting reserved keyword restriction for method names
Edit report at https://bugs.php.net/bug.php?id=28261edit=1 ID: 28261 Comment by: rayro at gmx dot de Reported by:Philippe dot Jausions at 11abacus dot com Summary:Lifting reserved keyword restriction for method names Status: Open Type: Feature/Change Request Package:Scripting Engine problem Operating System: * PHP Version:* Block user comment: N Private report: N New Comment: It would be nice to see this in future releases! Previous Comments: [2011-08-08 16:13:17] steven_nikkel at ertyu dot org Would this prevent the keyword eval from being used within code being eval'd? That appears to be the bug I'm running into, even though the keyword is only used in contained javascript code, not php, even included as a comment it fails. [2011-07-26 15:56:42] info at strictcoding dot co dot uk +1 for this feature request! [2011-07-10 19:47:43] s...@php.net The patch seems not to work with tokenizer extension - the extension returns wrong tokens (T_EVAL instead of expected T_STRING). [2009-06-30 05:52:23] taufiq at krimnet dot com I need this bug to be resolved. I'm writing Javascript/CSS collector minify library. I would like to code like below. JS::include(FILE_PATH)-include(FILE_PATH2)-include(FILE_PATH3); having method name other than include() is pretty annoying. [2007-12-16 00:46:09] kentfredric at gmail dot com At the moment (5.2.3 ) this is perfectly valid. Class A{ function __call( $function, $args ){ if( $function == 'print' ){ print MyPrint: {$args[0]}; } } } $a = new A(); $a-print( hello ); #-- surprisingly, this is not an invalid use of a keyword to the lexer. # MyPrint: hello but this Class A{ function print( $args ){ print MyPrint: {$args}; } } $a = new A(); $a-print( hello ); Yields a parse error Parse error: syntax error, unexpected T_PRINT, expecting T_STRING which appears to be an illogical design contstraint. I've seen rather brutal slander for people attempting to perform this ( #14178 , this bug ) amounting to hey, you suck, dont do that without any rational explanation. So yes, I look forward to this feature being integrated. 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 https://bugs.php.net/bug.php?id=28261 -- Edit this bug report at https://bugs.php.net/bug.php?id=28261edit=1
Bug #46408 [Com]: Locale number format settings can cause pg_query_params to break with numerics
Edit report at https://bugs.php.net/bug.php?id=46408edit=1 ID: 46408 Comment by: alec at smecher dot bc dot ca Reported by:alec at smecher dot bc dot ca Summary:Locale number format settings can cause pg_query_params to break with numerics Status: Wont fix Type: Bug Package:PostgreSQL related Operating System: * PHP Version:5.*, 6 Assigned To:yohgaki Block user comment: N Private report: N New Comment: I suggest this patch. diff -u -r php-5.4.6/ext/pgsql/pgsql.c php-5.4.6-mod/ext/pgsql/pgsql.c --- php-5.4.6/ext/pgsql/pgsql.c 2012-08-14 21:26:05.0 -0700 +++ php-5.4.6-mod/ext/pgsql/pgsql.c 2012-09-06 10:59:45.0 -0700 @@ -23,6 +23,7 @@ /* $Id$ */ #include stdlib.h +#include locale.h #define PHP_PGSQL_PRIVATE 1 @@ -1736,7 +1737,15 @@ } else { zval tmp_val = **tmp; zval_copy_ctor(tmp_val); + + // PSQL requires . for radix; convert to string, + // avoiding problems with doubles and locales + // using , as a radix character instead + // (see https://bugs.php.net/bug.php?id=46408) + char *current_locale = setlocale(LC_NUMERIC, C); convert_to_string(tmp_val); + setlocale(LC_NUMERIC, current_locale); + if (Z_TYPE(tmp_val) != IS_STRING) { php_error_docref(NULL TSRMLS_CC, E_WARNING,Error converting parameter); zval_dtor(tmp_val); Previous Comments: [2012-04-18 12:44:31] claude dot pache at gmail dot com @yohgaki (and others) I think that, the root of the problem is the way PHP uses the locale information, which I consider deeply broken. Here are the details: In my understanding, the locale information is useful only for *output*, i.e. for messages destined to the user. They should not be used for any internal conversion from one type to the other, unless the result is destined to output. The problem is, that PHP uses the locale for any automatic conversion from number to string. This behaviour is ok in the following case: echo Three and a half is: . $number; However, in the following cases, this is NOT correct, because the resulting string must not be localised: * constructing a JSON object (I hope that json_encode() does NOT use internal number-to-string conversion); * using bcmath package (I have personnaly be bitten by this misfeature); * construct a SQL request (the present case); * etc. In all these cases, you have to do one of the following options: (1) never use any locale other than en_US (and re-implement manually the locale feature); (2) carefully check the type of each and every parameter and explicitely perform a correct conversion when needed, e.g. using number_format(..., '.', ''); (3) fix PHP to NOT use locale for number-to-string conversion unless it is explicitely asked for (side note: historically, there has been a similar problem with the magic quote misfeature); (4) modify the modules bcmath, postgresql, etc, so that they circumvent the mentionned PHP misfeature, i.e., they do the option (2) above at your place. In my dreams, the option (3) would be implemented, but pragmatically, I think that option (4) has more chance to be implemented rapidly, if ever. I think that alec asked precisely the option (4) to be implemented. (Personnally, I have opted for option (1).) Claude P.S. The option (4) might seem a non-optimal hack. However, do not forget that programming languages and API should be adapted to the needs of the programmers, and not the other way round. [2012-04-18 03:13:12] yohg...@php.net You misunderstand how libpq/PostgreSQL works. If you think you can make proper patch for this, clone git source and send pull request. No one will stop you from that. [2012-04-18 02:58:26] alec at smecher dot bc dot ca I believe pg_query_params is broken until this is resolved, but it looks like we're not going to agree on it. I hope someone else can speak up if they do think this is a bug. Since we disagree on the approach any patch I write to correct it will be rejected. I'll add a comment to the manual page for pg_query_params to document this. [2012-04-18 02:26:48] yohg...@php.net BTW, you are reading
Bug #46408 [Com]: Locale number format settings can cause pg_query_params to break with numerics
Edit report at https://bugs.php.net/bug.php?id=46408edit=1 ID: 46408 Comment by: alec at smecher dot bc dot ca Reported by:alec at smecher dot bc dot ca Summary:Locale number format settings can cause pg_query_params to break with numerics Status: Wont fix Type: Bug Package:PostgreSQL related Operating System: * PHP Version:5.*, 6 Assigned To:yohgaki Block user comment: N Private report: N New Comment: Pull request filed at https://github.com/php/php-src/pull/186 Previous Comments: [2012-09-06 18:03:28] alec at smecher dot bc dot ca I suggest this patch. diff -u -r php-5.4.6/ext/pgsql/pgsql.c php-5.4.6-mod/ext/pgsql/pgsql.c --- php-5.4.6/ext/pgsql/pgsql.c 2012-08-14 21:26:05.0 -0700 +++ php-5.4.6-mod/ext/pgsql/pgsql.c 2012-09-06 10:59:45.0 -0700 @@ -23,6 +23,7 @@ /* $Id$ */ #include stdlib.h +#include locale.h #define PHP_PGSQL_PRIVATE 1 @@ -1736,7 +1737,15 @@ } else { zval tmp_val = **tmp; zval_copy_ctor(tmp_val); + + // PSQL requires . for radix; convert to string, + // avoiding problems with doubles and locales + // using , as a radix character instead + // (see https://bugs.php.net/bug.php?id=46408) + char *current_locale = setlocale(LC_NUMERIC, C); convert_to_string(tmp_val); + setlocale(LC_NUMERIC, current_locale); + if (Z_TYPE(tmp_val) != IS_STRING) { php_error_docref(NULL TSRMLS_CC, E_WARNING,Error converting parameter); zval_dtor(tmp_val); [2012-04-18 12:44:31] claude dot pache at gmail dot com @yohgaki (and others) I think that, the root of the problem is the way PHP uses the locale information, which I consider deeply broken. Here are the details: In my understanding, the locale information is useful only for *output*, i.e. for messages destined to the user. They should not be used for any internal conversion from one type to the other, unless the result is destined to output. The problem is, that PHP uses the locale for any automatic conversion from number to string. This behaviour is ok in the following case: echo Three and a half is: . $number; However, in the following cases, this is NOT correct, because the resulting string must not be localised: * constructing a JSON object (I hope that json_encode() does NOT use internal number-to-string conversion); * using bcmath package (I have personnaly be bitten by this misfeature); * construct a SQL request (the present case); * etc. In all these cases, you have to do one of the following options: (1) never use any locale other than en_US (and re-implement manually the locale feature); (2) carefully check the type of each and every parameter and explicitely perform a correct conversion when needed, e.g. using number_format(..., '.', ''); (3) fix PHP to NOT use locale for number-to-string conversion unless it is explicitely asked for (side note: historically, there has been a similar problem with the magic quote misfeature); (4) modify the modules bcmath, postgresql, etc, so that they circumvent the mentionned PHP misfeature, i.e., they do the option (2) above at your place. In my dreams, the option (3) would be implemented, but pragmatically, I think that option (4) has more chance to be implemented rapidly, if ever. I think that alec asked precisely the option (4) to be implemented. (Personnally, I have opted for option (1).) Claude P.S. The option (4) might seem a non-optimal hack. However, do not forget that programming languages and API should be adapted to the needs of the programmers, and not the other way round. [2012-04-18 03:13:12] yohg...@php.net You misunderstand how libpq/PostgreSQL works. If you think you can make proper patch for this, clone git source and send pull request. No one will stop you from that. [2012-04-18 02:58:26] alec at smecher dot bc dot ca I believe pg_query_params is broken until this is resolved, but it looks like we're not going to agree on it. I hope someone else can speak up if they do think this is a bug. Since we disagree on the approach any patch I write to correct it will be rejected. I'll add a comment to the
[PHP-BUG] Bug #63023 [NEW]: modulus problem
From: steven dot edward dot m at gmail dot com Operating system: windows PHP version: 5.3.16 Package: *General Issues Bug Type: Bug Bug description:modulus problem Description: Modulus return wrong result when: 2166896650%10 = -1280706462 what was the problem, is there any way to get the correct answer? Expected result: expected result was: 166896650 -- Edit bug report at https://bugs.php.net/bug.php?id=63023edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63023r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63023r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63023r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63023r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=63023r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=63023r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63023r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63023r=needscript Try newer version: https://bugs.php.net/fix.php?id=63023r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=63023r=support Expected behavior: https://bugs.php.net/fix.php?id=63023r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63023r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63023r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63023r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63023r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=63023r=dst IIS Stability: https://bugs.php.net/fix.php?id=63023r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=63023r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63023r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63023r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63023r=mysqlcfg
Bug #63023 [Opn-Nab]: modulus problem
Edit report at https://bugs.php.net/bug.php?id=63023edit=1 ID: 63023 Updated by: ras...@php.net Reported by:steven dot edward dot m at gmail dot com Summary:modulus problem -Status: Open +Status: Not a bug Type: Bug Package:*General Issues Operating System: windows PHP Version:5.3.16 Block user comment: N Private report: N New Comment: You are overflowing your 32-bit int limit on Windows. Move to 64-bit Linux or use bcmod(). eg. php echo bcmod('2166896650','10'); 166896650 Previous Comments: [2012-09-06 20:10:29] steven dot edward dot m at gmail dot com Description: Modulus return wrong result when: 2166896650%10 = -1280706462 what was the problem, is there any way to get the correct answer? Expected result: expected result was: 166896650 -- Edit this bug report at https://bugs.php.net/bug.php?id=63023edit=1
[PHP-BUG] Bug #63025 [NEW]: Method in trait not called when called as __constructor() argument
From: hinikato at mail dot ru Operating system: Windows 7 x64 PHP version: 5.4.6 Package: Scripting Engine problem Bug Type: Bug Bug description:Method in trait not called when called as __constructor() argument Description: Please see the code below. If I try move the $this-getSomething() to var: $tmp = $this-getSomething(); return new Bar($tmp); it works as expected, however it does not work as shown below. Test script: --- class Foo { use TFoo; function test() { $this-getFromTrait(); } } class Bar { function some() { die(__METHOD__); } } trait TFoo { function getFromTrait() { return new Bar($this-getSomething()); } function getSomething() { // Must be called!!! die(__METHOD__); } } (new Foo())-test(); Expected result: THe TFoo::getSomething() should be called. Actual result: -- The TFoo::getSomething()not called. -- Edit bug report at https://bugs.php.net/bug.php?id=63025edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63025r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63025r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63025r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63025r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=63025r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=63025r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63025r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63025r=needscript Try newer version: https://bugs.php.net/fix.php?id=63025r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=63025r=support Expected behavior: https://bugs.php.net/fix.php?id=63025r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63025r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63025r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63025r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63025r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=63025r=dst IIS Stability: https://bugs.php.net/fix.php?id=63025r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=63025r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63025r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63025r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63025r=mysqlcfg
[PHP-BUG] Bug #63026 [NEW]: require_once error
From: ian dot xspace at yahoo dot cn Operating system: windows 7 PHP version: 5.3.16 Package: *Compile Issues Bug Type: Bug Bug description:require_once error Description: ?php //OS: win7 php:5.3.16 mysql:5.5 //such as [Some code snippets] //Assume WEB_ROOT = 'E:/www'; define('WEB_ROOT', strtr(dirname(__FILE__), '\\', '/')); //define the web system directory define('TEMP', WEB_ROOT.DS.'temp'); define('LIBS', WEB_ROOT.DS.'libs'); define('VIEWS', WEB_ROOT.DS.'views'); define('LOGS', VIEWS.DS.'logs'); define('DYN', VIEWS.DS.'dynamic'); define('HLP', WEB_ROOT.DS.'helpers'); define('PLNS', WEB_ROOT.DS.'plugins'); define('CONFS', WEB_ROOT.DS.'configs'); define('MODELS', WEB_ROOT.DS.'models'); define('CTRLS', WEB_ROOT.DS.'controls'); //define associate /*Error writing */ class SYS { private function sysModule() { return array( 'M'='MODELS', 'V'='VIEWS', 'C'='CTRLS', 'L'='LIBS', 'P'='PLNS', 'H'='HLP' ); } public static function getSys($fun) { return self::$fun(); } } //common.php load some calss file //Assume $type = 'M.className'; function loadSomeClass($type) { $csName = substr($cs, 2); $type = strtoupper(strtok($cs, '.')); $moArr = SYS::getSys('sysModule'); //find module require_once($moArr[$type].DS.{$csName}.php); } //bugs: In accordance with the above wording some successful and some can not successfully ? /* private function sysModule() { return array( 'M'=MODELS, 'V'=VIEWS, 'C'=CTRLS, 'L'=LIBS, 'P'=PLNS, 'H'=HLP ); } */ ? Test script: --- ?php //OS: win7 php:5.3.16 mysql:5.5 //such as [Some code snippets] //Assume WEB_ROOT = 'E:/www'; define('WEB_ROOT', strtr(dirname(__FILE__), '\\', '/')); //define the web system directory define('TEMP', WEB_ROOT.DS.'temp'); define('LIBS', WEB_ROOT.DS.'libs'); define('VIEWS', WEB_ROOT.DS.'views'); define('LOGS', VIEWS.DS.'logs'); define('DYN', VIEWS.DS.'dynamic'); define('HLP', WEB_ROOT.DS.'helpers'); define('PLNS', WEB_ROOT.DS.'plugins'); define('CONFS', WEB_ROOT.DS.'configs'); define('MODELS', WEB_ROOT.DS.'models'); define('CTRLS', WEB_ROOT.DS.'controls'); //define associate /*Error writing */ class SYS { private function sysModule() { return array( 'M'='MODELS', 'V'='VIEWS', 'C'='CTRLS', 'L'='LIBS', 'P'='PLNS', 'H'='HLP' ); } public static function getSys($fun) { return self::$fun(); } } //common.php load some calss file //Assume $type = 'M.className'; function loadSomeClass($type) { $csName = substr($cs, 2); $type = strtoupper(strtok($cs, '.')); $moArr = SYS::getSys('sysModule'); //find module require_once($moArr[$type].DS.{$csName}.php); } //bugs: In accordance with the above wording some successful and some can not successfully ? /* private function sysModule() { return array( 'M'=MODELS, 'V'=VIEWS, 'C'=CTRLS, 'L'=LIBS, 'P'=PLNS, 'H'=HLP ); } */ ? Expected result: private function sysModule() { return array( 'M'='MODELS', 'V'='VIEWS', 'C'='CTRLS', 'L'='LIBS', 'P'='PLNS', 'H'='HLP' ); } error writing! why require_once some successful and some error -- Edit bug report at https://bugs.php.net/bug.php?id=63026edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63026r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63026r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63026r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63026r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=63026r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=63026r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63026r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63026r=needscript Try newer version: https://bugs.php.net/fix.php?id=63026r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=63026r=support Expected
Bug #63025 [Com]: Method in trait not called when called as __constructor() argument
Edit report at https://bugs.php.net/bug.php?id=63025edit=1 ID: 63025 Comment by: reeze dot xia at gmail dot com Reported by:hinikato at mail dot ru Summary:Method in trait not called when called as __constructor() argument Status: Open Type: Bug Package:Scripting Engine problem Operating System: Windows 7 x64 PHP Version:5.4.6 Block user comment: N Private report: N New Comment: There is nothing to do with trait. look http://3v4l.org/eOVRJ class A { /* no constructor public function __construct() {} */ } class B { public function __construct() { die(DIE ME!); } } $a = new A(new B()); // output nothing. it didn't die with DIE ME! since class A didn't have any constructor, so the construct params will not executed the same as: if (false $it-iWillNotBeExecuted()) { // } I thought this is a document problem :) Previous Comments: [2012-09-07 05:20:18] hinikato at mail dot ru Description: Please see the code below. If I try move the $this-getSomething() to var: $tmp = $this-getSomething(); return new Bar($tmp); it works as expected, however it does not work as shown below. Test script: --- class Foo { use TFoo; function test() { $this-getFromTrait(); } } class Bar { function some() { die(__METHOD__); } } trait TFoo { function getFromTrait() { return new Bar($this-getSomething()); } function getSomething() { // Must be called!!! die(__METHOD__); } } (new Foo())-test(); Expected result: THe TFoo::getSomething() should be called. Actual result: -- The TFoo::getSomething()not called. -- Edit this bug report at https://bugs.php.net/bug.php?id=63025edit=1