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
