[PHP-BUG] Bug #65657 [NEW]: DatePeriod doesn't accept valid ISO-8601 formats (timezone problem)
From: glavic at gmail dot com Operating system: ALL PHP version: Irrelevant Package: Date/time related Bug Type: Bug Bug description:DatePeriod doesn't accept valid ISO-8601 formats (timezone problem) Description: The ISO-8601 states the following: The offset from UTC is given in the format ±[hh]:[mm], ±[hh][mm], or ±[hh].. But DatePeriod accepts only $iso formats that are in UTC (flag Z). See test script. I have tried all possible combinations to set timezone correctly, but no success: http://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators Test script: --- ?php $iso = 'R2/2013-09-09T12:00:15Z/P1D'; $periods = new DatePeriod($iso); var_dump( is_object($periods) ); $iso = 'R2/2013-09-09T12:00:15+02:00/P1D'; $periods = new DatePeriod($iso); var_dump( is_object($periods) ); Run this on multiple PHP versions: http://3v4l.org/b4n9j Expected result: bool(true) bool(true) # with correct offset ofc Actual result: -- bool(true) Fatal error: Uncaught exception 'Exception' with message 'DatePeriod::__construct(): Unknown or bad format (R2/2013-09-09T12:00:15+02:00/P1D)' in ... -- Edit bug report at https://bugs.php.net/bug.php?id=65657edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65657r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65657r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65657r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65657r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65657r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65657r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65657r=needscript Try newer version: https://bugs.php.net/fix.php?id=65657r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65657r=support Expected behavior: https://bugs.php.net/fix.php?id=65657r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65657r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65657r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65657r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65657r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65657r=dst IIS Stability: https://bugs.php.net/fix.php?id=65657r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65657r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65657r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65657r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65657r=mysqlcfg
Bug #65548 [Opn-Csd]: Comparison for DateTimeImmutable doesn't work
Edit report at https://bugs.php.net/bug.php?id=65548edit=1
ID: 65548
Updated by: ni...@php.net
Reported by:mail at roland-ramthun dot de
Summary:Comparison for DateTimeImmutable doesn't work
-Status: Open
+Status: Closed
Type: Bug
Package:Date/time related
Operating System: Linux
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of bsitnikov...@sugarcrm.com
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=d7f5f1ef35c32d6943cd76a3c51752e8d64c5e5e
Log: Fix bug #65548: Comparison for DateTimeImmutable doesn't work
Previous Comments:
[2013-08-27 23:44:59] cmbecker69 at gmx dot de
It seems that the comparison operators are not overloaded for
DateTimeImmutable objects. Apparently they show the same behavior
as for arbitrary user defined classes.
If my assumption is correct, instead of adding a special treatment
for the comparison operators wrt. DateTimeImmutable objects, it
might be considered to add a magic method __compare(). However,
I'm not sure, if this fits well with type juggling.
[2013-08-25 14:03:21] mail at roland-ramthun dot de
Description:
Comparison for DateTimeImmutable doesn't work. The same example with DateTime
objects works.
Test script:
---
$a = new DateTimeImmutable('today');
$b = new DateTimeImmutable('tomorrow');
if ($a $b) {
print(yay);
}
Expected result:
yay
Actual result:
--
no output
--
Edit this bug report at https://bugs.php.net/bug.php?id=65548edit=1
Bug #64851 [Asn-Csd]: DateTimeImmutable::createFromFormat() returns DateTime
Edit report at https://bugs.php.net/bug.php?id=64851edit=1
ID: 64851
Updated by: ni...@php.net
Reported by:vr...@php.net
Summary:DateTimeImmutable::createFromFormat() returns
DateTime
-Status: Assigned
+Status: Closed
Type: Bug
Package:Date/time related
Operating System: Any
PHP Version:5.5.0RC1
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
Fixed by
https://github.com/php/php-src/commit/165f544ae9a3ac674a533a45ad8a8d5dccfa2536.
Previous Comments:
[2013-05-15 23:01:34] vr...@php.net
Derick, can you please take a look?
[2013-05-15 23:01:19] vr...@php.net
Description:
It should return DateTimeImmutable.
Test script:
---
?php
echo get_class(DateTimeImmutable::createFromFormat('j-M-Y', '15-Feb-2009'));
?
Expected result:
DateTimeImmutable
Actual result:
--
DateTime
--
Edit this bug report at https://bugs.php.net/bug.php?id=64851edit=1
Bug #65502 [Opn-Csd]: DateTimeImmutable::createFromFormat returns DateTime
Edit report at https://bugs.php.net/bug.php?id=65502edit=1
ID: 65502
Updated by: ni...@php.net
Reported by:carlos at encore-lab dot com
Summary:DateTimeImmutable::createFromFormat returns DateTime
-Status: Open
+Status: Closed
Type: Bug
Package:Date/time related
Operating System: CentOS 6.4 i386
PHP Version:5.5.2
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of bsitnikov...@sugarcrm.com
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=165f544ae9a3ac674a533a45ad8a8d5dccfa2536
Log: Fix bug #65502: DateTimeImmutable::createFromFormat returns DateTime
Previous Comments:
[2013-08-22 11:27:15] carlos at encore-lab dot com
Description:
---
From manual page: http://www.php.net/datetimeimmutable.createfromformat
---
According to the manual (and the common sense also),
DateTimeImmutable::createFromFormat should return a DateTimeImmutable object,
but
instead of that it returns a DateTime one.
Test script:
---
I've used the CLI console to test it:
php $today = DateTimeImmutable::createFromFormat('Y-m-d|', '2013-08-22');
php $tomorrow = $today-add(new DateInterval('P1D'));
php var_dump($today-format('Y-m-d'), $tomorrow-format('Y-m-d'));
string(10) 2013-08-23
string(10) 2013-08-23
php var_dump($today instanceof DateTimeImmutable);
bool(false)
php var_dump($today instanceof DateTime);
bool(true)
Expected result:
$today must contain a DateTimeImmutable object and thus it must be immutable.
Actual result:
--
$today is a DateTime object instead of DateTimeImmutable
--
Edit this bug report at https://bugs.php.net/bug.php?id=65502edit=1
Req #31564 [Opn-Wfx]: Secure Password Storage
Edit report at https://bugs.php.net/bug.php?id=31564edit=1 ID: 31564 Updated by: ni...@php.net Reported by:OvdSpek at LIACS dot NL Summary:Secure Password Storage -Status: Open +Status: Wont fix Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: * PHP Version:5.0.3 Block user comment: N Private report: N New Comment: Won't happen, because password management is too diverse to have some one-size fits all solution. There is no problem per-se that scripts can read passwords. Previous Comments: [2005-01-15 16:52:32] OvdSpek at LIACS dot NL Description: Hi, Would it be possible to add secure password storage (mainly for database access) to PHP (when used as web server module) such that: The passwords are per vhost. The passwords can't be read by scripts themself in any way. The passwords can only be read by the library (function) that actually uses them. Multiple passwords can be stored. For example, a vhost could use five user/pass combinations to access five databases. The advantage would be that passwords wouldn't be stored in normal PHP files (readable by scripts) anymore and that script configuration would be easier. Reproduce code: --- - -- Edit this bug report at https://bugs.php.net/bug.php?id=31564edit=1
Req #30561 [Opn-Wfx]: PHP code execution tracing
Edit report at https://bugs.php.net/bug.php?id=30561edit=1
ID: 30561
Updated by: ni...@php.net
Reported by:asidorov at hotbox dot ru
Summary:PHP code execution tracing
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
Operating System: Windows XP
PHP Version:4.3.8
Block user comment: N
Private report: N
New Comment:
Won't be added to PHP. Stuff like this are the job of debugging extensions.
Previous Comments:
[2004-10-26 13:02:57] asidorov at hotbox dot ru
XDebug doesn't trace variables automatically. I need expicitly call
xdebug_var_dump(), var_dump() or echo. I mean that trace will dump all
variables, expressions. Something like dumping program execution tree all
expression trees and how they are collapsing.
There are situations where I need to know how my code is ran in true details.
I suppose it is hard to implement (simply I don't know how the interpreter is
implemented so I really don't know).
[2004-10-26 12:00:47] der...@php.net
Xdebug does this just fine, what do you mean?
[2004-10-26 11:48:22] asidorov at hotbox dot ru
Description:
The very very helpful thing would be adding trace capability to PHP to avoid
writing all this annoying var_dump's and echo's. Example output is unsuitable
ofcourse. It is provided just to show the idea. There may be some number of
output templates (full, medium, ...).
I know that there are debug_backtrace() and xDebug but those are not the
requested.
Thank you and best regards.
Reproduce code:
---
?php
/* ... */
// deep - deepness of tracing function calls
// output - output file
##TRACE medium, deep(0), output('trace.txt')
// ...
for ($i=0; $i$n; $i++) {
$a += $arr1[$i]/$arr2[$i] + foo($i);
}
// ...
##ENDTRACE
/* ... */
?
Expected result:
trace.txt:
//for ($i=0; $i$n; $i++) {
Init: $i=0;
Loop:
1) 0($i) 1($n) == TRUE
//$a += $arr1[$i]/$arr2[$i+1] + foo($i);
$a = -1($a) + 3($arr1[0]) / 2($arr2[1]) + 0(foo(0)) == 0.5
2) 1($i) 1($n) == FALSE
End loop.
//}
--
Edit this bug report at https://bugs.php.net/bug.php?id=30561edit=1
Bug #63616 [Asn-Dup]: iterator_count loves SplFileObject too much (endless)
Edit report at https://bugs.php.net/bug.php?id=63616edit=1
ID: 63616
Updated by: ni...@php.net
Reported by:hanskrentel at yahoo dot de
Summary:iterator_count loves SplFileObject too much
(endless)
-Status: Assigned
+Status: Duplicate
Type: Bug
Package:SPL related
Operating System: Windows
PHP Version:5.4.9
Assigned To:helly
Block user comment: N
Private report: N
New Comment:
This has the same underlying issue as https://bugs.php.net/bug.php?id=65600.
SplFileObject does not advance to the next line unless current() was called.
Previous Comments:
[2012-11-27 08:39:01] larue...@php.net
helly, do you have time to look at this? seems memory stream doesn't handle the
eof in this situation.
thanks ;)
[2012-11-26 21:43:27] hanskrentel at yahoo dot de
Description:
For some reason not clear to me, using iterator_count with the iterator
interface
of SplFileObject (as well with SplTempFileObject) results in an endless running
script.
Test script:
---
?php
$test = new SplFileObject(data://text/plain,1\n2);
$test-setFlags(SplFileObject::DROP_NEW_LINE);
echo Values: [, implode(', ', iterator_to_array($test)),
]\nCount: , iterator_count($test), \n;
?
-- OR --
?php
$test = new SplTempFileObject();
$test-setFlags(SplTempFileObject::DROP_NEW_LINE);
$test-fwrite(1\n2);
echo Values: [, implode(', ', iterator_to_array($test)),
]\nCount: , iterator_count($test), \n;
?
Expected result:
Values: [1, 2]
Count: 2
Actual result:
--
Values: [1, 2]
Count:
--
Edit this bug report at https://bugs.php.net/bug.php?id=63616edit=1
[PHP-BUG] Bug #65662 [NEW]: root files cpanel
From: mbiama at angosso dot com
Operating system: Ubuntu/linux/Apache/php
PHP version: 5.5.3
Package: Apache2 related
Bug Type: Bug
Bug description:root files cpanel
Description:
?php
include 'http://www.exemple.com/file.php/.?root=1bar=2';
$root = 1;
$bar = 2;
$(function() {
$root = include 'return.php';
echo $root; // prints 'PHP'
$bar = include 'noreturn.php';
echo $bar; // prints 1
$string = get_include_contents('somefile.php');
?
Expected result:
?php
include 'http://www.nav.com/file.php/./?root=1bar=2';
$root = 1;
$bar = 2;
$(function() {
$(#wb_element_instance599).children(ul).children().each(function() {
if
($(this).children(ul).size() == 0) return;
$(this).hover(function() {
$(this).children(ul).css({display: block});
}, function() {
$(this).children(ul).css({display: none});
});
});
});
include 'file.txt'; // id=wb_element_instance601 class=wb_element;
include 'file.php'; // ul class=hmenu;
?php include dirname(__FILES__).'/uk.zyro/li class='active'a
href='HOME/'
target='_self' title='HOME'HOME/a/li'; ?
?php include dirname(__FILES__).'/uk.zyro/li class='active'a
href='ROOMS/'
target='_self' title='ROOMS'ROOMS/a/li';
?php include dirname(__FILES__).'/uk.zyro/li class='active'a
href='RESERVATIONS/' target='_self'
title='RESERVATIONS'RESERVATIONS/a/li';
?
?php include dirname(__FILES__).'/uk.zyro/li class='active'a
href='CONTACTS/' target='_self' title='CONTACTS'CONTACTS/a/li'; ?
?php include dirname(__FILES__).'/uk.zyro/li class='active'a
href='SITEMAP/'
target='_self' title='SITEMAP'SITEMAP/a/li'; ?
?php include dirname(__FILES__).'/uk.zyro/li class='active'a
href='AFFILIATE/' target='_self' title='AFFILIATE'AFFILIATE/a/li'; ?
?php include dirname(__FILES__).'/uk.zyro/li class='active'a
href='MEDIAS/'
target='_self' title='MEDIAS'MEDIAS/a/li'; ?
if ((include 'vars.php') == 'OK') {
echo 'OK';
}
$root = include 'return.php';
echo $root; // prints 'PHP'
$bar = include 'noreturn.php';
echo $bar; // prints 1
$string = get_include_contents('somefile.php');
function get_include_contents($filename) {
if (is_file($filename)) {
ob_start();
include $filename;
return ob_get_clean();
}
return false;
}
?
--
Edit bug report at https://bugs.php.net/bug.php?id=65662edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65662r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65662r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65662r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65662r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65662r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65662r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65662r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65662r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65662r=support
Expected behavior: https://bugs.php.net/fix.php?id=65662r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65662r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65662r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65662r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65662r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65662r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65662r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65662r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65662r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65662r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65662r=mysqlcfg
Bug #40837 [Com]: static and non-static functions can't have the same name
Edit report at https://bugs.php.net/bug.php?id=40837edit=1 ID: 40837 Comment by: ed at over-yonder dot com Reported by:nick dot telford at gmail dot com Summary:static and non-static functions can't have the same name Status: Not a bug Type: Bug Package:Class/Object related Operating System: Irrelevant PHP Version:5.2.1 Block user comment: N Private report: N New Comment: Though this is old, I would like to add my own two cents. I realize that parent methods are accessed using :: as well, and this would create an ambiguity if we allowed same name usage. The problem, however, is not same name usage. The problem is that the keyword parent is the same as the keyword $this, and as such, it seems more logically sound to use parent- function than parent::function. Using the scope resolution operator logically implies the need to do so. But if we treat the parent keyword as though it is an identifier, the same way we treat object names and $this, then we can use the arrow for member functions and the scope resolution operator for static functions without ambiguity. If anything, the ambiguity / inconsistency is the use of the scope resolution operator to access member functions (which is exactly what parent::function does). In short, the usage of the scope resolution operator for parent member functions is a logical inconsistency, and the reason that parent::static and parent::member ambiguities would arise from same name capability is because of this seemingly incorrect application of scope resolution for accessing parent member functions, when a perfectly useful operator (-) already exists. In order to make compilers / interpreters handle this odd situation, they merely need to identify what things like parent and $this refer to first, which then clarifies all issues that would arise from name ambiguity, as it then allows :: and - to be distinct. Previous Comments: [2013-04-22 01:15:41] dmittner at llnw dot com Well, given the lack of similar support in other languages I can see this is an uphill battle not worth a long fight, so I'll leave with this departing thought (plus I doubt this is a proper place to debate merits of functionality changes): When I looked up this similar issue on other languages, I found people asking about it for Java and C#, and the responses fundamentally came down to the same thing: the compiler doesn't understand it. But it was clear that this is something people want in many languages, and I'd put forth that all of them doing it poorly isn't justification not to lead the charge to building a better convention. Fact is, static scope exists separate of instance scope for a reason. And if we're accepting that reason as enough to support both scopes' existence to begin with, why isn't that reason enough to take the next logical step and support resource signatures of the same name for each? Obviously using :: is out of the question and similar limitations in other languages is likely why it's not possible in them, but if we have new operators specifically to separate these, why not do it? Maybe it would put pressure on other languages to add similar support. The only remaining argument against it I could see would be one of code cleanliness and possible confusion having two methods with the same signature, but I'd have to dismiss that as minor (especially compared to overloading signatures in other languages) when there's a clear static presence on the method and the new operator on any calls to it. And with that, good day and happy programming. [2013-04-21 22:34:18] ni...@php.net @dmittner: :: is not a static access operator, it's a scope resolution operator. It calls a method (or accesses a property) in a certain scope. Conceptually that one operator is trying to do too much. That certain scope it's trying to use isn't chosen by the programmer; it's chosen by the context; by where it's being used. That's presumptuous and an unnecessary limitation. Maybe I didn't phrase that well enough. By in a certain scope I meant the class before the :: operator. In Foo::bar() the bar() method is called in the Foo scope. So, as you can see the scope *is* chosen by the programmer and no presumption takes place. :: is (AFAIK) the only way to access specifically static resources in one context, but then is also used to reference the resources of special names in other contexts. Again, this might be a misunderstanding. The scope-resolution behavior is *not* restricted to special names. It's not just about parent::foo() [and self::foo() and static::foo()], I just used that as an example as it is the most commonly used. You can do a
Req #51798 [Opn-Csd]: Implement mpz_mul_2exp
Edit report at https://bugs.php.net/bug.php?id=51798edit=1 ID: 51798 Updated by: ni...@php.net Reported by:david+php at 2good dot nu Summary:Implement mpz_mul_2exp -Status: Open +Status: Closed Type: Feature/Change Request Package:GNU MP related Operating System: Any PHP Version:5.3.2 -Assigned To: +Assigned To:nikic Block user comment: N Private report: N New Comment: This is supported in PHP 5.6 as $gmpNum $shift. Previous Comments: [2010-05-12 13:31:34] david+php at 2good dot nu Description: A number of GMP functions are not yet exposed through PHP, for example mpz_mul_2exp; Set rop to op1 times 2 raised to op2. This operation can also be defined as a left shift by op2 bits. See also http://svn.php.net/viewvc/php/php-src/trunk/ext/gmp/TODO?view=markup If I implement it I will attach the patch. -- Edit this bug report at https://bugs.php.net/bug.php?id=51798edit=1
Req #64782 [Opn-Csd]: SplFileObject constructor make $context optional / give it a default value
Edit report at https://bugs.php.net/bug.php?id=64782edit=1
ID: 64782
Updated by: ni...@php.net
Reported by:hanskrentel at yahoo dot de
Summary:SplFileObject constructor make $context optional /
give it a default value
-Status: Open
+Status: Closed
Type: Feature/Change Request
Package:SPL related
PHP Version:5.4.14
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of nikic
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=ad976d82405ad25fb424328c5b9bdca7b734cca4
Log: Fix bug #64782: SplFileObject constructor make $context optional
Previous Comments:
[2013-05-09 03:11:43] larue...@php.net
The following patch has been added/updated:
Patch Name: accept_null_for_context.patch
Revision: 1368069103
URL:
https://bugs.php.net/patch-display.php?bug=64782patch=accept_null_for_context.patchrevision=1368069103
[2013-05-09 03:10:59] larue...@php.net
all I got is:
PHP Fatal error: Uncaught exception 'RuntimeException' with message
'SplFileObject::__construct() expects parameter 4 to be resource, null given'
in
/tmp/1.php:6
Stack trace:
#0 /tmp/1.php(6): SplFileObject-__construct('/tmp/1.php', 'r', false, NULL)
#1 /tmp/1.php(10): Myfile-__construct('/tmp/1.php')
#2 {main}
thrown in /tmp/1.php on line 6
it you meant this err, yes, this could be improved. I will attach a patch
[2013-05-07 10:02:57] hanskrentel at yahoo dot de
Correction: The line $this-levels = new Levels(); in the test-script above
needs to be removed.
Addendum: The following variant shows the boilerplate code this needs to get
away with the error:
?php
class Myfile extends SplFileObject
{
public function __construct($file_name, $open_mode = r, $use_include_path
= FALSE, $context = NULL) {
if ($context === NULL) {
parent::__construct($file_name, $open_mode, $use_include_path);
} else {
parent::__construct($file_name, $open_mode, $use_include_path,
$context);
}
}
}
[2013-05-07 09:57:03] hanskrentel at yahoo dot de
Description:
When extending from SplFileObject and overwriting the constructor, it is not
easily possible to override the parent one because for the last parameter
$context
one can not provide an optional default.
Therefore it requires (somewhat needles) if-branched code only to deal with the
$context not passed case when calling the parents constructor.
It would be nice if $context does accept NULL then if I do not want to use any
context but need to specify the parameter.
Test script:
---
?php
class Myfile extends SplFileObject
{
public function __construct($file_name, $open_mode = r, $use_include_path
= FALSE, $context = NULL) {
$this-levels = new Levels();
parent::__construct($file_name, $open_mode, $use_include_path,
$context);
}
}
$file = new MyFile(__FILE__);
Expected result:
It should not give any warning or error.
Actual result:
--
Warning: Missing argument 4 for Myfile::__construct(), called in [pointing to
the
line $file = new MyFile(__FILE__);] and defined in [pointing to the line
public function __construct($file_name, $open_mode = r, $use_include_path =
FALSE, $context = NULL) {]
--
Edit this bug report at https://bugs.php.net/bug.php?id=64782edit=1
Bug #65662 [Opn-Fbk]: root files cpanel
Edit report at https://bugs.php.net/bug.php?id=65662edit=1
ID: 65662
Updated by: requi...@php.net
Reported by:mbiama at angosso dot com
Summary:root files cpanel
-Status: Open
+Status: Feedback
Type: Bug
Package:Apache2 related
Operating System: Ubuntu/linux/Apache/php
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to Open.
Thank you for your interest in PHP.
You've given no description of what the supposed bug is and the code you've
provided is indecipherable and invalid.
Previous Comments:
[2013-09-12 15:27:05] mbiama at angosso dot com
Description:
?php
include 'http://www.exemple.com/file.php/.?root=1bar=2';
$root = 1;
$bar = 2;
$(function() {
$root = include 'return.php';
echo $root; // prints 'PHP'
$bar = include 'noreturn.php';
echo $bar; // prints 1
$string = get_include_contents('somefile.php');
?
Expected result:
?php
include 'http://www.nav.com/file.php/./?root=1bar=2';
$root = 1;
$bar = 2;
$(function() {
$(#wb_element_instance599).children(ul).children().each(function() {
if
($(this).children(ul).size() == 0) return;
$(this).hover(function() {
$(this).children(ul).css({display: block});
}, function() {
$(this).children(ul).css({display: none});
});
});
});
include 'file.txt'; // id=wb_element_instance601 class=wb_element;
include 'file.php'; // ul class=hmenu;
?php include dirname(__FILES__).'/uk.zyro/li class='active'a
href='HOME/'
target='_self' title='HOME'HOME/a/li'; ?
?php include dirname(__FILES__).'/uk.zyro/li class='active'a
href='ROOMS/'
target='_self' title='ROOMS'ROOMS/a/li';
?php include dirname(__FILES__).'/uk.zyro/li class='active'a
href='RESERVATIONS/' target='_self'
title='RESERVATIONS'RESERVATIONS/a/li';
?
?php include dirname(__FILES__).'/uk.zyro/li class='active'a
href='CONTACTS/' target='_self' title='CONTACTS'CONTACTS/a/li'; ?
?php include dirname(__FILES__).'/uk.zyro/li class='active'a
href='SITEMAP/'
target='_self' title='SITEMAP'SITEMAP/a/li'; ?
?php include dirname(__FILES__).'/uk.zyro/li class='active'a
href='AFFILIATE/' target='_self' title='AFFILIATE'AFFILIATE/a/li'; ?
?php include dirname(__FILES__).'/uk.zyro/li class='active'a
href='MEDIAS/'
target='_self' title='MEDIAS'MEDIAS/a/li'; ?
if ((include 'vars.php') == 'OK') {
echo 'OK';
}
$root = include 'return.php';
echo $root; // prints 'PHP'
$bar = include 'noreturn.php';
echo $bar; // prints 1
$string = get_include_contents('somefile.php');
function get_include_contents($filename) {
if (is_file($filename)) {
ob_start();
include $filename;
return ob_get_clean();
}
return false;
}
?
--
Edit this bug report at https://bugs.php.net/bug.php?id=65662edit=1
Bug #65419 [Ver]: Inside trait, self::class != __CLASS__
Edit report at https://bugs.php.net/bug.php?id=65419edit=1 ID: 65419 Updated by: ralphschind...@php.net Reported by:nicolas dot grekas+php at gmail dot com Summary:Inside trait, self::class != __CLASS__ Status: Verified Type: Bug Package:Scripting Engine problem PHP Version:5.5.1 -Assigned To: +Assigned To:ralphschindler Block user comment: N Private report: N New Comment: Ill work up a patch that will demonstrate ::class resolving in traits similar to how __CLASS__ works in traits. This seems to be the consensus (correct me if I am wrong), and consistent with __CLASS__ (to some degree) in traits. Previous Comments: [2013-08-14 10:10:48] nicolas dot grekas+php at gmail dot com Why remove ::class support inside traits? It mostly works today, and it is as usefull there than inside classes or anywhere else, am I wrong? Would it be possible to replace self::class occurences by __CLASS__ at compile time so that the code path for __CLASS__ is also used here? [2013-08-11 15:31:06] larue...@php.net I prefer to trigger a COMPILE ERROR prevent from using ::class in a traits [2013-08-09 07:57:41] g...@php.net Yes, that looks wrong. It should indeed behave as __CLASS__. [2013-08-09 07:55:23] nicolas dot grekas+php at gmail dot com I totally agree with you. This reminds me the discussion that happened in https://bugs.php.net/55214 and that led to this special handling for __CLASS__. I think that the very same arguments apply here also. Concerning parent and static, they are free from this problem because they are resolved at run-time (tested, it works). [2013-08-08 18:33:55] requi...@php.net The RFC was created a few weeks after 5.4.0 was released and does not specify how self::class would work for traits. I would take that to mean the writer did not consider how it would work for traits, rather than that traits should inherit the behavior for classes. So either this is a doc bug and the ::class doc should state that it resolves to the trait itself when used for traits (as a ::trait syntax would be weird), or self::class is fixed so be identical to __CLASS__. Presumably parent::class and static::class would receive similar changes. Note for the latter: in zend_language_scanner, __CLASS__ has special handling when used inside traits. I imagine similar logic - creating a special __CLASS__ constant - would be used in zend_do_resolve_class_name(). 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=65419 -- Edit this bug report at https://bugs.php.net/bug.php?id=65419edit=1
Bug #46064 [Opn-Csd]: Exception when creating ReflectionProperty object on dynamicly created property
Edit report at https://bugs.php.net/bug.php?id=46064edit=1
ID: 46064
Updated by: fel...@php.net
Reported by:zemi dot inet at gmail dot com
Summary:Exception when creating ReflectionProperty object on
dynamicly created property
-Status: Open
+Status: Closed
Type: Bug
Package:Reflection related
Operating System: Linux amoeba 2.6.22-14-server
PHP Version:5.2.6
-Assigned To:
+Assigned To:felipe
Block user comment: N
Private report: N
Previous Comments:
[2008-10-29 15:06:29] fel...@php.net
This bug has been fixed in CVS.
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/.
Thank you for the report, and for helping us make PHP better.
We need add some examples for this case. The tests added with the patch can
help.
http://news.php.net/php.cvs/53766
[2008-09-12 11:16:08] zemi dot inet at gmail dot com
Description:
Always getting exception when creating ReflectionProperty object on dynamicly
created property.
Discovered when I tried to use ReflectionProperty::isDefault().
I presume it returns true when property is created on compile-time and false
when dynamicly created on run-time?
Reproduce code:
---
class x {
public $x = 1;
public $y = 1;
}
$o = new x;
$o-z = 1;
$reflector = new ReflectionProperty($o, 'z');
$d = $reflector-isDefault();
Expected result:
$d == false
Actual result:
--
Fatal error: Uncaught exception 'ReflectionException' with message 'Property
x::$z does not exist' on line: $reflector = new ReflectionProperty($o, 'z');
--
Edit this bug report at https://bugs.php.net/bug.php?id=46064edit=1
Req #33350 [Com]: php can't handle utf-8 in path names
Edit report at https://bugs.php.net/bug.php?id=33350edit=1 ID: 33350 Comment by: bvibber at wikimedia dot org Reported by:php-bug dot scyt at spamgourmet dot com Summary:php can't handle utf-8 in path names Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: Windows XP PHP Version:5.0.4 Block user comment: N Private report: N New Comment: So, this is still an issue that affects programs like MediaWiki running on Windows servers: https://bugzilla.wikimedia.org/show_bug.cgi?id=1780 Windows NT/XP/Vista/7/8/etc use Unicode for file names, but the POSIX filesystem APIs expose only the ANSI interfaces, which use 8-bit or DBCS locale-specific encodings. Since PHP's filesystem APIs seem to use the POSIX ones, you can't use UTF-8 for filenames as one expects on Linux, Mac OS X, etc. Not only this, but there's no general way to simply switch encodings -- you'll be limited to the 8-bit encoding's character set, so can't for instance upload a Chinese-named file to a Russian-configured server. Some other cross-platform toolkits like glib use Win32's Unicode filesystem APIs internally, which allow using the full Unicode character set for filenames, and expose the Unicode strings as UTF-8 for C null-terminated string compatibility. Previous Comments: [2005-06-15 14:42:12] php-bug dot scyt at spamgourmet dot com Nice try. :) It should do the same thing apache does. Convert the UTF-8 string to the system's character encoding. That is UTF-16 or the 8-bit character encoding windows is currently set to. You could do the conversion to the 8-bit character encoding. That would save some code changes and would work in most cases. But there are systems where this would still fail. e.g. having directory names with german umlauts and setting the 8-bit character encoding to a character encoding without this umlauts (e.g. russian). The UTF-16 way would work in this scenario and is therefore preferable. [2005-06-15 13:44:36] ed...@php.net The underlying filesystem is not UTF-8 based so there is very little PHP can do here. [2005-06-15 11:59:56] php-bug dot scyt at spamgourmet dot com Description: Apache2 on Windows NT based operating systems uses utf-8 to encode pathnames. php fails with file not found error messages if it encounters such pathes. mod_php and php-cgi.exe is affected. Reproduce code: --- Rename a directory that contains a php script to testÄ. That is an capital A with two dots above it. Codepoint 196 in latin-1. Then try to access this php script through the webserver. -- Edit this bug report at https://bugs.php.net/bug.php?id=33350edit=1
Req #60577 [Opn-Ver]: count(new EmptyIterator) returns 1
Edit report at https://bugs.php.net/bug.php?id=60577edit=1 ID: 60577 Updated by: le...@php.net Reported by:adam at sixohthree dot com Summary:count(new EmptyIterator) returns 1 -Status: Open +Status: Verified Type: Feature/Change Request Package:SPL related PHP Version:5.4SVN-2011-12-20 (SVN) Block user comment: N Private report: N New Comment: I confirmed this for versions 5.1.0 - 5.5.3. Previous Comments: [2011-12-20 20:17:50] adam at sixohthree dot com Description: As an object that simulates a list of zero items, count(new EmptyIterator) should return zero. Test script: --- ?php $it = new EmptyIterator; var_dump(count($it)); Expected result: int(0) Actual result: -- int(1) -- Edit this bug report at https://bugs.php.net/bug.php?id=60577edit=1
Bug #52560 [Asn-Nab]: FilterIterator errantly returns null for first element
Edit report at https://bugs.php.net/bug.php?id=52560edit=1
ID: 52560
Updated by: le...@php.net
Reported by:tobias382 at gmail dot com
Summary:FilterIterator errantly returns null for first
element
-Status: Assigned
+Status: Not a bug
Type: Bug
Package:SPL related
Operating System: Ubuntu 10.04
PHP Version:5.3SVN-2010-08-07 (snap)
-Assigned To:colder
+Assigned To:levim
Block user comment: N
Private report: N
New Comment:
This is simply a common misunderstanding. Iterators need to be rewound before
use.
Whether that was a good design or not is debatable, but nonetheless this is not
a
bug.
Previous Comments:
[2010-08-07 04:49:28] tobias382 at gmail dot com
Small amendment: $iterator-rewind() should be $this-rewind() in the
overridden
constructor in the test script.
[2010-08-07 04:40:26] tobias382 at gmail dot com
Description:
Even when a FilterIterator subclass accepts all elements, it returns NULL for
the
first element in the original array. There are a few methods to correct this
behavior, noted in the attached test script.
Test script:
---
?php
class FooIterator extends FilterIterator {
/*
// Forces this class to produce expected behavior below
// (i.e. 1, 2, NULL instead of NULL, 2, NULL)
public function __construct(Iterator $iterator) {
parent::__construct($iterator);
$iterator-rewind();
}
*/
// Should cause all elements to be accepted
public function accept() {
return true;
}
/*
// Another way to force this class to produce expected behavior below
public function current() {
return $this-getInnerIterator()-current();
}
*/
}
$array = array(1, 2);
/*
// What should happen in subsequent blocks
$iterator1 = new ArrayIterator($array);
var_dump($iterator1-current()); // int(1)
$iterator1-next();
var_dump($iterator1-current()); // int(2)
$iterator1-next();
var_dump($iterator1-current()); // NULL
*/
// The problem
$iterator2 = new FooIterator(new ArrayIterator($array));
var_dump($iterator2-current()); // NULL -- this should be int(1)
$iterator2-next();
var_dump($iterator2-current()); // int(2)
$iterator2-next();
var_dump($iterator2-current()); // NULL
// Exhibits correct behavior with no changes to FooIterator
$iterator3 = new FooIterator(new ArrayIterator($array));
$iterator3-rewind(); // This line shouldn't be needed, but is to force
expected behavior
var_dump($iterator3-current()); // int(1)
$iterator3-next();
var_dump($iterator3-current()); // int(2)
$iterator3-next();
var_dump($iterator3-current()); // NULL
Expected result:
int(1)
int(2)
NULL
int(1)
int(2)
NULL
Actual result:
--
NULL
int(2)
NULL
int(1)
int(2)
NULL
--
Edit this bug report at https://bugs.php.net/bug.php?id=52560edit=1
Bug #27792 [Ctl-Opn]: [PATCH] Functions fail on large files (filesize,is_file,is_dir,readdir)
Edit report at https://bugs.php.net/bug.php?id=27792edit=1 ID: 27792 Updated by: ni...@php.net Reported by:kode at kodekrash dot com Summary:[PATCH] Functions fail on large files (filesize,is_file,is_dir,readdir) -Status: Critical +Status: Open Type: Bug Package:Filesystem function related Operating System: * (LFS) PHP Version:5.*, 6CVS (2009-04-30) Block user comment: N Private report: N Previous Comments: [2013-08-30 14:23:47] mail dot pourri at laposte dot net This is the most absurd comment I've ever seen! The software does not work as expected, please fix your machine. I've attached a new updated version of the patch against version 5.5.1 I've no time to backport the patch to any previous version, please be my guest if you need it. Some comments about the patch: 1) Changes size_t to off_t at required places in the code (this will only work if the LFS mode is specified at compilation/configuration time, that is if you type CFLAGS='-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' ./configure --usual-args 2) Pass all the tests that where passing without the patch 3) Fix a test that was failing without the patch (you can't mmap a pipe's file descriptor, the patch prevent doing so instead of failing at runtime) 4) Returns a double when/where the file size/offset is larger than 2^32 bytes. This means that file with size up to 2^52 (the size of a double's mantissa) can now be used with PHP on 32 bits machine. This is not the plain 64 bits, but adding a new type to PHP for 64 bits integer would be a much larger work. For file size/offset below 2^32 bytes, the previous type (integer) is still used, so backward compatibility is kept. For file larger than 2^52 bytes, approximate values are used (this is still not an issue since reading/writing such file would still work since it's done in C) 5) Loops on copy_stream/passthru until the complete stream is read, unlike the previous behavior of only reading up to the first 2GB of the file. Let me know if it helps. [2013-05-29 09:57:27] Sjon at hortensius dot net According to http://3v4l.org/sBClC; this is not a problem on a 64 bits linux machine (on any php version). I propose (since this bug obviously won't be fixed) to close this issue and tell people to use 64 bits machines instead of trying to get LFS support in PHP [2012-08-09 13:28:31] adu at rdsor dot ro @marcb I tested it in PHP 5.4.0 (cli) (built: Apr 12 2012 13:02:59)) on Ubuntu 12.04 kernel 3.0.0-19 i686 and the BUG is still here. Reproduced code: $fname = 'file_of_7GB'; var_dump(filesize( $fname )); // PHP Warning: filesize(): stat failed for file_of_7GB in php_bug_27792.php on line 4 // dumps bool(false) var_dump(is_file( $fname )); // dumps bool(false) var_dump(is_dir( $fname )); // dumps bool(false) $fname = 'file_of_354MB'; var_dump(filesize( $fname )); // dumps int(370336155) var_dump(is_file( $fname )); // dumps bool(true) var_dump(is_dir( $fname )); // dumps bool(false) [2011-01-05 04:46:23] marcb at voicemeup dot com Is anyone able to confirm if this was fixed in any of the 5.X branch ? This is a pretty stupid problem to have to deal with ! [2009-11-12 10:27:45] boite dot pour dot spam at gmail dot com The patch from Wez doesn't work, as it assumes size_t are 64 bits, which is not the case, even when LFS is defined. The patch from Mail Pourri works on 5.3.0 (I haven't tested in 5.3.1) 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=27792 -- Edit this bug report at https://bugs.php.net/bug.php?id=27792edit=1
[PHP-BUG] Req #65664 [NEW]: __destruct act different when instantiate class with/out var
From: valentiny510 at yahoo dot es
Operating system: Secret :)
PHP version: 5.4.19
Package: Class/Object related
Bug Type: Feature/Change Request
Bug description:__destruct act different when instantiate class with/out var
Description:
When the class is instantiated with a variable is working like one
espect...
but the issue come when you want to miss the variable, because you don't
use it or whatever reason..
Can be possible to act the same way both times ?
Examples below..
Test script:
---
?php
class Html
{
function __construct( ) { echo Header\n; }
function __construct( ) { echo \nFooter; }
}
# without variable
new Html;
pSome html here.../p
# with $html var...
$html = new Html;
pSome html here.../p
Expected result:
Header
Some html here...
Footer
Header
Some html here...
Footer
Actual result:
--
Header
Footer -- This is the problem...
Some html here...
Header
Some html here...
Footer
--
Edit bug report at https://bugs.php.net/bug.php?id=65664edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65664r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65664r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65664r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65664r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65664r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65664r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65664r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65664r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65664r=support
Expected behavior: https://bugs.php.net/fix.php?id=65664r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65664r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65664r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65664r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65664r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65664r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65664r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65664r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65664r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65664r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65664r=mysqlcfg
Bug #65629 [Opn-Ver]: SplObjectsStorage::detach() rewinds internal pointer
Edit report at https://bugs.php.net/bug.php?id=65629edit=1
ID: 65629
Updated by: le...@php.net
Reported by:alan dot bem at gmail dot com
Summary:SplObjectsStorage::detach() rewinds internal pointer
-Status: Open
+Status: Verified
Type: Bug
Package:SPL related
PHP Version:Irrelevant
-Assigned To:
+Assigned To:levim
Block user comment: N
Private report: N
New Comment:
Regardless of whether this is a bug, in general modifying a structure during
iteration has undefined behavior. I will look a bit into this and see what
might
be done.
Previous Comments:
[2013-09-07 03:14:18] alan dot bem at gmail dot com
Description:
It seems that SplObjectsStorage::detach() internally rewinds its array pointer.
PHP versions from 5.1.0 to 5.5.3 are affected.
Test script:
---
// To see this live, go to: http://3v4l.org/MAELj
?php
class A
{
public $val;
public function __construct($val) { $this-val = $val; }
}
$storage = new SplObjectStorage;
for($i = 1; $i = 10; $i++) {
$storage-attach(new A($i));
}
$iterations = 0;
$storage-rewind();
while ($storage-valid()) {
$iterations++;
$object = $storage-current();
echo 'Iteration #' . $iterations . ' with object A(' . $object-val . ')';
$storage-next();
if($iterations === 2 || $iterations === 8) {
$storage-detach($object);
echo ' - deleted Object A(' . $object-val . ') ';
}
echo PHP_EOL;
}
echo 'Number of iterations: ' . $iterations . PHP_EOL;
Expected result:
Iteration #1 with object A(1)
Iteration #2 with object A(2) - deleted Object A(2)
Iteration #3 with object A(3)
Iteration #4 with object A(4)
Iteration #5 with object A(5)
Iteration #6 with object A(6)
Iteration #7 with object A(7) - deleted Object A(7)
Iteration #8 with object A(8)
Iteration #9 with object A(9)
Iteration #10 with object A(10)
Number of iterations: 10
Actual result:
--
Iteration #1 with object A(1)
Iteration #2 with object A(2) - deleted Object A(2)
Iteration #3 with object A(1)
Iteration #4 with object A(3)
Iteration #5 with object A(4)
Iteration #6 with object A(5)
Iteration #7 with object A(6)
Iteration #8 with object A(7) - deleted Object A(7)
Iteration #9 with object A(1)
Iteration #10 with object A(3)
Iteration #11 with object A(4)
Iteration #12 with object A(5)
Iteration #13 with object A(6)
Iteration #14 with object A(8)
Iteration #15 with object A(9)
Iteration #16 with object A(10)
Number of iterations: 16
--
Edit this bug report at https://bugs.php.net/bug.php?id=65629edit=1
Req #65664 [Opn-Nab]: __destruct act different when instantiate class with/out var
Edit report at https://bugs.php.net/bug.php?id=65664edit=1
ID: 65664
Updated by: ni...@php.net
Reported by:valentiny510 at yahoo dot es
Summary:__destruct act different when instantiate class
with/out var
-Status: Open
+Status: Not a bug
Type: Feature/Change Request
Package:Class/Object related
Operating System: Secret :)
PHP Version:5.4.19
Block user comment: N
Private report: N
New Comment:
The destructor is called when where are no more references to an object. In
case of a temporary value (just new Html that isn't assigned) this will happen
right after the expression is evaluated.
Previous Comments:
[2013-09-12 22:48:59] valentiny510 at yahoo dot es
Description:
When the class is instantiated with a variable is working like one espect...
but the issue come when you want to miss the variable, because you don't use it
or whatever reason..
Can be possible to act the same way both times ?
Examples below..
Test script:
---
?php
class Html
{
function __construct( ) { echo Header\n; }
function __construct( ) { echo \nFooter; }
}
# without variable
new Html;
pSome html here.../p
# with $html var...
$html = new Html;
pSome html here.../p
Expected result:
Header
Some html here...
Footer
Header
Some html here...
Footer
Actual result:
--
Header
Footer -- This is the problem...
Some html here...
Header
Some html here...
Footer
--
Edit this bug report at https://bugs.php.net/bug.php?id=65664edit=1
Req #65664 [Com]: __destruct act different when instantiate class with/out var
Edit report at https://bugs.php.net/bug.php?id=65664edit=1
ID: 65664
Comment by: valentiny510 at yahoo dot es
Reported by:valentiny510 at yahoo dot es
Summary:__destruct act different when instantiate class
with/out var
Status: Not a bug
Type: Feature/Change Request
Package:Class/Object related
Operating System: Secret :)
PHP Version:5.4.19
Block user comment: N
Private report: N
New Comment:
$html = new Html;
-- From here to the end of script there is no more references to that object...
pSome html here.../p
P.S. Thank you for answering so fast :)
Previous Comments:
[2013-09-12 22:59:04] ni...@php.net
The destructor is called when where are no more references to an object. In
case of a temporary value (just new Html that isn't assigned) this will happen
right after the expression is evaluated.
[2013-09-12 22:48:59] valentiny510 at yahoo dot es
Description:
When the class is instantiated with a variable is working like one espect...
but the issue come when you want to miss the variable, because you don't use it
or whatever reason..
Can be possible to act the same way both times ?
Examples below..
Test script:
---
?php
class Html
{
function __construct( ) { echo Header\n; }
function __construct( ) { echo \nFooter; }
}
# without variable
new Html;
pSome html here.../p
# with $html var...
$html = new Html;
pSome html here.../p
Expected result:
Header
Some html here...
Footer
Header
Some html here...
Footer
Actual result:
--
Header
Footer -- This is the problem...
Some html here...
Header
Some html here...
Footer
--
Edit this bug report at https://bugs.php.net/bug.php?id=65664edit=1
[PHP-BUG] Bug #65665 [NEW]: Exception not properly caught when opcache enabled
From: ryan dot brothers at gmail dot com
Operating system: Linux
PHP version: 5.5.3
Package: opcache
Bug Type: Bug
Bug description:Exception not properly caught when opcache enabled
Description:
When running the following script with opcache enabled, the exception is
not caught by the correct catch block. The exception should be caught by
the 'caught by 1' block, but it is instead caught by the 'caught by 2'
block. Disabling opcache causes the exception to be caught in the correct
block.
Run the script with:
php -n -d zend_extension=opcache.so -d opcache.enable_cli=1 script.php
Test script:
---
?php
try
{
switch (1)
{
case 0:
try
{
}
catch (Exception $e)
{
}
break;
case 1:
try
{
throw new Exception('aaa');
}
catch (Exception $e)
{
echo 'caught by 1';
exit;
}
break;
}
}
catch (Exception $e)
{
echo 'caught by 2';
exit;
}
Expected result:
caught by 1
Actual result:
--
caught by 2
--
Edit bug report at https://bugs.php.net/bug.php?id=65665edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65665r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65665r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65665r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65665r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65665r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65665r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65665r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65665r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65665r=support
Expected behavior: https://bugs.php.net/fix.php?id=65665r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65665r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65665r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65665r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65665r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65665r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65665r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65665r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65665r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65665r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65665r=mysqlcfg
Bug #61981 [Fbk-NoF]: OO API, walk: $suffix_as_key is not working correctly
Edit report at https://bugs.php.net/bug.php?id=61981edit=1 ID: 61981 Updated by: lytbo...@php.net Reported by:gubin dot gm at yandex dot ru Summary:OO API, walk: $suffix_as_key is not working correctly -Status: Feedback +Status: No Feedback Type: Bug Package:SNMP related Operating System: * PHP Version:5.4.3 Assigned To:lytboris Block user comment: N Private report: N New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Re-Opened. Thank you. Previous Comments: [2013-03-17 16:58:15] lytbo...@php.net Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2013-03-17 16:53:58] lytbo...@php.net Automatic comment on behalf of lytboris Revision: http://git.php.net/?p=php-src.git;a=commit;h=b32405053f5a32d8c4d83f7566f5b414afd3aedb Log: Fix bug #61981 [2013-03-17 16:53:57] lytbo...@php.net Automatic comment on behalf of lytboris Revision: http://git.php.net/?p=php-src.git;a=commit;h=44197774c02506be626c85ec60889b58c6c0575e Log: Fixed bug #61981 [2012-05-09 11:10:56] gubin dot gm at yandex dot ru Description: Bag in method SNMP::walk. The parameter $suffix_as_key not working correctly. Test script: --- ?php $session = new SNMP(SNMP::VERSION_2c, 127.0.0.1, public); $ifDescr = $session-walk(.1.3.6.1.2.1.2.2.1.2, TRUE); print_r($ifDescr); ? Expected result: Array ( [1001] = Port 1:1 [1002] = Port 1:2 [1003] = Port 1:3 ... ) Actual result: -- Array ( [1001] = Port 1:1 [iso.3.6.1.2.1.2.2.1.2.1002] = Port 1:2 [iso.3.6.1.2.1.2.2.1.2.1003] = Port 1:3 ... ) -- Edit this bug report at https://bugs.php.net/bug.php?id=61981edit=1
Bug #64159 [Fbk-NoF]: Truncated snmpget
Edit report at https://bugs.php.net/bug.php?id=64159edit=1 ID: 64159 Updated by: lytbo...@php.net Reported by:loic dot blot at unix-experience dot fr Summary:Truncated snmpget -Status: Feedback +Status: No Feedback Type: Bug Package:SNMP related Operating System: * PHP Version:5.4.11 Assigned To:lytboris Block user comment: N Private report: N New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Re-Opened. Thank you. Previous Comments: [2013-05-03 12:08:55] lytbo...@php.net Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2013-05-03 12:08:02] lytbo...@php.net Automatic comment on behalf of lytboris Revision: http://git.php.net/?p=php-src.git;a=commit;h=2c336c9cde524cb6465bbd75924b7e40251aefab Log: Fixed bug #64159 (Truncated snmpget) [2013-05-03 12:08:00] lytbo...@php.net Automatic comment on behalf of lytboris Revision: http://git.php.net/?p=php-src.git;a=commit;h=e36adfe94a663bc1eeb5d9d378dc80883de179db Log: Fixed bug #64159 (Truncated snmpget) [2013-05-03 09:35:46] lytbo...@php.net Basically this is because of loosy algorithm predicting string length produced by snmp library function that prints OID values. As a walkaround one can set === snmp_set_valueretrieval(SNMP_VALUE_PLAIN); === (or OO API [SNMP Object]-valueretrieval) and then use bin2hex to decode binary string into hex string. [2013-02-20 18:40:33] yordan dot yordanov at innologica dot com Happening to me aslo. Here's my reproduction: [root@monitor ~]# snmpwalk -cpublic -v1 192.168.0.232 -On .1.3.6.1.4.1.9.9.46.1.6.1.1.4.10003 .1.3.6.1.4.1.9.9.46.1.6.1.1.4.10003 = Hex-STRING: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 [root@monitor ~]# php -r 'print_r(snmprealwalk(192.168.0.232,public,.1.3.6.1.4.1.9.9.46.1.6.1.1.4.10 003));' Array ( [SNMPv2-SMI::enterprises.9.9.46.1.6.1.1.4.10003] = Hex-STRING: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ) [root@monitor ~]# php -v PHP 5.4.11 (cli) (built: Jan 16 2013 16:51:38) Copyright (c) 1997-2013 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies [root@monitor ~]# uname -a Linux 2.6.32-279.19.1.el6.x86_64 #1 SMP Wed Dec 19 07:05:20 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux [root@monitor ~]# cat /etc/centos-release CentOS release 6.3 (Final) 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=64159 -- Edit this bug report at https://bugs.php.net/bug.php?id=64159edit=1
Bug #64765 [Fbk-NoF]: Some IPv6 addresses get interpreted wrong
Edit report at https://bugs.php.net/bug.php?id=64765edit=1
ID: 64765
Updated by: lytbo...@php.net
Reported by:gmcgraw at udel dot edu
Summary:Some IPv6 addresses get interpreted wrong
-Status: Feedback
+Status: No Feedback
Type: Bug
Package:SNMP related
Operating System: Linux
PHP Version:5.4.14
Assigned To:lytboris
Block user comment: N
Private report: N
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to Re-Opened. Thank you.
Previous Comments:
[2013-05-03 08:45:00] lytbo...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.4-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2013-05-03 08:41:41] lytbo...@php.net
Automatic comment on behalf of lytboris
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=3828f6227b188bd0c8d829a375ebf51faf67c448
Log: Fix bug #64765 (enclose IPv6 address into square brackets)
[2013-05-02 22:46:10] gmcgraw at udel dot edu
Description:
PHP sends the following string to Net-SNMP to parse as an address:
udp6:fc00::23:250:56ff:fe82:3177
Net-SNMP understands the final part of the IP address to be a port number,
since
it has no hexadecimal characters in it. There was an earlier bug filed and
fixed in PHP 5.4 that involved IPv6 but that fix only partially addressed the
issue (bug #42918). It made PHP correctly parse IPv6 address but it didn't
ensure that PHP sent Net-SNMP a form of address that it will always correctly
interpret.
My patch causes square brackets to always surround the IPv6 address, so that
Net-SNMP cannot possibly interpret the last part of the Ipv6 address as a port
number. The port number will be placed outside the square brackets. Here is
an
example of how it will now send the IPV6 address to Net-SNMP:
udp6:[fc00::23:250:56ff:fe82:3177]
Or if there is a custom port number 1234:
udp6:[fc00::23:250:56ff:fe82:3177]:1234
Net-SNMP will correctly parse that and use the default SNMP port number (161)
if
none is specified or the provided port number otherwise.
I have reproduced this in 5.4.1 and 5.4.14.
Test script:
---
$s=new SNMP(SNMP::VERSION_2C, '[fc00::23:250:56ff:fe82:3177]', 'public');
print_r($s-get('.1.3.6.1.2.1.1.1.0'));
Expected result:
STRING: Linux mykernel12345 #5 SMP Fri Jun 1 19:44:50 GMT 2012 x86_64
Actual result:
--
Warning: SNMP::get(): No response from udp6:fc00::23:250:56ff:fe82:3177 in php
shell code on line 1
--
Edit this bug report at https://bugs.php.net/bug.php?id=64765edit=1
