#23821 [Com]: Not requireing or including files
ID: 23821
Comment by: keithm at aoeex dot com
Reported By: admin at donelson dot net
Status: Open
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 4.3.3-dev
New Comment:
This isn't a bug, but user error. When includeing a file via URL, php
will make a request the server just as a browser would. Therefore, PHP
will not have access to the acutual PHP code, but only what it outputs.
Inorder to make this work, either name your file something else so
that the webserver doesn't parse it (.inc for example) or use local
filesystem paths to include files and not URLs.
Previous Comments:
[2003-05-28 13:45:01] admin at donelson dot net
Here is the scripts you requested. I had done as you asked and looked
into reporting a bug
and here is the end result. This order.php reproduces the error
perfectly. order.php is supposed to include McDonalds.php so it knows
how to place and receive and order.
http://localhost/phpBug/McDonalds.php";); // Nope
require("http://www.donelson.net/phpBug/McDonalds.php";); // Nope
$meal = new HappyMeal(1);
$meal->Buy();
?>
http://www.donelson.net/phpBug/McDonalds.php
*/
// Enable first line below for local testing,
// second URL local testing, and third for actual usage
// The support files are uploaded for testing purposes.
require("food.php");
//require("http://localhost/phpBug/food.php";);
//require("http://www.donelson.net/phpBug/food.php";);
class HappyMeal {
var $m_meal = array();
var $m_burger;
var $m_side;
var $m_drink;
function HappyMeal($number=1) {
$this->m_meal['burger'] = new Burger($number);
$this->m_meal['side'] = new Side($number);
$this->m_meal['drink'] = new Drink($number);
}
function Buy() {
foreach ($this->m_meal as $item) {
echo sprintf("Preparing %s",$item->Prepare());
}
}
}
?>
http://www.donelson.net/phpBug/food.php
*/
class Item {
var $name = '';
function Prepare() { return $this->name; }
}
class Burger extends Item {
var $name = 'BigMAC';
}
class Side extends Item {
var $name = 'Fries';
}
class Drink extends Item {
var $name = 'Dr Pepper';
}
?>
[2003-05-27 03:39:44] [EMAIL PROTECTED]
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.
We need a short, self contained reproducing script.
[2003-05-26 19:54:15] admin at donelson dot net
reopened.
[2003-05-26 19:53:29] admin at donelson dot net
Thanks sniper, I went there and download/installed 4.3.3-dev. I get the
samething on localhost, dont know on remote host. They only run the
latest released stable versions :(
Everything is same as it was before. Any more ideas for me? I got an
entire library that I am trying to get out but this needs to be fixed
first.
[2003-05-26 19:19:06] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/23821
--
Edit this bug report at http://bugs.php.net/?id=23821&edit=1
#30971 [Com]: Random highlight_string() bug while handling legal backslash characters
ID: 30971
Comment by: keithm at aoeex dot com
Reported By: [EMAIL PROTECTED]
Status: Verified
Bug Type: Strings related
Operating System: *
PHP Version: 4CVS, 5CVS
New Comment:
>>Okay, getting ahead of myself. There's been a radical change from
5.0.2
>>to 5.0.3, and it appears to have been partially repaired, but
>>highlighting is still botched.
Nothing radical has changed on the server. I simply decided to
implement "the fix" which is to prepend highlight_string with the error
suppression operator (@). As is apparent though, the error is still
occuring, it is just now hidden. If you look you will notice that the
colors are incorrect, and also the slashes be fore the '\n' codes int
he print statements are missing.
If you wish to see the orginal behaviour, append &dophpbug=1 to the URL
and it will revert back to the orginal code.
http://dalphp.shoggoth.net/pastebin_view.php?356&dophpbug=1
vs.
http://dalphp.shoggoth.net/pastebin_view.php?356
Previous Comments:
[2005-01-04 05:15:19] [EMAIL PROTECTED]
Okay, getting ahead of myself. There's been a radical change from 5.0.2
to 5.0.3, and it appears to have been partially repaired, but
highlighting is still botched.
Screenshots:
Bad: http://labs.jed.bz/renewed_bad.png
Good: http://labs.jed.bz/renewed_good.png
Hopefully this change will give someone more experienced with the
parser a hook into this odd behavior? This definitely changed between
5.0.2 and 5.0.3, but the bug in various forms still exists in both 4
and 5.
[2005-01-04 05:09:17] [EMAIL PROTECTED]
This is still my bug, and hey, I have CVS now, so I can verify it too.
Parsers really scare me so I'm not sure where to look to fix this, but
hopefully verifying it will renew interest in this? This seems like a
core parser problem.
[2004-12-14 22:54:30] jed at jed dot bz
Eh? Gave up already?
[2004-12-03 00:56:32] [EMAIL PROTECTED]
Description:
Bug 25725 was marked bogus due to a bad example. I am reopening it here
because this is a particularly annoying bug that needs to be fixed,
regardless of 'this is not an issue' sentiment within the PHP
community.
When the highlight_string() engine encounters ANY \ character, even one
prefixing an escape like \n (which are LEGAL, as some astute Quick Fix
posters have ignored), the parser interjects warnings into
highlight_string()'s output. The catch? This only happens randomly.
We rely on highlight_string() for our IRC pastebin, and I am sure this
function is used a lot elsewhere. I have submitted another entry to our
pastebin and was quite disappointed to see the bug's problem at once:
http://labs.jed.bz/phpbug3.png
Screenshot taken from
http://dalphp.shoggoth.net/pastebin_view.php?533
I have highlighted the problem for the QA reviewers with itchy Quick
Fix fingers. Notice the 'n' sitting on a line all by itself? That's the
back end of a \n sequence, and the PHP parser is erring on the \ itself.
It's as if the tokenizer, when used under highlight_string(), isn't
glomming \ onto its following character.
It is also only doing it on some newlines. As you can see, the newlines
next to '019' (the bottom of the highlight) are parsed fine! As you can
also see, the colors in the rest of the code, even on keywords that
should be highlighted green like 'static' and 'function', are all
messed up.
This isn't the first time we've run into this. I've taken screenshots
to append to Bug 25725, but they were ignored as well. I rewind and
replay them here for community benefit.
CORRECT: http://labs.jed.bz/phpbug2.png
NOT: http://labs.jed.bz/phpbug.png
Source URL: http://dalphp.shoggoth.net/pastebin_view.php?356
Nothing changed on the server between these two requests. I just
refreshed until the output changed. And these are legal newlines. The
example on Bug 25725 brought the itchy Quick Fix fingers out, but the
submitter presented a valid point, which I reiterate here.
Highlighted fine:
$x = 0
$y = 1
$z = 2
Not highlighted fine:
$x = 0;
\;
$z = 2;
And as I've demonstrated, this isn't highlighted fine either:
printf("\n");
The randomness of this problem suggests a leak or black magic within
PHP itself, and I have a gut feeling this is a little more problematic
than it appears at first hand. The reproduce code below is what is
supposed to be highlighted in phpbug3.png.
Note: Do not flood dalphp.shoggoth.net with refresh requests, trust my
screenshots.
Reproduce code:
--
#28444 [Com]: "Cannot access undefined property for object with overloaded property access"
ID: 28444
Comment by: keithm at aoeex dot com
Reported By: dennis at inmarket dot lviv dot ua
Status: Assigned
Bug Type: Class/Object related
Operating System: WinXP
PHP Version: 5.0.0RC2
Assigned To: andi
New Comment:
I ran into this problem also, but slighly differently. In my case, the
first property I'm accessing is a validly declared and set property of
the class, instead of set using __set or read using __get. I've tried
to reproduce it using simpler code, but I can't seem to get it done.
The actual code I'm using is far too complex for a bug report
submission (it's a customized DOM implemtation)
I'll see if I can describe it at all. Basically I have the following
classes that are involved:
abstract class Node -- Does define __set/__get
abstract class HTMLElement extends Node -- Does define __set/__get
class HTMLInputElement extends HTMLElement -- Does define __set/__get
class FormElement extends HTMLElement -- Does NOT define __set/__get
Now, the FormElement class has variable declarations like so:
private $minput;
private $mlabel;
private $mlplacement;
private $container;
$minput is eventuall an instance of HTMLInputElement when this error
occurs. Here is the relevent part of the formElement->setInputType
function
public function setInputType($xtype){
unset($this->minput);
switch ($xtype){
..
case 'radio': case 'text': case 'entry': case
'button': case 'image': case 'submit': case 'reset': case 'checkbox':
$this->minput=$this->ownerDocument->createElement('INPUT');
/* as of this point, $this->minput is a valid HTMLInputElement
instance, verified w/ print_r */
$this->minput->type = $xtype;
break;
...
}
When that method is called, I receive the error in question on the
line: $this->minput->type = $xtype;
I'll keep trying to come up with simpler code that reproduces the bug,
but if anyone does want to view the big code (maybe for clarity) it is
available at
http://wiser.kicks-ass.org:8008/PHPDOM/PHPDOM-error.tar.gz
My PHP version is 5.0.2, and I can reproduce with both the CLI and
Apache 2 Module. Operating systems Both FreeBSD and Linux 2.6.9
Previous Comments:
[2004-11-08 20:05:09] php at rodric dot org
I ran into this in a slightly different way -- trying to
foreach through an ArrayAccess object. Interestingly,
removing the __set from class O allows this to work.
class O
{
private $m_a = array();
function __get ($key)
{
return $this->m_a[$key];
}
function __set ($key, $val)
{
$this->m_a[$key] = $val;
}
}
class A implements ArrayAccess, IteratorAggregate
{
private $m_e = array();
function __construct ($e = NULL)
{
$this->m_e = is_null ($e) ? array() : $e;
}
function offsetSet ($key, $value)
{
$this->m_e[$key] = $value;
}
function offsetGet ($key)
{
if (isset ($this->m_e[$key]))
{
return $this->m_e[$key];
}
}
function offsetUnset ($key)
{
unset ($this->m_e[$key]);
}
function offsetExists ($key)
{
return isset ($this->m_e[$key]);
}
function getIterator ()
{
return new ArrayIterator($this->m_e);
}
}
$o = new O();
$o->a = new A(array(1, 2, 3));
foreach ($o->a as $e)
{
echo "$e ";
}
[2004-10-13 14:05:03] info at pandora-web dot de
Another Test Case:
---
class TestClass {
private $_p = array();
public function __get($propName){
return $this->_p[$propName];
}
public function __set($propName, $propValue){
$this->_p[$propName] = $value;
}
}
$a = new TestClass();
$a->testVar = 'test';
print $a->testVar; //--> 'test'
$a->testVar = new TestClass();
$a->testVar->testVar = 'test2';
// __set of $a->testVar called instead
of getter of $a->testVar and setter of $a->testVar->testVar
Solution Hint:
I think I is better to call the __get method of the first objects and
than call the __set method of the last one in chain. Like you with
__call.
[2004
#28444 [Com]: "Cannot access undefined property for object with overloaded property access"
ID: 28444
Comment by: keithm at aoeex dot com
Reported By: dennis at inmarket dot lviv dot ua
Status: Assigned
Bug Type: Class/Object related
Operating System: WinXP
PHP Version: 5.0.0RC2
Assigned To: andi
New Comment:
Ok, just wanted to add that I figured my problem out, and you might be
able to just consider it user error. Apparently calling unset on a
property of a class makes that property no longer valid for that class,
rather than just giving it an empty value and free'ing the memory for
it's contents like I had thought. Not sure if this is intentional or
not (does kind of make sense) but anyway removing the
unset($this->minput) line from my function and it started working
again.
Previous Comments:
[2005-01-11 08:03:24] keithm at aoeex dot com
I ran into this problem also, but slighly differently. In my case, the
first property I'm accessing is a validly declared and set property of
the class, instead of set using __set or read using __get. I've tried
to reproduce it using simpler code, but I can't seem to get it done.
The actual code I'm using is far too complex for a bug report
submission (it's a customized DOM implemtation)
I'll see if I can describe it at all. Basically I have the following
classes that are involved:
abstract class Node -- Does define __set/__get
abstract class HTMLElement extends Node -- Does define __set/__get
class HTMLInputElement extends HTMLElement -- Does define __set/__get
class FormElement extends HTMLElement -- Does NOT define __set/__get
Now, the FormElement class has variable declarations like so:
private $minput;
private $mlabel;
private $mlplacement;
private $container;
$minput is eventuall an instance of HTMLInputElement when this error
occurs. Here is the relevent part of the formElement->setInputType
function
public function setInputType($xtype){
unset($this->minput);
switch ($xtype){
..
case 'radio': case 'text': case 'entry': case
'button': case 'image': case 'submit': case 'reset': case 'checkbox':
$this->minput=$this->ownerDocument->createElement('INPUT');
/* as of this point, $this->minput is a valid HTMLInputElement
instance, verified w/ print_r */
$this->minput->type = $xtype;
break;
...
}
When that method is called, I receive the error in question on the
line: $this->minput->type = $xtype;
I'll keep trying to come up with simpler code that reproduces the bug,
but if anyone does want to view the big code (maybe for clarity) it is
available at
http://wiser.kicks-ass.org:8008/PHPDOM/PHPDOM-error.tar.gz
My PHP version is 5.0.2, and I can reproduce with both the CLI and
Apache 2 Module. Operating systems Both FreeBSD and Linux 2.6.9
[2004-11-08 20:05:09] php at rodric dot org
I ran into this in a slightly different way -- trying to
foreach through an ArrayAccess object. Interestingly,
removing the __set from class O allows this to work.
class O
{
private $m_a = array();
function __get ($key)
{
return $this->m_a[$key];
}
function __set ($key, $val)
{
$this->m_a[$key] = $val;
}
}
class A implements ArrayAccess, IteratorAggregate
{
private $m_e = array();
function __construct ($e = NULL)
{
$this->m_e = is_null ($e) ? array() : $e;
}
function offsetSet ($key, $value)
{
$this->m_e[$key] = $value;
}
function offsetGet ($key)
{
if (isset ($this->m_e[$key]))
{
return $this->m_e[$key];
}
}
function offsetUnset ($key)
{
unset ($this->m_e[$key]);
}
function offsetExists ($key)
{
return isset ($this->m_e[$key]);
}
function getIterator ()
{
return new ArrayIterator($this->m_e);
}
}
$o = new O();
$o->a = new A(array(1, 2, 3));
foreach ($o->a as $e)
{
echo "$e ";
}
[2004-10-13 14:05:03] info at pandora-web dot de
Another Test Case:
---
class TestClass {
private $_p = array();
public function __get($propName){
return $this->_p[$propName];
}
public function __set($propName, $p
#27409 [NEW]: Comparison order of operations incorrect
From: keithm at aoeex dot com Operating system: Linux PHP version: 5CVS-2004-02-26 (dev) PHP Bug Type: Scripting Engine problem Bug description: Comparison order of operations incorrect Description: The order of operation for comparisons seems to be incorrect. The following example script will demonstrate the problem: Reproduce code: --- Expected result: The screen should display nothing. I would expect that the $x=5 would execute, and then php would compare $x != $x, which of course would be false, and the loop would run. Actual result: -- x is not equal to x the loop is executed and that echo statement is displayed. It seems that php pulls the value of $x, execute the $x=5 statement, and runs the comparison. So for a split second, you in essence have two $x variables. One which has the value of 0, and the other with the value of 5. If you reverse the order of the operands in the condition, then it works as expected: -- Edit bug report at http://bugs.php.net/?id=27409&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27409&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27409&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27409&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27409&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27409&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27409&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27409&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27409&r=support Expected behavior: http://bugs.php.net/fix.php?id=27409&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27409&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27409&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27409&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27409&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27409&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27409&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27409&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27409&r=float
#25725 [Com]: highlight_string doesn't parse strings containing \ properly
ID: 25725
Comment by: keithm at aoeex dot com
Reported By: kjartan at zind dot net
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 4CVS, 5CVS
New Comment:
This bug is not bogus. We are experiencing it semi-randomly with our
pastebin code at http://dalphp.shoggoth.net/pastebin.php
(http://dalphp.shoggoth.net/pastebin_view.php?356 is one post being
affected)
The code that is paste is generating the warning for \'s which are
valid. In this case, the \ in the \n in the print statements.
Here's some debugging code/output I added to see if this was a bug or
not.
-=-=-= code -=-=-=-=-
$src=implode("\n", $Source);
echo '';
if (strpos($src, '';
$source=str_replace(array('', ''), '', $source);
}
else {
$source=nl2br(htmlentities($src));
}
echo $src;
-=-=-=-=-=-=-=-=-=-=-
-=-=-= output -=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
As you can see, the highlight_string call is causing the warning to be
injected into the source where they should not be. The code is fine
under normal circumstances.
Previous Comments:
[2003-10-02 20:56:57] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The warning you are seeing is a lexical parser warning, it cannot be
avoided simply because it is the same parser as the one parsing normal
PHP source. If PHP were to execute the file it too would strip/ignore
the \ character.
[2003-10-02 17:03:45] kjartan at zind dot net
Doing @highlight_string seems to work to, but it strips the \. Might
not fixing, but it still seems like a bug.
[2003-10-02 16:51:07] [EMAIL PROTECTED]
If you just want to suppress warnings, error_reporting(0) might help
you. I'm not sure if this needs to be fixed anyhow though...
[2003-10-02 07:17:27] kjartan at zind dot net
Description:
Given a string that contains this PHP code:
Then highlight_string() generates this:
Granted its not valid PHP, but should hightlight_string() function as a
PHP validation system? Not that it does a good job at it as this gets
colored just fine:
What gives?
Reproduce code:
---
';
highlight_string($string);
Expected result:
I expect it to just leave the \ alone and not cause warnings.
--
Edit this bug report at http://bugs.php.net/?id=25725&edit=1
[PHP-BUG] Bug #62707 [NEW]: nextRowset causes segfault when using libmysql
From: keithm at aoeex dot com
Operating system: Linux
PHP version: 5.4.5
Package: PDO related
Bug Type: Bug
Bug description:nextRowset causes segfault when using libmysql
Description:
Using PDO with the MySQL driver built using libmysql
pdo_mysql
PDO Driver for MySQL => enabled
Client API version => 5.5.25a
After calling a stored procedure I have the following lines to eat up the
results before running more queries:
do { try { $queueStmt->fetch(); } catch (Exception $e){} } while
($queueStmt-
>nextRowset());
When using libmysql this results in a segfault when calling nextRowset.
Test script:
---
"SET NAMES utf8"));
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$sql = 'DROP TABLE IF EXISTS testtbl';
$db->exec($sql);
$sql = 'DROP PROCEDURE IF EXISTS testproc';
$db->exec($sql);
$sql = 'CREATE TABLE testtbl (pk INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
data VARCHAR(10), nextrun DATETIME)';
$db->exec($sql);
$sql = "INSERT INTO testtbl (data, nextrun) VALUES ('asdf',
UTC_TIMESTAMP()),('defg', UTC_TIMESTAMP()),('higk',
UTC_TIMESTAMP()),('lmnop', UTC_TIMESTAMP())";
$db->exec($sql);
$sql = 'CREATE PROCEDURE testproc() NOT DETERMINISTIC MODIFIES SQL DATA
BEGIN DECLARE nextId INT; SELECT pk INTO nextId FROM testtbl WHERE
nextrun=(SELECT MIN(nextrun) FROM testtbl) LIMIT 1; UPDATE testtbl SET
nextrun=UTC_TIMESTAMP()+INTERVAL 1 DAY WHERE pk=nextId; SELECT * FROM
testtbl WHERE pk=nextId; END';
$db->exec($sql);
$queueSql = 'CALL testproc()';
$queueStmt = $db->prepare($queueSql);
$queueStmt->execute();
$row=$queueStmt->fetch(PDO::FETCH_ASSOC);
do { try { $queueStmt->fetch(); } catch (Exception $e){} } while
($queueStmt->nextRowset());
echo "Success";
Expected result:
Success
Actual result:
--
Segmentation fault
--
Edit bug report at https://bugs.php.net/bug.php?id=62707&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62707&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62707&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62707&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62707&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62707&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62707&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62707&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62707&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62707&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62707&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62707&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62707&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62707&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62707&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62707&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62707&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62707&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62707&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62707&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62707&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62707&r=mysqlcfg
Bug #62724 [Com]: isset returns false but array_key_exists returns true (int keys)
Edit report at https://bugs.php.net/bug.php?id=62724&edit=1 ID: 62724 Comment by: keithm at aoeex dot com Reported by:max at kriegt dot es Summary:isset returns false but array_key_exists returns true (int keys) Status: Open Type: Bug Package:Arrays related Operating System: Debian 6 PHP Version:5.4.5 Block user comment: N Private report: N New Comment: This is not a bug. From the manual page on isset: "Determine if a variable is set and is not NULL." In your example, $foo[0] is null which is why isset returns false. Previous Comments: [2012-08-02 09:36:54] max at kriegt dot es Description: Hi, recently realized that isset not returning the same result as array_key_exists does for int-Keys. Test script: --- https://bugs.php.net/bug.php?id=62724&edit=1
Req #62745 [Com]: Extend echo and print possiblity
Edit report at https://bugs.php.net/bug.php?id=62745&edit=1
ID: 62745
Comment by: keithm at aoeex dot com
Reported by:kjelkenes at gmail dot com
Summary:Extend echo and print possiblity
Status: Open
Type: Feature/Change Request
Package:Unknown/Other Function
Operating System: *
PHP Version:5.4.5
Block user comment: N
Private report: N
New Comment:
You can already accomplish this using output buffering if so desired. I don't
see a need to add anything else into the mix. For example:
--
alert(\'This will never be executed.\')';
--
outputs:
<script>alert('This will never be executed.')</script>
Previous Comments:
[2012-08-04 14:13:55] kjelkenes at gmail dot com
Description:
This is a feature request regarding the "echo" and "print" functions used in
PHP. The echo/print statement is used for output. As of today there are no way
of extending these statements, leading to potential security risks.
If we could extend the echo function at a given time with a handler/closure
this could really improve the security of PHP.
Say we have the following security risk (XSS injection):
$data = "alert('hi');"; // From db.
echo $data;
Today we need custom functions to escape this such as:
function escape($data){
return htmlspecialchars($data, ENT_QUOTES, 'UTF-8');
}
echo escape($data);
What if we could implement a handler for the echo/print statements such as this:
// Define a handler:
$outputHandler = function escape($data){
return htmlspecialchars($data, ENT_QUOTES, 'UTF-8');
};
/**
* Sets a output handler for php, it's used in echo and print statements.
* @param string $name The identity of this handler ( Unique )
* @param mixed $outputHandler function name or callback closure to use.
* @param mixed $flags What type of satements to use this function.
*/
add_output_handler('xss_filter',$outputHandler, OutputHandler::F_ECHO |
OutputHandler::F_PRINT);
/**
* Removes a given output handler by it's name.
*/
remove_output_handler('xss_filter');
Then we could use normal statements:
echo 'alert('This will never be exected.')';
And when we don't need it anymore:
remove_output_handler('xss_filter');
This way, one can be sure that the output of ANY kind is actually stripped,
without implementing a whole new templating system for PHP.
Also this does not break any kind of PHP applications running, it just adds new
functionality that is (let's face it) really needed for PHP.
This is also great for MVC frameworks, just apply it before executing a view
file and remove it after!
--
Edit this bug report at https://bugs.php.net/bug.php?id=62745&edit=1
[PHP-BUG] Req #52281 [NEW]: New Unref function - breaks reference between variables.
From: Operating system: PHP version: Irrelevant Package: Unknown/Other Function Bug Type: Feature/Change Request Bug description:New Unref function - breaks reference between variables. Description: An addition to PHP that would be nice is a way to break a reference between two variables, without destroying them. Currently, the only way I found to break a reference is to use unset($var), however this causes the variable to be destroyed which causes can cause undesirable side-effects on classes. Suggested function: unref($var) - Removes references from $var. The function would give $var whatever value it currently has via it's reference, and then removes the reference. Test script: --- Example of problem prompting this: See: http://www.aoeex.com/extras/unref.php Pastebin (in-case main url is down): http://pastebin.com/BtWeasC1 -- Edit bug report at http://bugs.php.net/bug.php?id=52281&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52281&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52281&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52281&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52281&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52281&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52281&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52281&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52281&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52281&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52281&r=support Expected behavior: http://bugs.php.net/fix.php?id=52281&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52281&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52281&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52281&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52281&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52281&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52281&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52281&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52281&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52281&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52281&r=mysqlcfg
Bug #34028 [Com]: socket_create_listen doesn't listen on all interfaces
Edit report at http://bugs.php.net/bug.php?id=34028&edit=1 ID: 34028 Comment by: keithm at aoeex dot com Reported by:alex at cedevices dot com Summary:socket_create_listen doesn't listen on all interfaces Status: No Feedback Type: Bug Package:Sockets related Operating System: Windows 2000 PHP Version:5.0.4 Block user comment: N Private report: N New Comment: Same issue. Small test script: === php -v PHP 5.3.99-dev (cli) (built: May 15 2011 09:31:01) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2011 Zend Technologies (also fails in 5.3.6 release) After running the script above: === C:\Users\Keith>netstat -nap tcp Active Connections Proto Local Address Foreign AddressState [..snip..] TCP127.0.0.1:5900 0.0.0.0:0 LISTENING C:\Users\Keith>nc -v 127.0.0.1 5900 sleek [127.0.0.1] 5900 (?) open Testing You said: Testing 123 You said: 123 bye You said: bye C:\Users\Keith>nc -v 192.168.0.6 5900 sleek [192.168.0.6] 5900 (?): connection refused Previous Comments: [2007-03-13 06:36:34] mayank_1 at yahoo dot com i am using php 5.0.4 Ver. and i want to broad cast msg in local network using php so i am using this function $socket = socket_create(AF_INET, SOCK_DGRAM, SOL_UDP); but if i am run this php file then generat error on page this Fatal error: Call to undefined function socket_create() in C:\Program Files\Apache Group\Apache2\htdocs\mayank\socket\examp1.php on line 3 what i do for it pls reply me [2006-08-03 13:27:50] jarcarlos at sapo dot pt I have the same problem with PHP 5.1.4 version. The soket can't receive connections from internet, but can do it in local network. But when i put 0.0.0.0 in address socket_bind I begin to receive connections. In some (many) connections i receive warning in socket_write and socket_read because "unable to write/read from socket [0]". My operating system is: Windows XP. [2005-08-15 01:00:04] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-08-07 21:21:29] tony2...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2005-08-07 20:43:15] alex at cedevices dot com Description: Standard latest xampp setup (including PHP 5.0.4). When using socket_create_listen(port), it does not listen on all interfaces as the docs indicate that it would. I was unable to connect to the machine using anything other than localhost (127.0.0.1). The workaround is to use socket_create, socket_bind (with 0.0.0.0 as the address) and socket_listen to accomplish the same task. -- Edit this bug report at http://bugs.php.net/bug.php?id=34028&edit=1
[PHP-BUG] Bug #55374 [NEW]: DOMDocument::LoadHTMLFile fails with %xx sequences in filename.
From:
Operating system: Linux
PHP version: 5.4.0alpha3
Package: DOM XML related
Bug Type: Bug
Bug description:DOMDocument::LoadHTMLFile fails with %xx sequences in filename.
Description:
DOMDocument::LoadHTMLFile appears to urldecode it's argument, which causes
problems when attempting to load a file containing a %xx sequence.
This issue was brought up on ##php in freenode when someone was attempting
to load
a file named 'Linux_Files%2Fetc%2Fbash.bashrc.html'. Suggested work around
was to
use LoadHTML + file_get_contents instead.
There was a small debate over whether this is a bug, or just a
documentation
problem (perhaps LoadHTMLFile expects a URL).
DOMDocument::Load() is also affected.
Test script:
---
Contents of 'Linux_Files%2Fetc%2Fbash.bashrc.html'
---8<---
---8<---
contents of 'test.php'
---8<---
loadHTMLFile($file);
var_dump($doc->getElementsByTagName('body')->length);
echo str_repeat('-', 80), "\r\n";
$doc2 = new DOMDocument();
$doc2->loadHTMLFile(urlencode($file));
var_dump($doc2->getElementsByTagName('body')->length);
---8<---
Expected result:
Expect the ->loadHTMLFile($file) to succeed and the -
>loadHTMLFile(urlencode($file)) to fail with a file-not-found type error.
Actual result:
--
->loadHTMLFile($file) failes with errors:
PHP Warning: DOMDocument::loadHTMLFile(): I/O warning : failed to load
external
entity "Linux_Files%2Fetc%2Fbash.bashrc.html" in /home/kicken/test.php on
line 6
Warning: DOMDocument::loadHTMLFile(): I/O warning : failed to load external
entity
"Linux_Files%2Fetc%2Fbash.bashrc.html" in /home/kicken/test.php on line 6
->loadHTMLFile(urlencode($file)) succeeds.
--
Edit bug report at https://bugs.php.net/bug.php?id=55374&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55374&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55374&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55374&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55374&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55374&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55374&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55374&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55374&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55374&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55374&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55374&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55374&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55374&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55374&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55374&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55374&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55374&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55374&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55374&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55374&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55374&r=mysqlcfg
