#41218 [NEW]: mysql_query

[dailu at mail dot ru]

From: dailu at mail dot ru
Operating system: Windows XP Pro
PHP version:  5.2.1
PHP Bug Type: MySQL related
Bug description:  mysql_query

Description:

Table is empty. I insert one record in table. In spite that table contain
two equal records, although at output record is single. I used mysql
5.0.20.

P.S.: I'm from Russia, sorry for my english..

Reproduce code:
---
mysql_connect('localhost', 'root', NULL);
mysql_select_db('localhost');

echo '  Before:';
$result = mysql_query('SELECT * FROM `documents`');
while($array = mysql_fetch_assoc($result))
printf('%d.%d %s', $array['id'], $array['id_branch'],
$array['name']);

// Table is empty
mysql_query("INSERT INTO `documents` (`id`,`id_branch`,`name`) VALUES
(NULL, 1, 'Record2')");
echo '  After:';
$result = mysql_query('SELECT * FROM `documents`');
while($array = mysql_fetch_assoc($result))
printf('%d.%d %s', $array['id'], $array['id_branch'],
$array['name']);

Expected result:

  Before:
  After:
1.1 Record2


-- 
Edit bug report at http://bugs.php.net/?id=41218&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=41218&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=41218&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=41218&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41218&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=41218&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=41218&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41218&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41218&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=41218&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41218&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=41218&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=41218&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41218&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=41218&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41218&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41218&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=41218&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=41218&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=41218&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41218&r=mysqlcfg

#41217 [Opn->Bgs]: Print statement related bug

[tony2001]

 ID:   41217
 Updated by:   [EMAIL PROTECTED]
 Reported By:  skchandon at skchandon dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Output Control
 Operating System: Windows IIS ISAPi DLL
 PHP Version:  5.2.1
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.




Previous Comments:


[2007-04-27 19:19:45] skchandon at skchandon dot com

Description:

The following code generates error:
something again 
BODYHTML;(space/tab character)
?>
the above code generates the following error:

Parse error: parse error, unexpected T_SL in
C:\php_prog\toad\test\bug_test.php on line 3

Removing the space characters gets rid of the problem.



Reproduce code:
---
something again 
BODYHTML;(space/tab character)
?>

Expected result:

this is something oh yeah something again 

Actual result:
--
Parse error: parse error, unexpected T_SL in
C:\php_prog\toad\test\bug_test.php on line 3





-- 
Edit this bug report at http://bugs.php.net/?id=41217&edit=1

#41217 [NEW]: Print statement related bug

[skchandon at skchandon dot com]

From: skchandon at skchandon dot com
Operating system: Windows IIS ISAPi DLL
PHP version:  5.2.1
PHP Bug Type: Output Control
Bug description:  Print statement related bug

Description:

The following code generates error:
something again 
BODYHTML;(space/tab character)
?>
the above code generates the following error:

Parse error: parse error, unexpected T_SL in
C:\php_prog\toad\test\bug_test.php on line 3

Removing the space characters gets rid of the problem.



Reproduce code:
---
something again 
BODYHTML;(space/tab character)
?>

Expected result:

this is something oh yeah something again 

Actual result:
--
Parse error: parse error, unexpected T_SL in
C:\php_prog\toad\test\bug_test.php on line 3

-- 
Edit bug report at http://bugs.php.net/?id=41217&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=41217&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=41217&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=41217&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41217&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=41217&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=41217&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41217&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41217&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=41217&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41217&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=41217&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=41217&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41217&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=41217&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41217&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41217&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=41217&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=41217&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=41217&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41217&r=mysqlcfg

#41216 [Opn->Bgs]: PCRE_UTF8 slows down 30 times

[tony2001]

 ID:   41216
 Updated by:   [EMAIL PROTECTED]
 Reported By:  DPP 
-Status:   Open
+Status:   Bogus
 Bug Type: PCRE related
 Operating System: WinXPsp2
 PHP Version:  5.2.1
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.




Previous Comments:


[2007-04-27 17:33:54] DPP 

Forgot to say: file contain russian text encoded in UTF-8.
Without PCRE_UTF8 modifier regexp falls on russian letter "R".



[2007-04-27 17:26:59] DPP 

Description:

Parsing file with 1 lines of following format:

level + delim + [EMAIL PROTECTED]@ + delim +] tag + [delim + line_value +]
terminator

level   digit
delim   space
xref_id alphanum
tag alpha (english)
line_value  any (except terminator)
terminator  \r\n

With regexp:

$c=preg_match_all("/^\s*(\d+)\s+(@(\S+)@\s+)?(\w+)(\s+@(\S+)@\s*|.*)?$/Sm",$fp,$m,PREG_PATTERN_ORDER);

Setting PCRE_UTF8 modifier slows whole script down 30 times (from 300ms
to 9000ms).

May be more accurate regexp here will be
$c=preg_match_all("/^ *(\d+) +(@([EMAIL PROTECTED])@ +)?([^ \\n]+)(
+@([EMAIL PROTECTED])@ *| +[^\\n]*)?$/m",$fp,$m,PREG_PATTERN_ORDER);
But it changes nothing.






-- 
Edit this bug report at http://bugs.php.net/?id=41216&edit=1

#41216 [Opn]: PCRE_UTF8 slows down 30 times

[DPP]

 ID:   41216
 User updated by:  DPP 
 Reported By:  DPP 
 Status:   Open
 Bug Type: PCRE related
 Operating System: WinXPsp2
 PHP Version:  5.2.1
 New Comment:

Forgot to say: file contain russian text encoded in UTF-8.
Without PCRE_UTF8 modifier regexp falls on russian letter "R".


Previous Comments:


[2007-04-27 17:26:59] DPP 

Description:

Parsing file with 1 lines of following format:

level + delim + [EMAIL PROTECTED]@ + delim +] tag + [delim + line_value +]
terminator

level   digit
delim   space
xref_id alphanum
tag alpha (english)
line_value  any (except terminator)
terminator  \r\n

With regexp:

$c=preg_match_all("/^\s*(\d+)\s+(@(\S+)@\s+)?(\w+)(\s+@(\S+)@\s*|.*)?$/Sm",$fp,$m,PREG_PATTERN_ORDER);

Setting PCRE_UTF8 modifier slows whole script down 30 times (from 300ms
to 9000ms).

May be more accurate regexp here will be
$c=preg_match_all("/^ *(\d+) +(@([EMAIL PROTECTED])@ +)?([^ \\n]+)(
+@([EMAIL PROTECTED])@ *| +[^\\n]*)?$/m",$fp,$m,PREG_PATTERN_ORDER);
But it changes nothing.






-- 
Edit this bug report at http://bugs.php.net/?id=41216&edit=1

#41216 [NEW]: PCRE_UTF8 slows down 30 times

[DPP]

From: DPP 
Operating system: WinXPsp2
PHP version:  5.2.1
PHP Bug Type: PCRE related
Bug description:  PCRE_UTF8 slows down 30 times

Description:

Parsing file with 1 lines of following format:

level + delim + [EMAIL PROTECTED]@ + delim +] tag + [delim + line_value +]
terminator

level   digit
delim   space
xref_id alphanum
tag alpha (english)
line_value  any (except terminator)
terminator  \r\n

With regexp:

$c=preg_match_all("/^\s*(\d+)\s+(@(\S+)@\s+)?(\w+)(\s+@(\S+)@\s*|.*)?$/Sm",$fp,$m,PREG_PATTERN_ORDER);

Setting PCRE_UTF8 modifier slows whole script down 30 times (from 300ms to
9000ms).

May be more accurate regexp here will be
$c=preg_match_all("/^ *(\d+) +(@([EMAIL PROTECTED])@ +)?([^ \\n]+)( +@([EMAIL 
PROTECTED])@
*| +[^\\n]*)?$/m",$fp,$m,PREG_PATTERN_ORDER);
But it changes nothing.


-- 
Edit bug report at http://bugs.php.net/?id=41216&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=41216&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=41216&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=41216&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41216&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=41216&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=41216&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41216&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41216&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=41216&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41216&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=41216&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=41216&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41216&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=41216&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41216&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41216&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=41216&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=41216&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=41216&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41216&r=mysqlcfg

#41215 [Opn->Asn]: setAttribute return code reversed

[tony2001]

 ID:   41215
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jerry at gii dot co dot jp
-Status:   Open
+Status:   Assigned
 Bug Type: PDO related
 Operating System: WinXP Home SP2
 PHP Version:  5.2.1
-Assigned To:  
+Assigned To:  iliaa


Previous Comments:


[2007-04-27 17:11:29] jerry at gii dot co dot jp

I purposely didn't show the values of the parameters for the opening of
the data base, but trust me that they are correct.



[2007-04-27 17:09:13] jerry at gii dot co dot jp

Description:

dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION)

returns FALSE on success and TRUE on failure. This is the reverse of
the documentation (and counter-intuitive).

The data base server is MySQL 4.1.21-standard running on CentOS 3.

Reproduce code:
---
setAttribute(PDO::ATTR_ERRMODE,
PDO::ERRMODE_EXCEPTION);
$errmode = $dbh->getAttribute(PDO::ATTR_ERRMODE);
echo ($r_code ? "TRUE" : "FALSE") . " | " . $errmode;
?>


Expected result:

It should echo

TRUE | 2

Actual result:
--
FALSE | 2





-- 
Edit this bug report at http://bugs.php.net/?id=41215&edit=1

#41214 [Bgs]: referencing a reference parameter on a function-local variable does not work

[php at warhog dot net]

 ID:   41214
 User updated by:  php at warhog dot net
 Reported By:  php at warhog dot net
 Status:   Bogus
 Bug Type: Variables related
 Operating System: Linux (Ubuntu 6.10/Linux 2.6.17)
 PHP Version:  5.2.1
 New Comment:

Same thing in PHP 5.1.6 (from the official ubuntu repositories).

I thought about the problem and considered the fact that a local 
variable vanishes when the function is done... so I tried the same 
with a static variable.. but it didn't work either:



Expected:
-

int(1)
int(1)
int(1)
int(2)
int(3)
int(3)

Actual Result:
--

int(1)
int(1)
NULL
int(2)
int(3)
int(2)


Previous Comments:


[2007-04-27 17:11:24] [EMAIL PROTECTED]

You're creating a reference to the variable that exists only in the
function scope.



[2007-04-27 17:04:28] php at warhog dot net

Description:

When having a reference-variable as parameter in a function and 
referencing it on a local variable (inside the function) the 
variable will keep the referenced value inside the function but not 
outside. That's not the way I understand references in PHP.

Reproduce code:
---



Expected result:

int(3)
int(3)


Actual result:
--
int(3)
NULL






-- 
Edit this bug report at http://bugs.php.net/?id=41214&edit=1

#41215 [Opn]: setAttribute return code reversed

[jerry at gii dot co dot jp]

 ID:   41215
 User updated by:  jerry at gii dot co dot jp
 Reported By:  jerry at gii dot co dot jp
 Status:   Open
 Bug Type: PDO related
 Operating System: WinXP Home SP2
 PHP Version:  5.2.1
 New Comment:

I purposely didn't show the values of the parameters for the opening of
the data base, but trust me that they are correct.


Previous Comments:


[2007-04-27 17:09:13] jerry at gii dot co dot jp

Description:

dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION)

returns FALSE on success and TRUE on failure. This is the reverse of
the documentation (and counter-intuitive).

The data base server is MySQL 4.1.21-standard running on CentOS 3.

Reproduce code:
---
setAttribute(PDO::ATTR_ERRMODE,
PDO::ERRMODE_EXCEPTION);
$errmode = $dbh->getAttribute(PDO::ATTR_ERRMODE);
echo ($r_code ? "TRUE" : "FALSE") . " | " . $errmode;
?>


Expected result:

It should echo

TRUE | 2

Actual result:
--
FALSE | 2





-- 
Edit this bug report at http://bugs.php.net/?id=41215&edit=1

#41214 [Opn->Bgs]: referencing a reference parameter on a function-local variable does not work

[tony2001]

 ID:   41214
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php at warhog dot net
-Status:   Open
+Status:   Bogus
 Bug Type: Variables related
 Operating System: Linux (Ubuntu 6.10/Linux 2.6.17)
 PHP Version:  5.2.1
 New Comment:

You're creating a reference to the variable that exists only in the
function scope.


Previous Comments:


[2007-04-27 17:04:28] php at warhog dot net

Description:

When having a reference-variable as parameter in a function and 
referencing it on a local variable (inside the function) the 
variable will keep the referenced value inside the function but not 
outside. That's not the way I understand references in PHP.

Reproduce code:
---



Expected result:

int(3)
int(3)


Actual result:
--
int(3)
NULL






-- 
Edit this bug report at http://bugs.php.net/?id=41214&edit=1

#41215 [NEW]: setAttribute return code reversed

[jerry at gii dot co dot jp]

From: jerry at gii dot co dot jp
Operating system: WinXP Home SP2
PHP version:  5.2.1
PHP Bug Type: PDO related
Bug description:  setAttribute return code reversed

Description:

dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION)

returns FALSE on success and TRUE on failure. This is the reverse of the
documentation (and counter-intuitive).

The data base server is MySQL 4.1.21-standard running on CentOS 3.

Reproduce code:
---
setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$errmode = $dbh->getAttribute(PDO::ATTR_ERRMODE);
echo ($r_code ? "TRUE" : "FALSE") . " | " . $errmode;
?>


Expected result:

It should echo

TRUE | 2

Actual result:
--
FALSE | 2

-- 
Edit bug report at http://bugs.php.net/?id=41215&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=41215&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=41215&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=41215&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41215&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=41215&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=41215&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41215&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41215&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=41215&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41215&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=41215&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=41215&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41215&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=41215&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41215&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41215&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=41215&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=41215&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=41215&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41215&r=mysqlcfg

#41214 [NEW]: referencing a reference parameter on a function-local variable does not work

[php at warhog dot net]

From: php at warhog dot net
Operating system: Linux (Ubuntu 6.10/Linux 2.6.17)
PHP version:  5.2.1
PHP Bug Type: Variables related
Bug description:  referencing a reference parameter on a function-local 
variable does not work

Description:

When having a reference-variable as parameter in a function and 
referencing it on a local variable (inside the function) the 
variable will keep the referenced value inside the function but not 
outside. That's not the way I understand references in PHP.

Reproduce code:
---



Expected result:

int(3)
int(3)


Actual result:
--
int(3)
NULL


-- 
Edit bug report at http://bugs.php.net/?id=41214&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=41214&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=41214&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=41214&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41214&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=41214&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=41214&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41214&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41214&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=41214&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41214&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=41214&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=41214&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41214&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=41214&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41214&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41214&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=41214&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=41214&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=41214&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41214&r=mysqlcfg

#41204 [Asn]: DOMDocument::loadXML() fails when entities included in string

[jazzslider at gmail dot com]

 ID:   41204
 User updated by:  jazzslider at gmail dot com
 Reported By:  jazzslider at gmail dot com
 Status:   Assigned
 Bug Type: DOM XML related
 Operating System: Linux
 PHP Version:  5.2.1
 Assigned To:  rrichards
 New Comment:

Also...the fact that adding a DOCTYPE makes it work better when loading
XML from a string doesn't explain why no DOCTYPE is needed when the
entity reference is inserted using createEntityReference() and
appendChild().


Previous Comments:


[2007-04-27 14:24:54] jazzslider at gmail dot com

Further observation:

The problem is solved partially by adding a custom DTD reference to the
beginning of the string (after the  processing instruction)
containing mainly entity declarations.

When this is done, the only unexpected behavior left is that, if the
XML string contains the " entity, it WILL be substituted...i.e.,
the XML string:

===
<...PI and DOCTYPE...>"Hello!" This & that
are my very favorite things.
===

will, after loadXML()ing it into a new DOMDocument(), cause saveXML()
to produce the following output:

===
<...PI and DOCTYPE...>"Hello!" This & that are my very
favorite things.
===

(this is all assuming, of course, that the DOCTYPE declaration includes
all of the entities in the string in keeping with how they are
conventionally understood in HTML)

It is strange that the " entity should be automatically
substituted while none of the others are.  It would make more sense to
me if NONE of the entities were substituted; that's the behavior I'm
looking for.



[2007-04-26 16:42:35] jazzslider at gmail dot com

Description:

When using loadXML() to fill in a DOMDocument object from a
pre-existing XML string, entity references will cause the method to
fail, even though there does not seem to be a way to explicitly define
such entity references in the document prior to calling loadXML(), nor
does it seem to be necessary to do so when creating the same document
via DOMDocument methods directly.

Also note: I am using PHP 5.2.0-8, and cannot upgrade to 5.2.1 since my
site is on a shared server.

Reproduce code:
---
DOMDocument Entity Test
Created Via DOM Methods

createElement('span', 'This is the sample span.');
$dd1_root = $dd1->appendChild($dd1_root);
$dd1_nbsp = $dd1->createEntityReference('nbsp');
$dd1_nbsp = $dd1_root->appendChild($dd1_nbsp);
$str = $dd1->saveXML();
echo $str;
?>

Loaded From String
loadXML($str);
echo $dd2->saveXML();
?>

Expected result:

The content of the "Created Via DOM Methods" section should be
identical to the content of the "Loaded From String" section.

Actual result:
--
With warnings enabled, the following message appears:

"Warning: DOMDocument::loadXML() [function.DOMDocument-loadXML]: Entity
'nbsp' not defined in Entity, line: 2 in ..."





-- 
Edit this bug report at http://bugs.php.net/?id=41204&edit=1

#41213 [Opn->Bgs]: Subtracting 2 floats returns incorrect results

[tony2001]

 ID:   41213
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jsbruns at selectionsheet dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Math related
 Operating System: Windows NT Server
 PHP Version:  5.2.1
 New Comment:

Floating point values have a limited precision. Hence a value might 
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly 
printing it without any mathematical operations.

If you would like to know more about "floats" and what IEEE
754 is read this:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
 
Thank you for your interest in PHP.




Previous Comments:


[2007-04-27 13:55:45] jsbruns at selectionsheet dot com

Description:

Attempting to subtract one floating point number from another returns
the incorrect result. Float 1 is assigned in the code, float 2 is
retrieved from a mysql DB field, which is of type DECIMAL(5,4).

When subtracting $float1 from $float2 the result is:
-7.105427357601E-015  

Reproduce code:
---
//Field discount2 is defined as type DECIMAL(5.4). Original value in
database is 0.56, use PHP to multiply by 100 to get a whole number
(56).

$result = mysql_query("SELECT `discount2` 
FROM `product_discounts` 
WHERE `product_id` = 'prod1'"); 

$discount2 = mysql_result($result)*100; 
$discount1 = 56; 

echo $discount1; //56 
echo $discount2; //56 

if ($discount2 != $discount1)
  echo "Discount1 not equal to Discount2"; //Y
if (bccomp($discount1,$discount2) == 0)
  echo "Discount1 equal to Discount2"; //Y


echo ($discount1 + $discount2); //112 
echo ($discount1 - $discount2); //-7.105427357601E-015  


Expected result:

When subtracting $discount1 from $discount2 I expected to get 0. When
adding the two I get the expected 112.

Actual result:
--
When subtracting $discount1 from $discount2 I get:
-7.105427357601E-015  





-- 
Edit this bug report at http://bugs.php.net/?id=41213&edit=1

#41204 [Opn->Asn]: DOMDocument::loadXML() fails when entities included in string

[tony2001]

 ID:   41204
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jazzslider at gmail dot com
-Status:   Open
+Status:   Assigned
 Bug Type: DOM XML related
 Operating System: Linux
 PHP Version:  5.2.1
-Assigned To:  
+Assigned To:  rrichards


Previous Comments:


[2007-04-27 14:24:54] jazzslider at gmail dot com

Further observation:

The problem is solved partially by adding a custom DTD reference to the
beginning of the string (after the  processing instruction)
containing mainly entity declarations.

When this is done, the only unexpected behavior left is that, if the
XML string contains the " entity, it WILL be substituted...i.e.,
the XML string:

===
<...PI and DOCTYPE...>"Hello!" This & that
are my very favorite things.
===

will, after loadXML()ing it into a new DOMDocument(), cause saveXML()
to produce the following output:

===
<...PI and DOCTYPE...>"Hello!" This & that are my very
favorite things.
===

(this is all assuming, of course, that the DOCTYPE declaration includes
all of the entities in the string in keeping with how they are
conventionally understood in HTML)

It is strange that the " entity should be automatically
substituted while none of the others are.  It would make more sense to
me if NONE of the entities were substituted; that's the behavior I'm
looking for.



[2007-04-26 16:42:35] jazzslider at gmail dot com

Description:

When using loadXML() to fill in a DOMDocument object from a
pre-existing XML string, entity references will cause the method to
fail, even though there does not seem to be a way to explicitly define
such entity references in the document prior to calling loadXML(), nor
does it seem to be necessary to do so when creating the same document
via DOMDocument methods directly.

Also note: I am using PHP 5.2.0-8, and cannot upgrade to 5.2.1 since my
site is on a shared server.

Reproduce code:
---
DOMDocument Entity Test
Created Via DOM Methods

createElement('span', 'This is the sample span.');
$dd1_root = $dd1->appendChild($dd1_root);
$dd1_nbsp = $dd1->createEntityReference('nbsp');
$dd1_nbsp = $dd1_root->appendChild($dd1_nbsp);
$str = $dd1->saveXML();
echo $str;
?>

Loaded From String
loadXML($str);
echo $dd2->saveXML();
?>

Expected result:

The content of the "Created Via DOM Methods" section should be
identical to the content of the "Loaded From String" section.

Actual result:
--
With warnings enabled, the following message appears:

"Warning: DOMDocument::loadXML() [function.DOMDocument-loadXML]: Entity
'nbsp' not defined in Entity, line: 2 in ..."





-- 
Edit this bug report at http://bugs.php.net/?id=41204&edit=1

#41204 [Opn]: DOMDocument::loadXML() fails when entities included in string

[jazzslider at gmail dot com]

 ID:   41204
 User updated by:  jazzslider at gmail dot com
 Reported By:  jazzslider at gmail dot com
 Status:   Open
 Bug Type: DOM XML related
 Operating System: Linux
 PHP Version:  5.2.1
 New Comment:

Further observation:

The problem is solved partially by adding a custom DTD reference to the
beginning of the string (after the  processing instruction)
containing mainly entity declarations.

When this is done, the only unexpected behavior left is that, if the
XML string contains the " entity, it WILL be substituted...i.e.,
the XML string:

===
<...PI and DOCTYPE...>"Hello!" This & that
are my very favorite things.
===

will, after loadXML()ing it into a new DOMDocument(), cause saveXML()
to produce the following output:

===
<...PI and DOCTYPE...>"Hello!" This & that are my very
favorite things.
===

(this is all assuming, of course, that the DOCTYPE declaration includes
all of the entities in the string in keeping with how they are
conventionally understood in HTML)

It is strange that the " entity should be automatically
substituted while none of the others are.  It would make more sense to
me if NONE of the entities were substituted; that's the behavior I'm
looking for.


Previous Comments:


[2007-04-26 16:42:35] jazzslider at gmail dot com

Description:

When using loadXML() to fill in a DOMDocument object from a
pre-existing XML string, entity references will cause the method to
fail, even though there does not seem to be a way to explicitly define
such entity references in the document prior to calling loadXML(), nor
does it seem to be necessary to do so when creating the same document
via DOMDocument methods directly.

Also note: I am using PHP 5.2.0-8, and cannot upgrade to 5.2.1 since my
site is on a shared server.

Reproduce code:
---
DOMDocument Entity Test
Created Via DOM Methods

createElement('span', 'This is the sample span.');
$dd1_root = $dd1->appendChild($dd1_root);
$dd1_nbsp = $dd1->createEntityReference('nbsp');
$dd1_nbsp = $dd1_root->appendChild($dd1_nbsp);
$str = $dd1->saveXML();
echo $str;
?>

Loaded From String
loadXML($str);
echo $dd2->saveXML();
?>

Expected result:

The content of the "Created Via DOM Methods" section should be
identical to the content of the "Loaded From String" section.

Actual result:
--
With warnings enabled, the following message appears:

"Warning: DOMDocument::loadXML() [function.DOMDocument-loadXML]: Entity
'nbsp' not defined in Entity, line: 2 in ..."





-- 
Edit this bug report at http://bugs.php.net/?id=41204&edit=1

#41213 [NEW]: Subtracting 2 floats returns incorrect results

[jsbruns at selectionsheet dot com]

From: jsbruns at selectionsheet dot com
Operating system: Windows NT Server
PHP version:  5.2.1
PHP Bug Type: Math related
Bug description:  Subtracting 2 floats returns incorrect results

Description:

Attempting to subtract one floating point number from another returns the
incorrect result. Float 1 is assigned in the code, float 2 is retrieved
from a mysql DB field, which is of type DECIMAL(5,4).

When subtracting $float1 from $float2 the result is:
-7.105427357601E-015  

Reproduce code:
---
//Field discount2 is defined as type DECIMAL(5.4). Original value in
database is 0.56, use PHP to multiply by 100 to get a whole number (56).

$result = mysql_query("SELECT `discount2` 
FROM `product_discounts` 
WHERE `product_id` = 'prod1'"); 

$discount2 = mysql_result($result)*100; 
$discount1 = 56; 

echo $discount1; //56 
echo $discount2; //56 

if ($discount2 != $discount1)
  echo "Discount1 not equal to Discount2"; //Y
if (bccomp($discount1,$discount2) == 0)
  echo "Discount1 equal to Discount2"; //Y


echo ($discount1 + $discount2); //112 
echo ($discount1 - $discount2); //-7.105427357601E-015  


Expected result:

When subtracting $discount1 from $discount2 I expected to get 0. When
adding the two I get the expected 112.

Actual result:
--
When subtracting $discount1 from $discount2 I get:
-7.105427357601E-015  

-- 
Edit bug report at http://bugs.php.net/?id=41213&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=41213&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=41213&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=41213&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41213&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=41213&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=41213&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41213&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41213&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=41213&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41213&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=41213&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=41213&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41213&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=41213&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41213&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41213&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=41213&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=41213&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=41213&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41213&r=mysqlcfg

#40844 [Asn->Bgs]: SSH2.dll libssh update

[edink]

 ID:   40844
 Updated by:   [EMAIL PROTECTED]
 Reported By:  dj02 dot net at nbl dot fi
-Status:   Assigned
+Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: Windows Vista 6.0.6000
 PHP Version:  5.2.2-CVS
 Assigned To:  pollita
 New Comment:

Actually this should be reported to PECL package maintainer.

http://pecl.php.net/bugs/report.php?package=ssh2



Previous Comments:


[2007-04-27 12:58:29] [EMAIL PROTECTED]

The library is bundled in the source. Sara, hope you get some time to
upgrade the lib.



[2007-04-27 08:30:58] dj02 dot net at nbl dot fi

Still not updated



[2007-03-24 08:03:07] dj02 dot net at nbl dot fi

Did you notice my request, edink?



[2007-03-17 18:41:17] dj02 dot net at nbl dot fi

Description:

Hi,

Could you build php_ssh2.dll against latest libssh 2_0.14 libraries?






-- 
Edit this bug report at http://bugs.php.net/?id=40844&edit=1

#40988 [Asn->Sus]: Can't use a sendmail_path with whitespace

[edink]

 ID:   40988
 Updated by:   [EMAIL PROTECTED]
 Reported By:  webmaster at wiedmann-online dot de
-Status:   Assigned
+Status:   Suspended
 Bug Type: Mail related
 Operating System: Windows_NT
 PHP Version:  5.2.1
 Assigned To:  edink
 New Comment:

Problem is with php.ini parser that does not allow " in ini entry
values. Both windows and linux versions are affected. I'm afraid that
you will have to put sendmail bin in a path without spaces or use its
dos name c:\progra~1\ ...



Previous Comments:


[2007-04-05 12:17:28] webmaster at wiedmann-online dot de

> PHP on windows does not use sendmail for sending mails.

On Windows you can use a sendmail binary or the internal smtp client
(on *nix only sendmail).

(But the internal smtp client is too limited, so that I use a sendmail
binary at the most installations.)


> Is this cygwin build?

No. Standard Windows builds.



[2007-04-05 11:22:23] [EMAIL PROTECTED]

PHP on windows does not use sendmail for sending mails. Is this cygwin
build?



[2007-04-04 01:11:33] webmaster at wiedmann-online dot de

Description:

If I have the sendmail binary in a path with a whitespace, PHP can't
open/find this program, because the path is not quotet in the popen call
(mail.c).

On *nix this is not a problem, because on *nix you escape a space with
a backslash (Program\ Files) and don't quote the hole path ("Program
Files") like on Windows. And a backslash I can add myself in php.ini.

BTW:
A 8.3 name (PROGRA~1) will still work on Windows, if it's not disabled
in the NTFS settings.


Reproduce code:
---
[php.ini]
sendmail_path = "C:\Pogram Files\sendmail\sendmail.exe -t"




Expected result:

Mail is send without problems.


Actual result:
--
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.






-- 
Edit this bug report at http://bugs.php.net/?id=40988&edit=1

#40844 [Asn]: SSH2.dll libssh update

[edink]

 ID:   40844
 Updated by:   [EMAIL PROTECTED]
 Reported By:  dj02 dot net at nbl dot fi
 Status:   Assigned
 Bug Type: Feature/Change Request
 Operating System: Windows Vista 6.0.6000
 PHP Version:  5.2.2-CVS
-Assigned To:  edink
+Assigned To:  pollita
 New Comment:

The library is bundled in the source. Sara, hope you get some time to
upgrade the lib.


Previous Comments:


[2007-04-27 08:30:58] dj02 dot net at nbl dot fi

Still not updated



[2007-03-24 08:03:07] dj02 dot net at nbl dot fi

Did you notice my request, edink?



[2007-03-17 18:41:17] dj02 dot net at nbl dot fi

Description:

Hi,

Could you build php_ssh2.dll against latest libssh 2_0.14 libraries?






-- 
Edit this bug report at http://bugs.php.net/?id=40844&edit=1

#41212 [Opn->Fbk]: Invalid http-header in _doRequest

[tony2001]

 ID:   41212
 Updated by:   [EMAIL PROTECTED]
 Reported By:  manrash at gmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: SOAP related
 Operating System: Debian Etch
 PHP Version:  5.2.1
 New Comment:

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 the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.




Previous Comments:


[2007-04-27 12:40:48] manrash at gmail dot com

Description:

The generated header has this content:

Content-Type: application/soap+xml; charset=utf-8;
action="http://www.example.com/ws.asmx";

in place of:

Content-Type: application/soap+xml; charset=utf-8;
SOAPAction: http://www.example.com/ws.asmx


Reproduce code:
---
$soapaction = "http://www.example.com/ws.asmx/method1";;
$msg = "";

$res = $this->proxy->__doRequest
($msg,"http://www.example.com/ws.asmx",$soapaction, 2);








-- 
Edit this bug report at http://bugs.php.net/?id=41212&edit=1

#41212 [NEW]: Invalid http-header in _doRequest

[manrash at gmail dot com]

From: manrash at gmail dot com
Operating system: Debian Etch
PHP version:  5.2.1
PHP Bug Type: SOAP related
Bug description:  Invalid http-header in _doRequest

Description:

The generated header has this content:

Content-Type: application/soap+xml; charset=utf-8;
action="http://www.example.com/ws.asmx";

in place of:

Content-Type: application/soap+xml; charset=utf-8;
SOAPAction: http://www.example.com/ws.asmx


Reproduce code:
---
$soapaction = "http://www.example.com/ws.asmx/method1";;
$msg = "";

$res = $this->proxy->__doRequest
($msg,"http://www.example.com/ws.asmx",$soapaction, 2);




-- 
Edit bug report at http://bugs.php.net/?id=41212&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=41212&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=41212&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=41212&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41212&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=41212&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=41212&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41212&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41212&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=41212&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41212&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=41212&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=41212&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41212&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=41212&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41212&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41212&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=41212&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=41212&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=41212&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41212&r=mysqlcfg

#41150 [Opn->Bgs]: phpinfo() configure option is empty

[tony2001]

 ID:   41150
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php-qa at sebastianmendel dot de
-Status:   Open
+Status:   Bogus
 Bug Type: PHP options/info functions
 Operating System: Red Hat 7.3
 PHP Version:  5.2.2RC1
 New Comment:

'./configure' 'i386-fedora-linux' - this thing was breaking it.


Previous Comments:


[2007-04-27 11:34:20] [EMAIL PROTECTED]

I did, see my reply.



[2007-04-27 11:31:10] php-qa at sebastianmendel dot de

did you recieved email?



[2007-04-27 11:19:42] [EMAIL PROTECTED]

No, I need to reproduce it myself.



[2007-04-27 11:14:35] php-qa at sebastianmendel dot de

nothing has changed on the system

till now i used php5.2-200610021230 where it worked and work perfectly

now i use 5.2.2RC1 where it does not work anymore - also not with 5.2.1
which i tested too


http://www.kfp-online.de/rpm.txt
http://www.kfp-online.de/php-qa.php


does this help?



[2007-04-27 11:05:46] [EMAIL PROTECTED]

What has changed in the system? Where can I reproduce it?



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/41150

-- 
Edit this bug report at http://bugs.php.net/?id=41150&edit=1

#41150 [Opn]: phpinfo() configure option is empty

[tony2001]

 ID:   41150
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php-qa at sebastianmendel dot de
 Status:   Open
 Bug Type: PHP options/info functions
 Operating System: Red Hat 7.3
 PHP Version:  5.2.2RC1
 New Comment:

I did, see my reply.


Previous Comments:


[2007-04-27 11:31:10] php-qa at sebastianmendel dot de

did you recieved email?



[2007-04-27 11:19:42] [EMAIL PROTECTED]

No, I need to reproduce it myself.



[2007-04-27 11:14:35] php-qa at sebastianmendel dot de

nothing has changed on the system

till now i used php5.2-200610021230 where it worked and work perfectly

now i use 5.2.2RC1 where it does not work anymore - also not with 5.2.1
which i tested too


http://www.kfp-online.de/rpm.txt
http://www.kfp-online.de/php-qa.php


does this help?



[2007-04-27 11:05:46] [EMAIL PROTECTED]

What has changed in the system? Where can I reproduce it?



[2007-04-27 10:48:17] php-qa at sebastianmendel dot de

main/build-defs.h:
#define CONFIGURE_COMMAND " './configure'"

same for 5.2.1 - which i tested again now

but it works with php5.2-200610021230
there the #define CONFIGURE_COMMAND line is fine, having the whole
configure command

php5.2-200610021230 was the last version i had running before upgrading
to 5.2.2RC1



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/41150

-- 
Edit this bug report at http://bugs.php.net/?id=41150&edit=1

#41150 [Fbk->Opn]: phpinfo() configure option is empty

[php-qa at sebastianmendel dot de]

 ID:   41150
 User updated by:  php-qa at sebastianmendel dot de
 Reported By:  php-qa at sebastianmendel dot de
-Status:   Feedback
+Status:   Open
 Bug Type: PHP options/info functions
 Operating System: Red Hat 7.3
 PHP Version:  5.2.2RC1
 New Comment:

did you recieved email?


Previous Comments:


[2007-04-27 11:19:42] [EMAIL PROTECTED]

No, I need to reproduce it myself.



[2007-04-27 11:14:35] php-qa at sebastianmendel dot de

nothing has changed on the system

till now i used php5.2-200610021230 where it worked and work perfectly

now i use 5.2.2RC1 where it does not work anymore - also not with 5.2.1
which i tested too


http://www.kfp-online.de/rpm.txt
http://www.kfp-online.de/php-qa.php


does this help?



[2007-04-27 11:05:46] [EMAIL PROTECTED]

What has changed in the system? Where can I reproduce it?



[2007-04-27 10:48:17] php-qa at sebastianmendel dot de

main/build-defs.h:
#define CONFIGURE_COMMAND " './configure'"

same for 5.2.1 - which i tested again now

but it works with php5.2-200610021230
there the #define CONFIGURE_COMMAND line is fine, having the whole
configure command

php5.2-200610021230 was the last version i had running before upgrading
to 5.2.2RC1



[2007-04-23 10:31:11] [EMAIL PROTECTED]

See main/build-defs.h, the very first define.
Shell (/bin/sh) is the only thing that is involved here and if you're
saying it worked for you before, I'd say something has changed in your
system, since there were no changes there for at least several months.



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/41150

-- 
Edit this bug report at http://bugs.php.net/?id=41150&edit=1

#40785 [Com]: Error trying to insert into CLOB column using PDO_OCI and Streams.

[eugene dot pikalov at gmail dot com]

 ID:  40785
 Comment by:  eugene dot pikalov at gmail dot com
 Reported By: jarismar at adplabs dot com dot br
 Status:  Assigned
 Bug Type:PDO related
 PHP Version: 5.2.1
 Assigned To: wez
 New Comment:

http://pecl.php.net/bugs/bug.php?id=7943


Previous Comments:


[2007-03-12 16:22:07] jarismar at adplabs dot com dot br

Description:

Trying to inset into a CLOB field usint RETURNING column INTO sql
syntax, results on the following error :

OCIStmtExecute: ORA-00932: inconsistent datatypes: expected BLOB got
CLOB

I've tested with Oracle 9i and 10g (both relases 10.1 and 10.2).



Reproduce code:
---
try {
  $oPDO = new PDO($sDSN, $sUserName, $sPassword);
  $oPDO->beginTransaction();

  $oStmt = $oPDO->prepare(
'INSERT INTO test_clob (id,data) '.
'VALUES (:id, EMPTY_CLOB()) '.
'RETURNING data INTO :value');

  if($oStmt === false) { print_r($oPDO->errorInfo()); }

  $iID = 1;
  if(!$oStmt->bindParam(':id', $iID)) { print_r($oStmt->errorInfo());
}

  $sData = str_repeat('x', 65535);
  if(!$oStmt->bindParam(':value', $resource, PDO::PARAM_LOB)) {
print_r($oStmt->errorInfo()); }

  if(!$oStmt->execute()) {print_r($oStmt->errorInfo());}

  if (is_resource($resource)) {
fwrite($resource, $sData);
fclose($resource);
  }

  $oPDO->commit();

} catch (Exception $oE) {
  print $oE->getMessage()."\n";
}
$oPDO = null;



Expected result:

No error or exception should occurs.

Actual result:
--
Array
(
[0] => HY000
[1] => 932
[2] => OCIStmtExecute: ORA-00932: inconsistent datatypes: expected
BLOB got CLOB
 (/oracle/applications/php-5.2.0/ext/pdo_oci/oci_statement.c:142)
)





-- 
Edit this bug report at http://bugs.php.net/?id=40785&edit=1

#41150 [Opn->Fbk]: phpinfo() configure option is empty

[tony2001]

 ID:   41150
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php-qa at sebastianmendel dot de
-Status:   Open
+Status:   Feedback
 Bug Type: PHP options/info functions
 Operating System: Red Hat 7.3
 PHP Version:  5.2.2RC1
 New Comment:

No, I need to reproduce it myself.


Previous Comments:


[2007-04-27 11:14:35] php-qa at sebastianmendel dot de

nothing has changed on the system

till now i used php5.2-200610021230 where it worked and work perfectly

now i use 5.2.2RC1 where it does not work anymore - also not with 5.2.1
which i tested too


http://www.kfp-online.de/rpm.txt
http://www.kfp-online.de/php-qa.php


does this help?



[2007-04-27 11:05:46] [EMAIL PROTECTED]

What has changed in the system? Where can I reproduce it?



[2007-04-27 10:48:17] php-qa at sebastianmendel dot de

main/build-defs.h:
#define CONFIGURE_COMMAND " './configure'"

same for 5.2.1 - which i tested again now

but it works with php5.2-200610021230
there the #define CONFIGURE_COMMAND line is fine, having the whole
configure command

php5.2-200610021230 was the last version i had running before upgrading
to 5.2.2RC1



[2007-04-23 10:31:11] [EMAIL PROTECTED]

See main/build-defs.h, the very first define.
Shell (/bin/sh) is the only thing that is involved here and if you're
saying it worked for you before, I'd say something has changed in your
system, since there were no changes there for at least several months.



[2007-04-23 09:52:54] php-qa at sebastianmendel dot de

can you give some sort of hint where i can/should look, where does PHP
normally stores this information, what sort of functions/libraries are
involved into this or what is changed in the code related to this
feature?



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/41150

-- 
Edit this bug report at http://bugs.php.net/?id=41150&edit=1

#41150 [Fbk->Opn]: phpinfo() configure option is empty

[php-qa at sebastianmendel dot de]

 ID:   41150
 User updated by:  php-qa at sebastianmendel dot de
 Reported By:  php-qa at sebastianmendel dot de
-Status:   Feedback
+Status:   Open
 Bug Type: PHP options/info functions
 Operating System: Red Hat 7.3
 PHP Version:  5.2.2RC1
 New Comment:

nothing has changed on the system

till now i used php5.2-200610021230 where it worked and work perfectly

now i use 5.2.2RC1 where it does not work anymore - also not with 5.2.1
which i tested too


http://www.kfp-online.de/rpm.txt
http://www.kfp-online.de/php-qa.php


does this help?


Previous Comments:


[2007-04-27 11:05:46] [EMAIL PROTECTED]

What has changed in the system? Where can I reproduce it?



[2007-04-27 10:48:17] php-qa at sebastianmendel dot de

main/build-defs.h:
#define CONFIGURE_COMMAND " './configure'"

same for 5.2.1 - which i tested again now

but it works with php5.2-200610021230
there the #define CONFIGURE_COMMAND line is fine, having the whole
configure command

php5.2-200610021230 was the last version i had running before upgrading
to 5.2.2RC1



[2007-04-23 10:31:11] [EMAIL PROTECTED]

See main/build-defs.h, the very first define.
Shell (/bin/sh) is the only thing that is involved here and if you're
saying it worked for you before, I'd say something has changed in your
system, since there were no changes there for at least several months.



[2007-04-23 09:52:54] php-qa at sebastianmendel dot de

can you give some sort of hint where i can/should look, where does PHP
normally stores this information, what sort of functions/libraries are
involved into this or what is changed in the code related to this
feature?



[2007-04-23 09:28:16] [EMAIL PROTECTED]

Cannot reproduce.



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/41150

-- 
Edit this bug report at http://bugs.php.net/?id=41150&edit=1

#41150 [Opn->Fbk]: phpinfo() configure option is empty

[tony2001]

 ID:   41150
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php-qa at sebastianmendel dot de
-Status:   Open
+Status:   Feedback
 Bug Type: PHP options/info functions
 Operating System: Red Hat 7.3
 PHP Version:  5.2.2RC1
 New Comment:

What has changed in the system? Where can I reproduce it?


Previous Comments:


[2007-04-27 10:48:17] php-qa at sebastianmendel dot de

main/build-defs.h:
#define CONFIGURE_COMMAND " './configure'"

same for 5.2.1 - which i tested again now

but it works with php5.2-200610021230
there the #define CONFIGURE_COMMAND line is fine, having the whole
configure command

php5.2-200610021230 was the last version i had running before upgrading
to 5.2.2RC1



[2007-04-23 10:31:11] [EMAIL PROTECTED]

See main/build-defs.h, the very first define.
Shell (/bin/sh) is the only thing that is involved here and if you're
saying it worked for you before, I'd say something has changed in your
system, since there were no changes there for at least several months.



[2007-04-23 09:52:54] php-qa at sebastianmendel dot de

can you give some sort of hint where i can/should look, where does PHP
normally stores this information, what sort of functions/libraries are
involved into this or what is changed in the code related to this
feature?



[2007-04-23 09:28:16] [EMAIL PROTECTED]

Cannot reproduce.



[2007-04-23 05:16:17] php-qa at sebastianmendel dot de

sorry, below means before



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/41150

-- 
Edit this bug report at http://bugs.php.net/?id=41150&edit=1

#41150 [Fbk->Opn]: phpinfo() configure option is empty

[php-qa at sebastianmendel dot de]

 ID:   41150
 User updated by:  php-qa at sebastianmendel dot de
 Reported By:  php-qa at sebastianmendel dot de
-Status:   Feedback
+Status:   Open
 Bug Type: PHP options/info functions
 Operating System: Red Hat 7.3
 PHP Version:  5.2.2RC1
 New Comment:

main/build-defs.h:
#define CONFIGURE_COMMAND " './configure'"

same for 5.2.1 - which i tested again now

but it works with php5.2-200610021230
there the #define CONFIGURE_COMMAND line is fine, having the whole
configure command

php5.2-200610021230 was the last version i had running before upgrading
to 5.2.2RC1


Previous Comments:


[2007-04-23 10:31:11] [EMAIL PROTECTED]

See main/build-defs.h, the very first define.
Shell (/bin/sh) is the only thing that is involved here and if you're
saying it worked for you before, I'd say something has changed in your
system, since there were no changes there for at least several months.



[2007-04-23 09:52:54] php-qa at sebastianmendel dot de

can you give some sort of hint where i can/should look, where does PHP
normally stores this information, what sort of functions/libraries are
involved into this or what is changed in the code related to this
feature?



[2007-04-23 09:28:16] [EMAIL PROTECTED]

Cannot reproduce.



[2007-04-23 05:16:17] php-qa at sebastianmendel dot de

sorry, below means before



[2007-04-23 05:15:13] php-qa at sebastianmendel dot de

- open my ssh console
 - login as root
 - (download and extract php 5.2.2RC1 bz2 archive from qa.php.net)
 - run command exactly as provided below
 - than run make (, make test) and make install

this is exactly the same configure command i used before on all other
versions i had previously installed (except of '--enable-exif') of PHP

(my make test report for this has same sender email address as here)



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/41150

-- 
Edit this bug report at http://bugs.php.net/?id=41150&edit=1

#41208 [Asn->Bgs]: saveXML() fails with iso-8859-1 input

[rrichards]

 ID:   41208
 Updated by:   [EMAIL PROTECTED]
 Reported By:  scott at realorganized dot com
-Status:   Assigned
+Status:   Bogus
 Bug Type: DOM XML related
 Operating System: Mac OS X, Linux
 PHP Version:  5.2.1
 Assigned To:  rrichards
 New Comment:

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

You need to utf-8 encode/decode data:
utf8_encode(chr(200))/utf-8_decode($data)


Previous Comments:


[2007-04-26 23:45:02] [EMAIL PROTECTED]

Rob, please verify this.



[2007-04-26 22:17:58] scott at realorganized dot com

change:
$domfather->saveXML()
to:
$domfather->saveXML($node)

in the example code and execute and no echo at all - no error, 
nothing.  It's like it crashed or something.



[2007-04-26 21:53:54] scott at realorganized dot com

Description:

When using input encoding of charset=iso-8859-1 domDocument() 
fails to output the ascii code 200 (e grave) using saveXML()

Reproduce code:
---
Here's some example code that shows the problem:

createElement("xxx", chr(200));
  $domfather->appendChild($node);
  echo "";
  echo htmlspecialchars($domfather->saveXML());
  $nodelist =  $domfather->getElementsByTagName("xxx");
  $data = $nodelist->item(0)->nodeValue;
  echo $data;
  echo strlen($data);
?>

Expected result:

I was expecting the saveXML() to output the e grave symbol (ascii 
200)

iso-8859-1 character mapping is here:

http://old.no/charmap/iso-8859-1.html

and shows that ascii is completely valid.

Please notice that the data is provided correctly when I ask for 
it by node.  the failure is just when using the saveXML() 
function.

Actual result:
--
The output from my server is below.  When I retrieve 
the node's data back, it is as expected.  But it's the saveXML() 
code that seems to have a problem. I suspect the problem is with 
the utf-8 -> iso-8859 conversion before output.

Warning:  DOMDocument::saveXML() [function.DOMDocument-saveXML]: 
output conversion failed due to conv error in /Library/Tenon/
WebServer/WebSites/realtyjuggler.com/subscription/test.php on line 
23

Warning:  DOMDocument::saveXML() [function.DOMDocument-saveXML]: 
Bytes: 0xC8 0x3C 0x2F 0x78 in /Library/Tenon/WebServer/WebSites/
realtyjuggler.com/subscription/test.php on line 23


È1





-- 
Edit this bug report at http://bugs.php.net/?id=41208&edit=1

#40844 [Asn]: SSH2.dll libssh update

[dj02 dot net at nbl dot fi]

 ID:   40844
 User updated by:  dj02 dot net at nbl dot fi
 Reported By:  dj02 dot net at nbl dot fi
 Status:   Assigned
 Bug Type: Feature/Change Request
-Operating System: Windows XP 5.1.2600
+Operating System: Windows Vista 6.0.6000
-PHP Version:  5.2.1
+PHP Version:  5.2.2-CVS
 Assigned To:  edink
 New Comment:

Still not updated


Previous Comments:


[2007-03-24 08:03:07] dj02 dot net at nbl dot fi

Did you notice my request, edink?



[2007-03-17 18:41:17] dj02 dot net at nbl dot fi

Description:

Hi,

Could you build php_ssh2.dll against latest libssh 2_0.14 libraries?






-- 
Edit this bug report at http://bugs.php.net/?id=40844&edit=1

#41194 [Opn->Bgs]: Similar to bug #39781

[tony2001]

 ID:   41194
 Updated by:   [EMAIL PROTECTED]
 Reported By:  bugs dot php at anonymousmail dot net
-Status:   Open
+Status:   Bogus
 Bug Type: Reproducible crash
 Operating System: Windows XP Professional x64 Edit
 PHP Version:  5.2.1
 New Comment:

>Notice it says, "PHP Fatal error", a.k.a. crash. 
>And it also crashed when I ran "php" from the command line.

Fatal error is not a crash.
Please follow my advice and start reading the docs.




Previous Comments:


[2007-04-27 08:15:00] bugs dot php at anonymousmail dot net

>Crash? What crash are you talking about?

I changed the bug status back to open. This is a real crash. Read on to
see why.

This crash (a crash according to Windows) occurred on my system when I
installed all extensions like I explained in my original post and is
caused by simply typing "php" at the Windows command prompt. This crash
was the source of the dump which I already posted, right below the
following text:

"Here is the report from the php CLI crashing from typing "php" at the
command prompt."

The person from bug #39781 had similar errors to those that I
received.

They got the error message, "There is a problem with this Windows
Installer package. A program run as part of the setup did not finish as
expected. Contact your support personnel or package vendor." This error
probably has something to do with installing extensions. As I explained
in my first post, I got that same error message.

They also had this error message, "CGI / FastCGI has encountered a
problem and needs to close." My error message was identical except mine
said php.exe because that was what I had executed.

This message is different than a warning message. All I did was type
"php" at the command prompt and hit enter. Then, windows pops up a error
message saying the above. I am then promptly returned to the command
prompt after I dismiss the error message. With a warning, I would still
be inside PHP.

I think one of the extensions is actually making PHP crash. I have
installed some extensions and gotten warnings in Apache, but PHP still
ran the script  However, when I had installed all the
extensions, PHP wouldn't execute that script.

I seriously do believe that one of the extensions is making PHP crash
for real. This is what I already posted from my Apache log file:

[error] [client 127.0.0.1] PHP Fatal error:  require_once() [function.require]: Failed opening required
'SAM/php_sam.php' (include_path='.;C:\\php5\\pear') in sam_factory on
line 1, referer: http://localhost/

Notice it says, "PHP Fatal error", a.k.a. crash. And it also crashed
when I ran "php" from the command line.

(Also, pear and php wasn't installed at the location it gave in the
include_path.)

So, it is crashing in the Apache module and also from php.exe on the
command line.

Over the years, I have seen lots of different programs crash. It looks
just like a crash to me. 

If I do not install all extensions, PHP runs great, which makes me
conclude that an extension is causing the crash.

I am running the 64bit version of Windows XP Pro. I don't know if that
has anything to do with PHP crashing. I have noticed that quite a lot of
older programs don't like to run on this OS. Maybe this is the problem
with whatever extension might be causing the crash.

If you want, I will be glad to provide any more information!


>Startup warnings are no crashes and you should start reading the docs
>before installing anything.
>Not PHP problem.

"RTFM", I understand that. However, for example, I am looking at this
from the perspective of someone who buys a book about blogging, etc. The
book briefly covers how to install Apache, PHP and MySql. Then continues
on with installing blog software (written in PHP), etc.

This person would be following step-by-step what the book says.
Sometimes problems occur which are unforeseen by the books author. This
person probably isn't going to know about "RTFM" or even where to find
it. I was this person several years ago!

Basically, my solution to all this is to possibly offer a 'simple' and
'advanced' selection on the installer. The simple selection will explain
about "RTFM", install the docs and offer to create shortcuts to them.

Most importantly, it will explain about the caveats of installing
extensions with unmet dependencies. Granted, it does say something about
this on the area where you can select extensions. However, it doesn't
explain much about it or explain why, etc.

The person from bug #39781 didn't even have the luxury of having a book
to reference.



[2007-04-26 22:54:44] [EMAIL PROTECTED]

>My point was, if someone wants to install php and they don't know
>about this stuff, then they will be UNABLE to use php! 

These are just warnings and they say "you did not read the docs, go now
and read them".

>For the lo

#41194 [Bgs->Opn]: Similar to bug #39781

[bugs dot php at anonymousmail dot net]

 ID:   41194
 User updated by:  bugs dot php at anonymousmail dot net
 Reported By:  bugs dot php at anonymousmail dot net
-Status:   Bogus
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: Windows XP Professional x64 Edit
 PHP Version:  5.2.1
 New Comment:

>Crash? What crash are you talking about?

I changed the bug status back to open. This is a real crash. Read on to
see why.

This crash (a crash according to Windows) occurred on my system when I
installed all extensions like I explained in my original post and is
caused by simply typing "php" at the Windows command prompt. This crash
was the source of the dump which I already posted, right below the
following text:

"Here is the report from the php CLI crashing from typing "php" at the
command prompt."

The person from bug #39781 had similar errors to those that I
received.

They got the error message, "There is a problem with this Windows
Installer package. A program run as part of the setup did not finish as
expected. Contact your support personnel or package vendor." This error
probably has something to do with installing extensions. As I explained
in my first post, I got that same error message.

They also had this error message, "CGI / FastCGI has encountered a
problem and needs to close." My error message was identical except mine
said php.exe because that was what I had executed.

This message is different than a warning message. All I did was type
"php" at the command prompt and hit enter. Then, windows pops up a error
message saying the above. I am then promptly returned to the command
prompt after I dismiss the error message. With a warning, I would still
be inside PHP.

I think one of the extensions is actually making PHP crash. I have
installed some extensions and gotten warnings in Apache, but PHP still
ran the script  However, when I had installed all the
extensions, PHP wouldn't execute that script.

I seriously do believe that one of the extensions is making PHP crash
for real. This is what I already posted from my Apache log file:

[error] [client 127.0.0.1] PHP Fatal error:  require_once() [function.require]: Failed opening required
'SAM/php_sam.php' (include_path='.;C:\\php5\\pear') in sam_factory on
line 1, referer: http://localhost/

Notice it says, "PHP Fatal error", a.k.a. crash. And it also crashed
when I ran "php" from the command line.

(Also, pear and php wasn't installed at the location it gave in the
include_path.)

So, it is crashing in the Apache module and also from php.exe on the
command line.

Over the years, I have seen lots of different programs crash. It looks
just like a crash to me. 

If I do not install all extensions, PHP runs great, which makes me
conclude that an extension is causing the crash.

I am running the 64bit version of Windows XP Pro. I don't know if that
has anything to do with PHP crashing. I have noticed that quite a lot of
older programs don't like to run on this OS. Maybe this is the problem
with whatever extension might be causing the crash.

If you want, I will be glad to provide any more information!


>Startup warnings are no crashes and you should start reading the docs
>before installing anything.
>Not PHP problem.

"RTFM", I understand that. However, for example, I am looking at this
from the perspective of someone who buys a book about blogging, etc. The
book briefly covers how to install Apache, PHP and MySql. Then continues
on with installing blog software (written in PHP), etc.

This person would be following step-by-step what the book says.
Sometimes problems occur which are unforeseen by the books author. This
person probably isn't going to know about "RTFM" or even where to find
it. I was this person several years ago!

Basically, my solution to all this is to possibly offer a 'simple' and
'advanced' selection on the installer. The simple selection will explain
about "RTFM", install the docs and offer to create shortcuts to them.

Most importantly, it will explain about the caveats of installing
extensions with unmet dependencies. Granted, it does say something about
this on the area where you can select extensions. However, it doesn't
explain much about it or explain why, etc.

The person from bug #39781 didn't even have the luxury of having a book
to reference.


Previous Comments:


[2007-04-26 22:54:44] [EMAIL PROTECTED]

>My point was, if someone wants to install php and they don't know
>about this stuff, then they will be UNABLE to use php! 

These are just warnings and they say "you did not read the docs, go now
and read them".

>For the longest time I tried to get php to work on my computer. 
>I gave up many times.

Well, you should really start with the docs.


>..they usually don't expect to maximize the likelihood that it
>will crash for unknown (to them) reasons!

Crash? What crash are you talking about?

>You can't expect everyone that wis

#41210 [Opn->Bgs]: unexpected behaviour on access null as an associative array

[johannes]

 ID:   41210
 Updated by:   [EMAIL PROTECTED]
 Reported By:  bgoldschmidt at rapidsoft dot de
-Status:   Open
+Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: debian
 PHP Version:  5.2.1
 New Comment:

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

.


Previous Comments:


[2007-04-27 07:43:02] bgoldschmidt at rapidsoft dot de

Description:

Trying to access null as an associative array works just fine and
doesn't result in an error, as it should.

Reproduce code:
---


Expected result:

An error.






-- 
Edit this bug report at http://bugs.php.net/?id=41210&edit=1

#41210 [NEW]: unexpected behaviour on access null as an associative array

[bgoldschmidt at rapidsoft dot de]

From: bgoldschmidt at rapidsoft dot de
Operating system: debian
PHP version:  5.2.1
PHP Bug Type: *General Issues
Bug description:  unexpected behaviour on access null as an associative array

Description:

Trying to access null as an associative array works just fine and doesn't
result in an error, as it should.

Reproduce code:
---


Expected result:

An error.


-- 
Edit bug report at http://bugs.php.net/?id=41210&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=41210&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=41210&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=41210&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41210&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=41210&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=41210&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41210&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41210&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=41210&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41210&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=41210&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=41210&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41210&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=41210&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41210&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41210&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=41210&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=41210&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=41210&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41210&r=mysqlcfg

#41209 [Opn->Fbk]: Segmentation fault with ArrayAccess, set_error_handler and undefined var

[johannes]

 ID:   41209
 Updated by:   [EMAIL PROTECTED]
 Reported By:  christian dot kaps at imaxx21 dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Ubuntu 7.04 Server
 PHP Version:  5.2.1
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

I can't reproduce it.
Please add a gdb backtrace in case you can reproduce it.


Previous Comments:


[2007-04-27 07:23:16] christian dot kaps at imaxx21 dot com

Description:

I get the message 'child pid 13149 exit signal Segmentation fault (11)'
in my apache logs. The problem occurs when i use the following code.



Reproduce code:
---
containers[(string) $id]);
}
}

$env = new env();
$cache = new cache();
var_dump(isset($cache[$id]));

?>

Expected result:

Fatal error: Uncaught exception 'ErrorException' with message
'Undefined variable: id' 

Actual result:
--
child pid 13149 exit signal Segmentation fault (11) in error.log





-- 
Edit this bug report at http://bugs.php.net/?id=41209&edit=1

#41209 [NEW]: Segmentation fault with ArrayAccess, set_error_handler and undefined var

[christian dot kaps at imaxx21 dot com]

From: christian dot kaps at imaxx21 dot com
Operating system: Ubuntu 7.04 Server
PHP version:  5.2.1
PHP Bug Type: Reproducible crash
Bug description:  Segmentation fault with ArrayAccess, set_error_handler and 
undefined var

Description:

I get the message 'child pid 13149 exit signal Segmentation fault (11)' in
my apache logs. The problem occurs when i use the following code.



Reproduce code:
---
containers[(string) $id]);
}
}

$env = new env();
$cache = new cache();
var_dump(isset($cache[$id]));

?>

Expected result:

Fatal error: Uncaught exception 'ErrorException' with message 'Undefined
variable: id' 

Actual result:
--
child pid 13149 exit signal Segmentation fault (11) in error.log

-- 
Edit bug report at http://bugs.php.net/?id=41209&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=41209&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=41209&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=41209&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41209&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=41209&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=41209&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41209&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41209&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=41209&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41209&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=41209&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=41209&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41209&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=41209&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41209&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41209&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=41209&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=41209&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=41209&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41209&r=mysqlcfg