#32020 [Fbk->Csd]: NULL is saved as 0 in variables
ID: 32020 User updated by: dreeh at ets-online dot de Reported By: dreeh at ets-online dot de -Status: Feedback +Status: Closed Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.3.10 New Comment: [EMAIL PROTECTED]:~> php -v PHP 4.3.10 (cli) (built: Jan 21 2005 15:25:23) Copyright (c) 1997-2004 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies now, the problem don't occurs anymore. i will reopen the bug if the error comes back. Previous Comments: [2005-02-21 18:49:22] [EMAIL PROTECTED] We can't reproduce this behaviour without eAccelerator. Please _check_ that you have not loaded any zend extensions (see `php -v` & phpinfo()). [2005-02-20 21:43:27] dreeh at ets-online dot de the last time...the problem only occurs without any extensions. i do not need any support, i'm reporting a bug. [2005-02-20 18:30:28] [EMAIL PROTECTED] 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. Thank you for your interest in PHP. Unless you can demonstrate that the problem occurs with "stock' PHP without any extra extensions especially compiler related extnsion this is not a PHP bug. [2005-02-18 16:53:16] dreeh at ets-online dot de no, the problem occurs when i comment the loading of the extension in the php.ini! with loaded extension, the bug doesn't occur. see my last comment. [2005-02-18 16:39:50] [EMAIL PROTECTED] Do not file bugs when you have Zend extensions (zend_extension=) loaded. Examples are Zend Optimizer, Zend Debugger, Turck MM Cache, APC, Xdebug and ionCube loader. These extensions often modify engine behavior which is not related to PHP itself. That's eAccelerator bug and it has nothing to do with PHP itself. 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/32020 -- Edit this bug report at http://bugs.php.net/?id=32020&edit=1
#27633 [Fbk]: Double \r problem on ftp_get in ASCII mode on Win32
ID: 27633 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: FTP related Operating System: win32 only PHP Version: 4CVS, 5CVS (2005-02-22) Assigned To: iliaa New Comment: It's the same with the latest Windows snapshot :-(. Previous Comments: [2005-02-23 04:54:07] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip There was some problem with win32 snapshots again.. [2005-02-21 12:20:51] [EMAIL PROTECTED] I can't see any change: \n becomes \r\r on 5.1.0-dev (200502210730) \n becomes \r\r on 5.0.4-dev (200502210930) \n becomes \r\r\n on 4.3.11-dev (200502210530) last \n becomes \r\r\n on 5. [2005-02-17 16:38:41] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2005-02-03 03:20:09] [EMAIL PROTECTED] http://www.binam.net/bug-27633.patch [2004-03-18 07:27:30] [EMAIL PROTECTED] Description: ftp_get() translates \n characters wrong in FTP_ASCII mode. Instead of \r\n, they become \r on Windows. Only newline at the end of a file (if any) is translated correct. \r\n on remote server become \r\r. Reproduce code: --- Expected result: \r\nWelcome ...\r\n Actual result: -- \rWelcome ...\r\n -- Edit this bug report at http://bugs.php.net/?id=27633&edit=1
#27633 [Fbk->Opn]: Double \r problem on ftp_get in ASCII mode on Win32
ID: 27633 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: FTP related Operating System: win32 only PHP Version: 4CVS, 5CVS (2005-02-22) Assigned To: iliaa Previous Comments: [2005-02-23 09:37:21] [EMAIL PROTECTED] It's the same with the latest Windows snapshot :-(. [2005-02-23 04:54:07] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip There was some problem with win32 snapshots again.. [2005-02-21 12:20:51] [EMAIL PROTECTED] I can't see any change: \n becomes \r\r on 5.1.0-dev (200502210730) \n becomes \r\r on 5.0.4-dev (200502210930) \n becomes \r\r\n on 4.3.11-dev (200502210530) last \n becomes \r\r\n on 5. [2005-02-17 16:38:41] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2005-02-03 03:20:09] [EMAIL PROTECTED] http://www.binam.net/bug-27633.patch 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/27633 -- Edit this bug report at http://bugs.php.net/?id=27633&edit=1
#27633 [Opn->Asn]: Double \r problem on ftp_get in ASCII mode on Win32
ID: 27633 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: FTP related Operating System: win32 only PHP Version: 4CVS, 5CVS (2005-02-22) Assigned To: iliaa New Comment: Ilia, your fix did not work? :) Previous Comments: [2005-02-23 09:37:21] [EMAIL PROTECTED] It's the same with the latest Windows snapshot :-(. [2005-02-23 04:54:07] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip There was some problem with win32 snapshots again.. [2005-02-21 12:20:51] [EMAIL PROTECTED] I can't see any change: \n becomes \r\r on 5.1.0-dev (200502210730) \n becomes \r\r on 5.0.4-dev (200502210930) \n becomes \r\r\n on 4.3.11-dev (200502210530) last \n becomes \r\r\n on 5. [2005-02-17 16:38:41] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2005-02-03 03:20:09] [EMAIL PROTECTED] http://www.binam.net/bug-27633.patch 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/27633 -- Edit this bug report at http://bugs.php.net/?id=27633&edit=1
#32078 [NEW]: saveXML / XSLT TransformToXML bug?
From: roger4a45 at yahoo dot es
Operating system: Windows XP
PHP version: 5.0.2
PHP Bug Type: DOM XML related
Bug description: saveXML / XSLT TransformToXML bug?
Description:
ref 1:
I try to build a XML using DOM extensions and then I want to output this
one by using XSLT extensions. My XML is created dinamicaly using
createElements / appendChilds as i will show below. If I use specials
chars like ¨¤ ¨¢ i can see a warning when i make and saveXML from
DOMDocument.
echo $xmlDOMDoc->saveXML()
Warning: output conversion failed due to conv error in d:\archivos de
programa\apache group\Apache\htdocs\newnovoprint\test\v2.php on line 122
Warning: Bytes: 0xE9 0x73 0x20 0x50 in d:\archivos de programa\apache
group\Apache\htdocs\newnovoprint\test\v2.php on line 122
Andres Poluk Andr
ref2:
If I try to use XSLT extensions when i make a TransformToXML() output is
wrong. Andr¨¦s is output as a Andr÷.
ref3:
I check documentation and i didn't find any information about that
problem.
If I load same XML from a file and i use XSLT extensions that result is
OK.
In code example i put third easy examples i build to explain this possible
bug.
Reproduce code:
---
XML I want to make (tested) known as v1.xml in third source.
Andr¨¦s Polim
XSL I use v1.xsl (tested)
http://www.w3.org/1999/XSL/Transform";
xmlns="http://www.w3.org/TR/REC-html40";>
First Code ref: 1
CreateElement("TEST");
$child = $xml->CreateElement("NAME","Andr¨¦s Poluk");
$root->appendChild($child);
$xml->appendChild($root);
echo $xml->saveXML(); // <- Error
?>
Second Code ref: 2
load('v1.xsl');
$proc = new XSLTProcessor;
$root = $xml->CreateElement("TEST");
$child = $xml->CreateElement("NAME","Andr¨¦s Poluk");
$root->appendChild($child);
$proc->importStyleSheet($xsl);
echo $proc->transformToXML($xml);
?>
Third code ref: 3 (This one works ok)
load('v1.xml');
$xsl->load('V1.xsl');
$proc->importStyleSheet($xsl);
echo $proc->transformToXML($xml);
?>
Expected result:
ref1,ref2,ref3:
Andr¨¦s Poluk (A simple text)
or
Andr¨¦s Poluk
Actual result:
--
ref1:
Warning: Bytes: 0xE9 0x73 0x20 0x50 in d:\archivos de programa\apache
group\Apache\htdocs\newnovoprint\test\v2.php on line 122
Andres Poluk Andr
ref2:
Andr÷. Poluk
ref3:
Andr¨¦s Poluk
--
Edit bug report at http://bugs.php.net/?id=32078&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32078&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32078&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32078&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32078&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32078&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32078&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32078&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32078&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32078&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32078&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32078&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32078&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32078&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32078&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32078&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32078&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32078&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32078&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32078&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32078&r=mysqlcfg
#32078 [Opn]: saveXML / XSLT TransformToXML bug?
ID: 32078
User updated by: roger4a45 at yahoo dot es
Reported By: roger4a45 at yahoo dot es
Status: Open
Bug Type: DOM XML related
Operating System: Windows XP
PHP Version: 5.0.2
New Comment:
Note: I see some chars from my explanation are bad. Characters have
problems are accents like à (using html encoding) So, I want to
output Andràs Poluk.
In ref2: Output seeing IE Explorer source is: Andr鳠Poluk (using
same html encoding).
Previous Comments:
[2005-02-23 11:01:19] roger4a45 at yahoo dot es
Description:
ref 1:
I try to build a XML using DOM extensions and then I want to output
this one by using XSLT extensions. My XML is created dinamicaly using
createElements / appendChilds as i will show below. If I use specials
chars like ¨¤ ¨¢ i can see a warning when i make and saveXML from
DOMDocument.
echo $xmlDOMDoc->saveXML()
Warning: output conversion failed due to conv error in d:\archivos de
programa\apache group\Apache\htdocs\newnovoprint\test\v2.php on line
122
Warning: Bytes: 0xE9 0x73 0x20 0x50 in d:\archivos de programa\apache
group\Apache\htdocs\newnovoprint\test\v2.php on line 122
Andres Poluk Andr
ref2:
If I try to use XSLT extensions when i make a TransformToXML() output
is wrong. Andr¨¦s is output as a Andr÷.
ref3:
I check documentation and i didn't find any information about that
problem.
If I load same XML from a file and i use XSLT extensions that result is
OK.
In code example i put third easy examples i build to explain this
possible bug.
Reproduce code:
---
XML I want to make (tested) known as v1.xml in third source.
Andr¨¦s Polim
XSL I use v1.xsl (tested)
http://www.w3.org/1999/XSL/Transform";
xmlns="http://www.w3.org/TR/REC-html40";>
First Code ref: 1
CreateElement("TEST");
$child = $xml->CreateElement("NAME","Andr¨¦s Poluk");
$root->appendChild($child);
$xml->appendChild($root);
echo $xml->saveXML(); // <- Error
?>
Second Code ref: 2
load('v1.xsl');
$proc = new XSLTProcessor;
$root = $xml->CreateElement("TEST");
$child = $xml->CreateElement("NAME","Andr¨¦s Poluk");
$root->appendChild($child);
$proc->importStyleSheet($xsl);
echo $proc->transformToXML($xml);
?>
Third code ref: 3 (This one works ok)
load('v1.xml');
$xsl->load('V1.xsl');
$proc->importStyleSheet($xsl);
echo $proc->transformToXML($xml);
?>
Expected result:
ref1,ref2,ref3:
Andr¨¦s Poluk (A simple text)
or
Andr¨¦s Poluk
Actual result:
--
ref1:
Warning: Bytes: 0xE9 0x73 0x20 0x50 in d:\archivos de programa\apache
group\Apache\htdocs\newnovoprint\test\v2.php on line 122
Andres Poluk Andr
ref2:
Andr÷. Poluk
ref3:
Andr¨¦s Poluk
--
Edit this bug report at http://bugs.php.net/?id=32078&edit=1
#32078 [Opn->Csd]: saveXML / XSLT TransformToXML bug?
ID: 32078
User updated by: roger4a45 at yahoo dot es
Reported By: roger4a45 at yahoo dot es
-Status: Open
+Status: Closed
Bug Type: DOM XML related
-Operating System: Windows XP
+Operating System: Windows XP /Windows 2000
PHP Version: 5.0.2
New Comment:
I found this one that solve problem. It's ref2 code correction:
load('v1.xsl');
$proc = new XSLTProcessor;
$root = $xml->CreateElement("TEST");
$val = utf8_encode ('Andrés Poluk'); //New Line
$child = $xml->CreateElement("NAME",$val);
$root->appendChild($child);
$xml->appendChild($root);
$proc->importStyleSheet($xsl);
echo $proc->transformToXML($xml);
?>
Now, output is what i expected. Maybe it will be usefull to add a note
in your php DOM
Previous Comments:
[2005-02-23 11:11:04] roger4a45 at yahoo dot es
Note: I see some chars from my explanation are bad. Characters have
problems are accents like à (using html encoding) So, I want to
output Andràs Poluk.
In ref2: Output seeing IE Explorer source is: Andr鳠Poluk (using
same html encoding).
[2005-02-23 11:01:19] roger4a45 at yahoo dot es
Description:
ref 1:
I try to build a XML using DOM extensions and then I want to output
this one by using XSLT extensions. My XML is created dinamicaly using
createElements / appendChilds as i will show below. If I use specials
chars like ¨¤ ¨¢ i can see a warning when i make and saveXML from
DOMDocument.
echo $xmlDOMDoc->saveXML()
Warning: output conversion failed due to conv error in d:\archivos de
programa\apache group\Apache\htdocs\newnovoprint\test\v2.php on line
122
Warning: Bytes: 0xE9 0x73 0x20 0x50 in d:\archivos de programa\apache
group\Apache\htdocs\newnovoprint\test\v2.php on line 122
Andres Poluk Andr
ref2:
If I try to use XSLT extensions when i make a TransformToXML() output
is wrong. Andr¨¦s is output as a Andr÷.
ref3:
I check documentation and i didn't find any information about that
problem.
If I load same XML from a file and i use XSLT extensions that result is
OK.
In code example i put third easy examples i build to explain this
possible bug.
Reproduce code:
---
XML I want to make (tested) known as v1.xml in third source.
Andr¨¦s Polim
XSL I use v1.xsl (tested)
http://www.w3.org/1999/XSL/Transform";
xmlns="http://www.w3.org/TR/REC-html40";>
First Code ref: 1
CreateElement("TEST");
$child = $xml->CreateElement("NAME","Andr¨¦s Poluk");
$root->appendChild($child);
$xml->appendChild($root);
echo $xml->saveXML(); // <- Error
?>
Second Code ref: 2
load('v1.xsl');
$proc = new XSLTProcessor;
$root = $xml->CreateElement("TEST");
$child = $xml->CreateElement("NAME","Andr¨¦s Poluk");
$root->appendChild($child);
$proc->importStyleSheet($xsl);
echo $proc->transformToXML($xml);
?>
Third code ref: 3 (This one works ok)
load('v1.xml');
$xsl->load('V1.xsl');
$proc->importStyleSheet($xsl);
echo $proc->transformToXML($xml);
?>
Expected result:
ref1,ref2,ref3:
Andr¨¦s Poluk (A simple text)
or
Andr¨¦s Poluk
Actual result:
--
ref1:
Warning: Bytes: 0xE9 0x73 0x20 0x50 in d:\archivos de programa\apache
group\Apache\htdocs\newnovoprint\test\v2.php on line 122
Andres Poluk Andr
ref2:
Andr÷. Poluk
ref3:
Andr¨¦s Poluk
--
Edit this bug report at http://bugs.php.net/?id=32078&edit=1
#32076 [Opn->Csd]: ReflectionMethod :: isDestructor() always return true
ID: 32076
Updated by: [EMAIL PROTECTED]
Reported By: fablezouave at gmail dot com
-Status: Open
+Status: Closed
Bug Type: Class/Object related
Operating System: debian/GNU Linux
PHP Version: 5.0.3
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2005-02-23 09:02:09] fablezouave at gmail dot com
Description:
Hi
It seems that the ReflectionMethod :: isDestructor() method always
return true.
Thanks
Fab
Reproduce code:
---
getMethods() as $val) {
$M = new reflectionMethod($val->class, $val->name);
echo ''.$val->name.'';
if($M->isConstructor())
echo 'Constructor';
// Always return TRUE
if($M->isDestructor())
echo 'Destructor';
}
?>
Expected result:
__construct
Constructor
truc
__destruct
Destructor
Actual result:
--
__construct
Constructor
Destructor
truc
Destructor
__destruct
Destructor
--
Edit this bug report at http://bugs.php.net/?id=32076&edit=1
#32079 [NEW]: PHP "Safe"-Mode not identifiable in X-Powered-By header
From: milky at users dot sf dot net
Operating system: all
PHP version: Irrelevant
PHP Bug Type: Feature/Change Request
Bug description: PHP "Safe"-Mode not identifiable in X-Powered-By header
Description:
PHP sends an "X-Powered-By" header with each request answer, containing a
PHP version string. It's also included with the Apache id in its "Server"
header.
This version information however misses important informations - for
example which sort of PHP is running over there.
If PHP is running in crippled mode, it should identify itself as
"SM-PHP/5.03" or just "S/M-PHP" or so. This would significantly benefit
the Web hosting provider industry, since fewer contracts would be
discarded again after customers find out that they've only be given
"Safe"-Mode PHP.
Incorrectly advertising features ("PHP" instead of "S/M-PHP") counts as
mischief in central Europe. *hint,hint*
(Given, that there is always either Python or Perl running on "safe"-moded
Webservers, it's obvious that this setting was made for dumb providers. No
need to discuss that again here; no?)
--
Edit bug report at http://bugs.php.net/?id=32079&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32079&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32079&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32079&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32079&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32079&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32079&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32079&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32079&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32079&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32079&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32079&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32079&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32079&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32079&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32079&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32079&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32079&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32079&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32079&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32079&r=mysqlcfg
#32079 [Opn->WFx]: PHP "Safe"-Mode not identifiable in X-Powered-By header
ID: 32079
Updated by: [EMAIL PROTECTED]
Reported By: milky at users dot sf dot net
-Status: Open
+Status: Wont fix
Bug Type: Feature/Change Request
Operating System: all
PHP Version: Irrelevant
New Comment:
We won't change because of obvious security concerns. External people
should not know exactly what your set-up is.
Previous Comments:
[2005-02-23 15:17:02] milky at users dot sf dot net
Description:
PHP sends an "X-Powered-By" header with each request answer, containing
a PHP version string. It's also included with the Apache id in its
"Server" header.
This version information however misses important informations - for
example which sort of PHP is running over there.
If PHP is running in crippled mode, it should identify itself as
"SM-PHP/5.03" or just "S/M-PHP" or so. This would significantly benefit
the Web hosting provider industry, since fewer contracts would be
discarded again after customers find out that they've only be given
"Safe"-Mode PHP.
Incorrectly advertising features ("PHP" instead of "S/M-PHP") counts as
mischief in central Europe. *hint,hint*
(Given, that there is always either Python or Perl running on
"safe"-moded Webservers, it's obvious that this setting was made for
dumb providers. No need to discuss that again here; no?)
--
Edit this bug report at http://bugs.php.net/?id=32079&edit=1
#32080 [NEW]: segfault when assigning object to itself in ze1 mode
From: nicoletti at nns dot ch
Operating system: Linux 2.4
PHP version: 5.0.3
PHP Bug Type: Zend Engine 2 problem
Bug description: segfault when assigning object to itself in ze1 mode
Description:
segfault when assigning object to itself in ze1 mode
Reproduce code:
---
ini_set('zend.ze1_compatibility_mode', true);
class test { }
$t = new test;
$t = $t; // gives segfault
Expected result:
last line gives segfault
--
Edit bug report at http://bugs.php.net/?id=32080&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32080&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32080&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32080&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32080&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32080&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32080&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32080&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32080&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32080&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32080&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32080&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32080&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32080&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32080&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32080&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32080&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32080&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32080&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32080&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32080&r=mysqlcfg
#32082 [NEW]: Comparing of floating point values fail
From: weber at mapsolute dot com Operating system: Linux PHP version: 4.3.9 PHP Bug Type: Math related Bug description: Comparing of floating point values fail Description: If you compare two equal floating point values for uneven the compare fails (it returns true) and I can see no reason why. I've checked the PHP manual (http://uk.php.net/manual/en/language.types.float.php), but this doesn't explain the behave. The two numbers below must be binary equal, independend if you save them as single or double precision floating point numbers and even if you would store them as double and convert into float for comparing, they must stay binary equal. Even as string they must be binary equal. Therefore comparing them should return true in any case. Quote from http://en.wikipedia.org/wiki/IEEE_754: Comparing floating-point numbers An interesting feature of this particular representation is that it makes comparisons of numbers of the same sign which are not NaNs simple. For positive numbers (the sign bit is 0) a and b, then a < b whenever the unsigned binary integers with the same bit patterns as a and b are also ordered the same way. In other words if you are comparing two positive floating-point numbers (known not to be NaNs) you can just use an unsigned binary integer comparison using the same bits. Reproduce code: --- OK"; else echo "WRONG"; var_dump($a); echo ""; var_dump($b); ?> Expected result: OK float(437.674240047) float(437.674240047) Actual result: -- WRONG float(437.674240047) float(437.674240047) -- Edit bug report at http://bugs.php.net/?id=32082&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32082&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32082&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32082&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32082&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32082&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32082&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32082&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32082&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32082&r=support Expected behavior: http://bugs.php.net/fix.php?id=32082&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32082&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32082&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32082&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32082&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32082&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32082&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32082&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32082&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32082&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32082&r=mysqlcfg
#32082 [Opn->Bgs]: Comparing of floating point values fail
ID: 32082 User updated by: weber at mapsolute dot com Reported By: weber at mapsolute dot com -Status: Open +Status: Bogus Bug Type: Math related Operating System: Linux PHP Version: 4.3.9 New Comment: Ups, my misstake, I saw it after submitting (hopefully nobody reads it ;-)). Previous Comments: [2005-02-23 16:22:17] weber at mapsolute dot com Description: If you compare two equal floating point values for uneven the compare fails (it returns true) and I can see no reason why. I've checked the PHP manual (http://uk.php.net/manual/en/language.types.float.php), but this doesn't explain the behave. The two numbers below must be binary equal, independend if you save them as single or double precision floating point numbers and even if you would store them as double and convert into float for comparing, they must stay binary equal. Even as string they must be binary equal. Therefore comparing them should return true in any case. Quote from http://en.wikipedia.org/wiki/IEEE_754: Comparing floating-point numbers An interesting feature of this particular representation is that it makes comparisons of numbers of the same sign which are not NaNs simple. For positive numbers (the sign bit is 0) a and b, then a < b whenever the unsigned binary integers with the same bit patterns as a and b are also ordered the same way. In other words if you are comparing two positive floating-point numbers (known not to be NaNs) you can just use an unsigned binary integer comparison using the same bits. Reproduce code: --- OK"; else echo "WRONG"; var_dump($a); echo ""; var_dump($b); ?> Expected result: OK float(437.674240047) float(437.674240047) Actual result: -- WRONG float(437.674240047) float(437.674240047) -- Edit this bug report at http://bugs.php.net/?id=32082&edit=1
#28899 [Com]: substr and mb_substr work different
ID: 28899 Comment by: drraf at tlen dot pl Reported By: mauroi at digbang dot com Status: Assigned Bug Type: mbstring related Operating System: * PHP Version: 4CVS, 5CVS (2004-12-12) Assigned To: moriyoshi New Comment: If mb_string() can overload substr() (when function overloading in on when using mbstring) - in my opinion mb_substr() should be fixed. Previous Comments: [2005-02-03 03:25:48] [EMAIL PROTECTED] Whatever is the "logical" behaviour of the function, it doesn't really matter: We will NOT change the behaviour of substr() at this point. Thus the only place to change is mbstring. [2004-12-20 13:58:20] mauroi at digbang dot com just to mention it... lot of code written with the mb_* function overload relies on substr returning a zero length string... changing substr to work like mb_substr won't break anything (i think) [2004-12-20 10:28:55] [EMAIL PROTECTED] The very nature of "substr" is that the function returns the specified part of the string whenever the range is valid and returns an error status if it is out of range. If a null string is a valid string entity, then it should be able to be referred to by index "0" and thus the implementation returns a null string instead of false. Or you would say this isn't really logical? :) [2004-12-15 04:19:11] [EMAIL PROTECTED] The correct quote from up-to-date manual: "If string is less than or equal to start characters long, FALSE will be returned." Notice the 'or equal' there? Thus logically mb_substr() is buggy. [2004-06-23 22:12:57] [EMAIL PROTECTED] Good catch. Logically it seems substr() is wrong and mb_substr() is correct. 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/28899 -- Edit this bug report at http://bugs.php.net/?id=28899&edit=1
#27406 [Com]: php_check_syntax executes code
ID: 27406
Comment by: de_bruut at hotmail dot com
Reported By: thomas at stauntons dot org
Status: Assigned
Bug Type: Unknown/Other Function
Operating System: All
PHP Version: php5.0-200412100930
Assigned To: iliaa
New Comment:
Couple of points:
1. there are already half a dozen functions that include files or
execute strings
2. there's no other function that allows you to check the validity of a
piece of php code
3. right now, php_check_syntax does more than its name implies (it
includes the file)
4. there are several situations where a 'clean' lint check of php code
is useful (snippet submissions, UNIT TESTS(!), ...)
5. in general, functions should do only one thing, not two only
slightly related things, and one of them badly
I would love to see php_check_syntax implemented as its name implies: a
lint check for a STRING. Not a file (see Wylie's comment), because there
are enough functions to read a file or stream into a string.
If someone wants to include the file afterwards, they only need to add
a single line of code, or they can write their own two-line function.
This even leaves them the choice between include() and include_once(),
something which php_check_syntax does not do at this point.
Did I mention the potential value of php_check_syntax for >> UNIT TESTS
<< yet? php_check_syntax would allow us to check the syntax of a file
(string) as the first of a group of tests for that file/class, and thus
avoiding a potential fatal error, which could interrupt an entire set of
tests on multiple files. Thus, a syntax check could make quite a number
of very serious PHP developers very happy. Not much point if
php_check_syntax immediately includes the file (string) though...
Previous Comments:
[2005-02-09 21:42:13] du at bestwaytech dot com
There is one other difference between include and php_check_syntax that
should be noted in the manual. Aside from supressing output buffer, it
only includes functions and classes, it does not set or affect global
variables, the way include() would.
If you have "test.php"
$myvar = 1;
echo $myvar;
function myfunction() {}
class myclass {}
include ("test.php") will set $myvar, print $myvar and set myfunction &
myclass
php_check_syntax("test.php") will ONLY include myfunction & myclass
[2005-01-29 04:35:48] wylie at geekasylum dot org
There seems to be a lot of discussion on whether this is a bug or a
misuse. Here is something else to consider:
de_bruut mentioned above that a syntax check function as described in
the documentation of this function would be useful for development and
testing, and I agree, but it also has other uses.
I am about to write a code repository website where users can submit
snippets (no smaller than complete functions) and it would be great to
be able to check the syntax of the uploaded code on the fly and reject
or accept it right there while the submitter is still online. This be
one less admin check to do before the code was accepted to the site.
Checking uploaded code snippets from the public is a huge security rick
if the syntax checker includes or executes the code, but a simple lint
check would be a huge boon to developers and code geeks like myself.
In my case, it would be fantastic if we could optionally syntax check a
string rather than a disk file as the code on my site would be stored in
a database (and I imagine many other repositories would do the same).
In the case of this bug a decision needs to be made as to whether the
code or the documentation expresses the true value of this function,
and one or other (ie: the code or the docco) needs to be fixed. This
bug has been open almost a year and it seems that decision still has
not been made.
If the documentation is correct and the function is a simple lint
checker, people can then include() any code that checks as valid if
they desire to, (some dont) but if the syntax checker includes the code
itself, then people like myself cant use it at all as the code to be
checked has no relation to the running website (and should never be
included).
[2005-01-25 20:12:15] [EMAIL PROTECTED]
fix assign to
[2005-01-25 19:56:39] [EMAIL PROTECTED]
It's like include() except it won't output the "checked" file (like if
the "checked" file has an echo, it won't echo it). Aside from the
obvious that's the only difference I notice but haven't tested it
thoroughly.
Sounds like this bug will never be fixed so I guess we should just
document the current behavior.
[2004-12-14 00:30:08] [EMAIL PROTECTED]
I see it's assigned to Ilia so I'm not changing the status. P
#32084 [NEW]: abekatter
From: heo at hep dot net Operating system: Windows PHP version: 4.3.9 PHP Bug Type: Feature/Change Request Bug description: abekatter Description: abekatter Reproduce code: --- abekatter Expected result: abekatter Actual result: -- abekatter -- Edit bug report at http://bugs.php.net/?id=32084&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32084&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32084&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32084&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32084&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32084&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32084&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32084&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32084&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32084&r=support Expected behavior: http://bugs.php.net/fix.php?id=32084&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32084&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32084&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32084&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32084&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32084&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32084&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32084&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32084&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32084&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32084&r=mysqlcfg
#31954 [Opn->Fbk]: Interbase returning bool - PHP crash
ID: 31954 Updated by: [EMAIL PROTECTED] Reported By: okke at formsma dot nl -Status: Open +Status: Feedback Bug Type: InterBase related Operating System: Windows XP SP1 PHP Version: 5.0.3 New Comment: Did you build php_interbase.dll from source, or did you use the pre-built one from php.net? Previous Comments: [2005-02-13 12:23:16] okke at formsma dot nl Description: I'm using interbase 7. I made a table using a BOOLEAN field. Everything worked fine, until I tried to extract data from the table. Then I found out that the BOOLEAN field was crashing PHP (and, in succession, apache). The error I got with PHP was (command line client): "Warning: ibase_fetch_assoc(): Dynamic SQL Error SQL error code = -804 Incorrect values within SQLDA structure in [...]" (for search-sake: the Apache error was "Parent: child process exited with status 3221225477 -- Restarting.") The problem is not a database failure; IBconsole and Database Workbench both handle the test-SQL perfectly. Reproduce code: --- I left the PHP code out, for readability. I'm using ibase_connect(), ibase_query() and ibase_fetch_assoc(). Run the following SQL first: CREATE TABLE TEST ( ID INTEGER NOT NULL, PUBLISHED BOOLEAN DEFAULT 0, CONSTRAINT PK_CMS PRIMARY KEY (ID) ) ; Fill the database with some lines, it doesn't matter what exactly: INSERT INTO TEST(ID, PUBLISHED) VALUES(1,false); INSERT INTO TEST(ID, PUBLISHED) VALUES(2,true); INSERT INTO TEST(ID, PUBLISHED) VALUES(3,false); INSERT INTO TEST(ID, PUBLISHED) VALUES(4,true); Then try to extract data from the database: SELECT * FROM TEST; Expected result: (after ibase_query()): an array with the values from the database. Actual result: -- A big fat error, where after PHP and Apache will crash. The problem occurs on the line with ibase_query(). -- Edit this bug report at http://bugs.php.net/?id=31954&edit=1
#32084 [Opn->Bgs]: abekatter
ID: 32084 Updated by: [EMAIL PROTECTED] Reported By: heo at hep dot net -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: Windows PHP Version: 4.3.9 New Comment: Play somewhere else. Previous Comments: [2005-02-23 20:50:31] heo at hep dot net Description: abekatter Reproduce code: --- abekatter Expected result: abekatter Actual result: -- abekatter -- Edit this bug report at http://bugs.php.net/?id=32084&edit=1
#29521 [Csd->Opn]: compress.bzip2 wrapper
ID: 29521 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: Bzip2 Related Operating System: all PHP Version: 5CVS-2004-08-04 (dev) New Comment: it now echoes another error: "Warning: fopen (compress.bzip2://http://pt2.php.net/backend/notes/all.bz2): failed to open stream: Invalid argument in bz2.php on line 3" Previous Comments: [2005-02-23 19:49:03] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2004-10-04 13:52:29] [EMAIL PROTECTED] I've compiled with --with-bz2 (and I'm using the snaps.php.net for windows) [2004-10-04 13:34:26] [EMAIL PROTECTED] You must build with --with-bz2, not --with-bzip2 [2004-10-04 12:10:51] [EMAIL PROTECTED] I know this may sound strange, but I can replicate this problem on my two machines (windows & linux) using latest HEAD. [2004-10-04 04:11:20] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. This bug was fixed in CVS. I absolutely cannot replicate the probem. 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/29521 -- Edit this bug report at http://bugs.php.net/?id=29521&edit=1
#32074 [Opn]: OID's missing from PHP snmpwalk compared with command line snmpwalk
ID: 32074
User updated by: Gregg dot Nelson at Co dot Ramsey dot MN dot US
Reported By: Gregg dot Nelson at Co dot Ramsey dot MN dot US
Status: Open
Bug Type: SNMP related
Operating System: ReHat 9.0
PHP Version: 5.0.3
New Comment:
The following bash script shows that snmpwalk and snmpget/getnext
produce the same number of lines and output
when called from the command line
#!/bin/bash
#
# Compare snmpwalk and snmpget/getnext output.
#
#set -vx
walkoid="SNMPv2-SMI::enterprises.9.9.161"
lc=$(snmpwalk -v2c -crmsy 192.168.108.254 $walkoid|wc -l)
echo snmpwalk: $lc lines.
startmib="$walkoid.1.1.1.1.2.0"
nextmib=$startmib
oper="snmpget";lc=0
while :; do
mib=$($oper -v2c -crmsy 192.168.108.254 $nextmib)
oper="snmpgetnext"
if [ $(echo $mib|grep ".9.9.161"|wc -l) -eq 0 ];then break;fi
# echo $mib
let lc=lc+1
nextmib=${mib%%\ =\ *}
done
echo snmpget/next: $lc lines.
exit
Previous Comments:
[2005-02-23 04:38:59] Gregg dot Nelson at Co dot Ramsey dot MN dot US
Description:
Running:
PHP-5.0.3
Net-SNMP-5.2.1
Apache-(httpd-2.0.530)
PHP config Line
./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-snmp
No changes to php.ini
---
Executing snmpwalk from command line (RH Linux 9) produces different
results from snmpwalk called from php.
I have a Cisco 6509 configured for Server Load Balancing.
The MIB tree for this starts at OID .1.3.6.1.4.1.9.9.161
With the following command from the Linux shell I get the folowing
results:
---
snmpwalk -v2c -crmsy 192.168.108.254 .1.3.6.1.4.1.9.9.161
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.2.0 = Counter32: 49602212
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.3.0 = Counter64: 49602212
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.4.0 = Counter32: 2776480
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.5.0 = Counter64: 2776480
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.6.0 = Counter32: 26014
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.7.0 = Counter64: 26014
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.8.0 = Counter32: 26013
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.9.0 = Counter64: 26013
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.10.0 = Counter32: 26014
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.11.0 = Counter64: 26014
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.12.0 = Counter32: 6
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.13.0 = Counter64: 6
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.14.0 = Counter32: 0
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.15.0 = Counter64: 0
SNMPv2-SMI::enterprises.9.9.161.1.2.1.1.2.0.8.67.65.70.69.84.69.83.84 =
INTEGER: 1
SNMPv2-SMI::enterprises.9.9.161.1.2.1.1.3.0.8.67.65.70.69.84.69.83.84 =
INTEGER: 3
SNMPv2-SMI::enterprises.9.9.161.1.2.1.1.4.0.8.67.65.70.69.84.69.83.84 =
Gauge32: 2
SNMPv2-SMI::enterprises.9.9.161.1.2.1.1.5.0.8.67.65.70.69.84.69.83.84 =
Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.2.1.1.6.0.8.67.65.70.69.84.69.83.84 =
INTEGER: 1
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.4.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= INTEGER: 2
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.4.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= INTEGER: 2
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.5.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.5.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.6.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.6.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.7.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 4294967295
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.7.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 4294967295
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.8.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 8
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.8.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 8
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.9.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 8
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.9.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 8
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.10.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.10.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.11.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 1
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.11.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 1
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.12.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= INTEGER: 360
SNMPv2-SMI::enterprises
#31597 [Opn->Csd]: ibase_connect() - incorrect warning
ID: 31597
Updated by: [EMAIL PROTECTED]
Reported By: 3tantes at inbox dot lv
-Status: Open
+Status: Closed
Bug Type: InterBase related
Operating System: Debian
PHP Version: 5.0.3
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2005-01-18 14:21:21] 3tantes at inbox dot lv
Description:
on
$rolename = "RO_WEBUSER";
$dbh = @ibase_connect($host, $usrname, $pswrd, "", 0, 3,
$rolename)
i get
Warning: ibase_connect() [function.ibase-connect.php]: bad
parameters on attach or create database CHARACTER SET RO_WEBUSER is not
defined in ...
it worked fine on php5.0.1.
maybe it's because the database charset is "NONE", so, when i try
$ibcharset = "NONE";
$rolename = "RO_WEBUSER";
$dbh = @ibase_connect($host, $usrname, $pswrd, $ibcharset, 0, 3,
$rolename);
it works fine on 5.0.3 too.
where's the problem? something's been changed?
Reproduce code:
---
$rolename = "RO_WEBUSER";
$serveraddr = "10.5.8.42";
$dbfilepath = "/home/girts/scr/db/scr.gdb";
$host = "{$serveraddr}:{$dbfilepath}";
if (!($dbh = @ibase_connect($host, $usrname, $pswrd, "", 0, 3,
$rolename))) {
echo "can't connect";
} else {
echo "connection ok";
}
Expected result:
connection ok
Actual result:
--
Warning: ibase_connect() [function.ibase-connect.php]: bad parameters
on attach or create database CHARACTER SET RO_WEBUSER is not defined in
...
can't connect
--
Edit this bug report at http://bugs.php.net/?id=31597&edit=1
#30114 [Opn->Fbk]: crash php-cli after "CREATE TABLE " and "DROP TABLE"
ID: 30114 Updated by: [EMAIL PROTECTED] Reported By: max at webscript dot ru -Status: Open +Status: Feedback Bug Type: InterBase related Operating System: Win XP Pro PHP Version: 5CVS-2004-09-16 (dev) New Comment: Please post the Interbase library versions returned by phpinfo() Previous Comments: [2004-09-16 14:45:00] max at webscript dot ru Description: when i try to create table via ibase_query() and then drop table it crash php (cli and mod_php) Table droped successfully but WinXP show window with error in php.exe (or apache.exe if i test it with mod_php) Reproduce code: --- $host = 'localhost:C:\BASE\MY.GDB'; $conn = ibase_connect($host, 'SYSDBA', 'masterkey'); $sql = "CREATE TABLE test_charset(ch varchar(200))"; ibase_query($conn, $sql) or die(ibase_errmsg()); $sql = "DROP TABLE test_charset"; ibase_query($conn, $sql) or die(ibase_errmsg()); Expected result: it must create table and then drop it without any errors and warnings Actual result: -- i got window whihc inform me, that error happened in php.exe. --- AppName: php.exe AppVer: 5.0.2.2 ModName: msvcrt.dll ModVer: 7.0.2600.0 Offset: 0002f548 -- Edit this bug report at http://bugs.php.net/?id=30114&edit=1
#30907 [Opn]: Apache crashes when inserting a -1 into a Interbase TIMESTAMP field
ID: 30907
Updated by: [EMAIL PROTECTED]
Reported By: sandell at slobtrot dot com
Status: Open
Bug Type: InterBase related
Operating System: WinXP Pro (SP2)
PHP Version: 5.0.2
New Comment:
Did you build php_interbase.dll from source, or did you use the
pre-built one from php.net?
Previous Comments:
[2004-11-26 14:24:25] sandell at slobtrot dot com
Description:
When inserting a -1 into a TIMESTAMP field in an interbase 7 database
Apache crashes. When looking at the "More info" in the WinXP crash
dialog it shows that it was mod "php_interbase.dll" that caused the
crash.
System setup:
Windows XP Pro, SP2
Apache/2.0.50 (Win32) (Win32 bin files downloaded)
PHP/5.0.2, extension INTERBASE used in php.ini
Interbase 7 (WI-V7.1.0.131), TCP/IP connection (Localhost)
No Zend optimizer
Note:
If a value of 0 (zero) is given in the statement, then all works as
expected.
Reproduce code:
---
1) Create the table "testtable" in a database with one field named
"DTField" of type TIMESTAMP.
2) Execute the following code:
// Crash Code
$db = ibase_connect('','','','None',0,3);
$sql = "INSERT INTO TestTable (DTField) VALUES (?)";
$sth = ibase_query($db_intra, $sql, -1);
ibase_commit($db);
Expected result:
The table should have a new entry
Actual result:
--
Apache crashes (php_interbase.dll)
--
Edit this bug report at http://bugs.php.net/?id=30907&edit=1
#30907 [Opn->Fbk]: Apache crashes when inserting a -1 into a Interbase TIMESTAMP field
ID: 30907
Updated by: [EMAIL PROTECTED]
Reported By: sandell at slobtrot dot com
-Status: Open
+Status: Feedback
Bug Type: InterBase related
Operating System: WinXP Pro (SP2)
PHP Version: 5.0.2
Previous Comments:
[2005-02-23 21:28:52] [EMAIL PROTECTED]
Did you build php_interbase.dll from source, or did you use the
pre-built one from php.net?
[2004-11-26 14:24:25] sandell at slobtrot dot com
Description:
When inserting a -1 into a TIMESTAMP field in an interbase 7 database
Apache crashes. When looking at the "More info" in the WinXP crash
dialog it shows that it was mod "php_interbase.dll" that caused the
crash.
System setup:
Windows XP Pro, SP2
Apache/2.0.50 (Win32) (Win32 bin files downloaded)
PHP/5.0.2, extension INTERBASE used in php.ini
Interbase 7 (WI-V7.1.0.131), TCP/IP connection (Localhost)
No Zend optimizer
Note:
If a value of 0 (zero) is given in the statement, then all works as
expected.
Reproduce code:
---
1) Create the table "testtable" in a database with one field named
"DTField" of type TIMESTAMP.
2) Execute the following code:
// Crash Code
$db = ibase_connect('','','','None',0,3);
$sql = "INSERT INTO TestTable (DTField) VALUES (?)";
$sth = ibase_query($db_intra, $sql, -1);
ibase_commit($db);
Expected result:
The table should have a new entry
Actual result:
--
Apache crashes (php_interbase.dll)
--
Edit this bug report at http://bugs.php.net/?id=30907&edit=1
#32074 [Opn]: OID's missing from PHP snmpwalk compared with command line snmpwalk
ID: 32074
User updated by: Gregg dot Nelson at Co dot Ramsey dot MN dot US
Reported By: Gregg dot Nelson at Co dot Ramsey dot MN dot US
Status: Open
Bug Type: SNMP related
Operating System: ReHat 9.0
PHP Version: 5.0.3
New Comment:
After a more careful comparison of the command line snmpwalk and the
PHP snmpwalk it appears the items missing from the PHP snmpwalk are the
Counter64 items.
Previous Comments:
[2005-02-23 21:18:48] Gregg dot Nelson at Co dot Ramsey dot MN dot US
The following bash script shows that snmpwalk and snmpget/getnext
produce the same number of lines and output
when called from the command line
#!/bin/bash
#
# Compare snmpwalk and snmpget/getnext output.
#
#set -vx
walkoid="SNMPv2-SMI::enterprises.9.9.161"
lc=$(snmpwalk -v2c -crmsy 192.168.108.254 $walkoid|wc -l)
echo snmpwalk: $lc lines.
startmib="$walkoid.1.1.1.1.2.0"
nextmib=$startmib
oper="snmpget";lc=0
while :; do
mib=$($oper -v2c -crmsy 192.168.108.254 $nextmib)
oper="snmpgetnext"
if [ $(echo $mib|grep ".9.9.161"|wc -l) -eq 0 ];then break;fi
# echo $mib
let lc=lc+1
nextmib=${mib%%\ =\ *}
done
echo snmpget/next: $lc lines.
exit
[2005-02-23 04:38:59] Gregg dot Nelson at Co dot Ramsey dot MN dot US
Description:
Running:
PHP-5.0.3
Net-SNMP-5.2.1
Apache-(httpd-2.0.530)
PHP config Line
./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-snmp
No changes to php.ini
---
Executing snmpwalk from command line (RH Linux 9) produces different
results from snmpwalk called from php.
I have a Cisco 6509 configured for Server Load Balancing.
The MIB tree for this starts at OID .1.3.6.1.4.1.9.9.161
With the following command from the Linux shell I get the folowing
results:
---
snmpwalk -v2c -crmsy 192.168.108.254 .1.3.6.1.4.1.9.9.161
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.2.0 = Counter32: 49602212
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.3.0 = Counter64: 49602212
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.4.0 = Counter32: 2776480
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.5.0 = Counter64: 2776480
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.6.0 = Counter32: 26014
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.7.0 = Counter64: 26014
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.8.0 = Counter32: 26013
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.9.0 = Counter64: 26013
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.10.0 = Counter32: 26014
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.11.0 = Counter64: 26014
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.12.0 = Counter32: 6
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.13.0 = Counter64: 6
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.14.0 = Counter32: 0
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.15.0 = Counter64: 0
SNMPv2-SMI::enterprises.9.9.161.1.2.1.1.2.0.8.67.65.70.69.84.69.83.84 =
INTEGER: 1
SNMPv2-SMI::enterprises.9.9.161.1.2.1.1.3.0.8.67.65.70.69.84.69.83.84 =
INTEGER: 3
SNMPv2-SMI::enterprises.9.9.161.1.2.1.1.4.0.8.67.65.70.69.84.69.83.84 =
Gauge32: 2
SNMPv2-SMI::enterprises.9.9.161.1.2.1.1.5.0.8.67.65.70.69.84.69.83.84 =
Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.2.1.1.6.0.8.67.65.70.69.84.69.83.84 =
INTEGER: 1
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.4.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= INTEGER: 2
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.4.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= INTEGER: 2
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.5.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.5.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.6.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.6.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.7.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 4294967295
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.7.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 4294967295
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.8.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 8
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.8.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 8
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.9.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 8
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.9.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 8
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.10.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.10.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 0
SNMPv2-SMI::enterprises.
#30073 [Opn->Fbk]: Exception handling not work for selectable procedures
ID: 30073
Updated by: [EMAIL PROTECTED]
Reported By: almad at dracidoupe dot cz
-Status: Open
+Status: Feedback
Bug Type: InterBase related
Operating System: Gentoo Linux
PHP Version: 5.0.1
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
Previous Comments:
[2004-09-13 14:31:55] almad at dracidoupe dot cz
Description:
When calling executable procedure, php works good, that means that
ibase_query returns FALSE and IBase_Errmsg() contains code and text of
exception returned by stored procedure.
However, when calling selectable procedure ("select a, b from
procedure_name"), ibase_query returns TRUE and exception is returned as
unhandlingable php warning when calling ibase_fetch_row/assoc/object.
Reproduce code:
---
$s = ibase_query ("select var from procedure_name");
If(!$s){
echo "FireBird returned error: ".IBase_Errmsg();
}
Else{
while($d=ibase_fetch_row($s)){
echo $d[0];
}
}
Expected result:
FireBird returned error: Some exception returned by procedure_name
Actual result:
--
Warning: ibase_fetch_assoc() [function.ibase-fetch-assoc]: exception 1
Some exception returned by procedure_name in /var/.../script.php on
line xx
--
Edit this bug report at http://bugs.php.net/?id=30073&edit=1
#30805 [Sus->Bgs]: broken db connection lost after fork
ID: 30805
Updated by: [EMAIL PROTECTED]
Reported By: rui dot francisco at fccn dot pt
-Status: Suspended
+Status: Bogus
Bug Type: InterBase related
Operating System: linux kernel 2.4.22
PHP Version: 5.0.2
New Comment:
.
Previous Comments:
[2005-01-13 22:26:16] [EMAIL PROTECTED]
Please provide an example that actually contains ibase_*() functions.
[2004-11-16 14:56:57] rui dot francisco at fccn dot pt
Description:
i query a db (firebird 1.5.1)for a resultset
I use a loop to go to all the records
in the record processing i fork ()
in there i use shell_exec with the no hup
terminate the child
in the parent i verify a log file
if the string i want is there i kill the child
wait for the child
when i try to update the db using the same db connection, or one new
its reports a broken pipe
The script was originally built using Pear DB, but i change it to ibase
function to garante that wasn't a Pear DB bug.
I compiled php with the following configuration
./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-ssl
--with-libxml --with-interbase=/opt/firebird --with-pear --with-zlib
--enable-sockets --enable-track-vars --enable-pcntl -enable-debug
My compiled modules
[EMAIL PROTECTED]:/usr/src/php-5.0.2# php -m
[PHP Modules]
ctype
dom
iconv
interbase
libxml
pcntl
pcre
posix
session
SimpleXML
sockets
SPL
SQLite
standard
tokenizer
xml
zlib
Thanks in advance
Rui Francisco
Reproduce code:
---
$pid=pcntl_fork();
if ($pid == -1)
{
echo "Erro ao efectuar o fork\n";
}
else if ($pid)
{
// we are the parent
$resultado='-';
//sleep(4);
while ($resultado=='-') {
sleep(2);
$a=shell_exec("cat xsupplicant.log");
if (strpos($a,'Failure',0)) {
$resultado='SC';
shell_exec('ifconfig '.$vInterface.' down');
shell_exec('killall xsupplicant');
sleep(2);
shell_exec('ifconfig '.$vInterface.' up');
}
if (strpos($a,'Authenticated',0))
$resultado='A';
}
pcntl_wait($status);
}
else
{
// we are the child
ob_start();
shell_exec('killall xsupplicant 2>&1');
shell_exec('rm /var/run/xsupplicant 2>&1');
ob_end_clean();
sleep(1);
$a=shell_exec("nohup xsupplicant -c conf_teste.conf -i
".$vInterface." & ");
exit (0);
}
echo $vDominio." - ".$resultado."\n";
Expected result:
update the database, no message
Actual result:
--
Warning: ibase_query(): Unable to complete network request to host
"localhost". Error writing data to the connection. Broken pipe in
/web/roam/test_connectivity.php on line 210
Unable to complete network request to host "localhost". Error writing
data to the connection. Broken pipe
--
Edit this bug report at http://bugs.php.net/?id=30805&edit=1
#32085 [NEW]: configure fails due to missing 'ld'
From: clint dot box at eds dot com Operating system: z/os 1.4 PHP version: 5.0.3 PHP Bug Type: *Compile Issues Bug description: configure fails due to missing 'ld' Description: Getting the following error attempting to install on z/os: Configuring libtool checking for Cygwin environment... no checking for mingw32 environment... no checking build system type... i370-ibm-openedition checking for non-GNU ld... no configure: error: no acceptable ld found in $PATH I have all of the pre-requisite software installed but still get this. Is there something missing that should be mentioned on the pre-requisite software listing? -- Edit bug report at http://bugs.php.net/?id=32085&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32085&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32085&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32085&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32085&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32085&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32085&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32085&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32085&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32085&r=support Expected behavior: http://bugs.php.net/fix.php?id=32085&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32085&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32085&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32085&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32085&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32085&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32085&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32085&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32085&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32085&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32085&r=mysqlcfg
#32086 [NEW]: strtotime don't work in DST
From: marcus at corp dot grupos dot com dot br
Operating system: FreeBSD 4.11-STABLE
PHP version: 4.3.10
PHP Bug Type: Date/time related
Bug description: strtotime don't work in DST
Description:
If timestamp don't exist, FreeBSD mktime() return -1 is correct. This case
occurs when use strtotime and have Daylight Save Time in timezone.
Example:
If DST save 1 hour and begin on 2004/11/02 00:00, timestamp between 00:00
and 01:00 don't exists.
I fix with this patch, but I find that it is not the best skill.
-- begin patch --
--- ext/standard/parsedate.c.orig Tue Dec 14 15:55:22 2004
+++ ext/standard/parsedate.cMon Feb 14 14:43:08 2005
@@ -2211,9 +2211,9 @@
date.yyHaveTime = 0;
date.yyHaveZone = 0;
- if (yyparse ((void *)&date)
- || date.yyHaveTime > 1 || date.yyHaveZone > 1
- || date.yyHaveDate > 1 || date.yyHaveDay > 1)
+ if (yyparse ((void *)&date))
+// || date.yyHaveTime > 1 || date.yyHaveZone > 1
+// || date.yyHaveDate > 1 || date.yyHaveDay > 1)
return -1;
tm.tm_year = ToYear (date.yyYear) - TM_YEAR_ORIGIN + date.yyRelYear;
@@ -2272,7 +2272,28 @@
}
if (Start == (time_t) -1)
- return Start;
+ {
+ tm = tm0;
+ while((Start = mktime(&tm)) == -1 && tm.tm_year > 68 &&
tm.tm_year < 138)
+ {
+ if (tm.tm_isdst == 0)
+ {
+ tm.tm_isdst = -1;
+ if (tm.tm_min < 59) {
+ tm.tm_min += 1;
+ } else {
+ tm.tm_min = 0;
+ if (tm.tm_hour < 23) {
+ tm.tm_hour += 1;
+ } else {
+ tm.tm_hour = 0;
+ tm.tm_mday += 1;
+ }
+ }
+ }
+ }
+ return Start;
+ }
}
if (date.yyHaveDay && !date.yyHaveDate)
-- end patch --
Reproduce code:
---
America/Sao_Paulo DST begin on 2004/11/02 00:00 and terminate on
2005/02/20 00:00
Expected result:
1099278000
1099364400
1108778400
1108864800
Actual result:
--
1099278000
-1
1108778400
1108864800
--
Edit bug report at http://bugs.php.net/?id=32086&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32086&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32086&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32086&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32086&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32086&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32086&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32086&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32086&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32086&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32086&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32086&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32086&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32086&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32086&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32086&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32086&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32086&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32086&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32086&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32086&r=mysqlcfg
#32086 [Opn->Asn]: strtotime don't work in DST
ID: 32086
Updated by: [EMAIL PROTECTED]
Reported By: marcus at corp dot grupos dot com dot br
-Status: Open
+Status: Assigned
Bug Type: Date/time related
Operating System: FreeBSD 4.11-STABLE
PHP Version: 4.3.10
-Assigned To:
+Assigned To: derick
Previous Comments:
[2005-02-23 22:01:34] marcus at corp dot grupos dot com dot br
Description:
If timestamp don't exist, FreeBSD mktime() return -1 is correct. This
case occurs when use strtotime and have Daylight Save Time in
timezone.
Example:
If DST save 1 hour and begin on 2004/11/02 00:00, timestamp between
00:00 and 01:00 don't exists.
I fix with this patch, but I find that it is not the best skill.
-- begin patch --
--- ext/standard/parsedate.c.orig Tue Dec 14 15:55:22 2004
+++ ext/standard/parsedate.cMon Feb 14 14:43:08 2005
@@ -2211,9 +2211,9 @@
date.yyHaveTime = 0;
date.yyHaveZone = 0;
- if (yyparse ((void *)&date)
- || date.yyHaveTime > 1 || date.yyHaveZone > 1
- || date.yyHaveDate > 1 || date.yyHaveDay > 1)
+ if (yyparse ((void *)&date))
+// || date.yyHaveTime > 1 || date.yyHaveZone > 1
+// || date.yyHaveDate > 1 || date.yyHaveDay > 1)
return -1;
tm.tm_year = ToYear (date.yyYear) - TM_YEAR_ORIGIN +
date.yyRelYear;
@@ -2272,7 +2272,28 @@
}
if (Start == (time_t) -1)
- return Start;
+ {
+ tm = tm0;
+ while((Start = mktime(&tm)) == -1 && tm.tm_year > 68 &&
tm.tm_year < 138)
+ {
+ if (tm.tm_isdst == 0)
+ {
+ tm.tm_isdst = -1;
+ if (tm.tm_min < 59) {
+ tm.tm_min += 1;
+ } else {
+ tm.tm_min = 0;
+ if (tm.tm_hour < 23) {
+ tm.tm_hour += 1;
+ } else {
+ tm.tm_hour = 0;
+ tm.tm_mday += 1;
+ }
+ }
+ }
+ }
+ return Start;
+ }
}
if (date.yyHaveDay && !date.yyHaveDate)
-- end patch --
Reproduce code:
---
America/Sao_Paulo DST begin on 2004/11/02 00:00 and terminate on
2005/02/20 00:00
Expected result:
1099278000
1099364400
1108778400
1108864800
Actual result:
--
1099278000
-1
1108778400
1108864800
--
Edit this bug report at http://bugs.php.net/?id=32086&edit=1
#30597 [Com]: GETTEXT strings occasionally don't get translated
ID: 30597 Comment by: wolfgang dot pichler at ivv dot tuwien dot ac dot at Reported By: schnaaf at home dot nl Status: No Feedback Bug Type: Gettext related Operating System: FreeBSD 4.7 PHP Version: 4.3.8 New Comment: same phenomenon observed in project www.emilda.org from different people with different versions of apache,php,gettext,linux VERY SPURIOUS i would think it is some major php design bug :-) Previous Comments: [2005-01-15 01:00:08] 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-01-07 15:56:11] alain at parkautomat dot net http://parkautomat.net/php4gettextbug.tar.gz It includes a sample php file and some translated messages. This shows the exact problem here. Distribution: Debian GNU/Linux Versions: gettext0.14.1 php4 4.3.9 apache 1.3.26.1 [2005-01-07 15:03:56] [EMAIL PROTECTED] 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 avoid embedding huge scripts into the report. [2005-01-07 14:38:34] alain at parkautomat dot net I updated to the newest gettext and I still have the problem. It only shows on texts with german 'Umlaut's as sources. All other text fragments are translated, just those with the Umlauts are not translated - most of the time. It looks like it only translates one entry and leaves the others untranslated. [2004-11-24 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". 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/30597 -- Edit this bug report at http://bugs.php.net/?id=30597&edit=1
#31954 [Fbk->Opn]: Interbase returning bool - PHP crash
ID: 31954 User updated by: okke at formsma dot nl Reported By: okke at formsma dot nl -Status: Feedback +Status: Open Bug Type: InterBase related Operating System: Windows XP SP1 PHP Version: 5.0.3 New Comment: I used the pre-built one from PHP.net Previous Comments: [2005-02-23 20:51:04] [EMAIL PROTECTED] Did you build php_interbase.dll from source, or did you use the pre-built one from php.net? [2005-02-13 12:23:16] okke at formsma dot nl Description: I'm using interbase 7. I made a table using a BOOLEAN field. Everything worked fine, until I tried to extract data from the table. Then I found out that the BOOLEAN field was crashing PHP (and, in succession, apache). The error I got with PHP was (command line client): "Warning: ibase_fetch_assoc(): Dynamic SQL Error SQL error code = -804 Incorrect values within SQLDA structure in [...]" (for search-sake: the Apache error was "Parent: child process exited with status 3221225477 -- Restarting.") The problem is not a database failure; IBconsole and Database Workbench both handle the test-SQL perfectly. Reproduce code: --- I left the PHP code out, for readability. I'm using ibase_connect(), ibase_query() and ibase_fetch_assoc(). Run the following SQL first: CREATE TABLE TEST ( ID INTEGER NOT NULL, PUBLISHED BOOLEAN DEFAULT 0, CONSTRAINT PK_CMS PRIMARY KEY (ID) ) ; Fill the database with some lines, it doesn't matter what exactly: INSERT INTO TEST(ID, PUBLISHED) VALUES(1,false); INSERT INTO TEST(ID, PUBLISHED) VALUES(2,true); INSERT INTO TEST(ID, PUBLISHED) VALUES(3,false); INSERT INTO TEST(ID, PUBLISHED) VALUES(4,true); Then try to extract data from the database: SELECT * FROM TEST; Expected result: (after ibase_query()): an array with the values from the database. Actual result: -- A big fat error, where after PHP and Apache will crash. The problem occurs on the line with ibase_query(). -- Edit this bug report at http://bugs.php.net/?id=31954&edit=1
#32090 [NEW]: fopen(..., 'wt') - fwrite($fp, ...) translates \n to \r
From: ceefour at gauldong dot net
Operating system: Windows XP SP1
PHP version: 5.0.3
PHP Bug Type: Filesystem function related
Bug description: fopen(..., 'wt') - fwrite($fp, ...) translates \n to \r
Description:
Using 'wt' (write-text), any \n should be translated to \r\n (0D 0A).
However in my system, PHP 5.0.3 in Windows XP SP1, this mode translates \n
to \r only (0D), which results in MAC-style line endings.
I had to use 'wb' (write-binary) and put \r\n manually to get desired
results.
Reproduce code:
---
$fp = fopen('anyfile.txt', 'wt');
fwrite($fp, "Hello\n");
fclose($fp);
Expected result:
anyfile.txt contains "Hello" + 0D 0A (\r \n)
Actual result:
--
anyfile.txt contains "Hello" + 0D (\r only)
--
Edit bug report at http://bugs.php.net/?id=32090&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32090&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32090&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32090&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32090&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32090&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32090&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32090&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32090&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32090&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32090&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32090&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32090&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32090&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32090&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32090&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32090&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32090&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32090&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32090&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32090&r=mysqlcfg
#32090 [Opn]: fopen(..., 'wt') - fwrite($fp, ...) translates \n to \r
ID: 32090
User updated by: ceefour at gauldong dot net
Reported By: ceefour at gauldong dot net
Status: Open
Bug Type: Filesystem function related
Operating System: Windows XP SP1
PHP Version: 5.0.3
New Comment:
BTW, for *PORTABILITY* I choose 't' (text mode), so it works both for
UNIXes and Windows, even MACs.
I don't want to do this:
fopen(, 'wb')
if (strpos('win', strtolower(PHP_OS)) !== false) {
$line_ending = "\r\n";
} else {
$line_ending = "\n";
}
which is NOT PORTABLE AT ALL. Why do you suggest 'b' mode will be more
portable? The documentation is weird, IMHO.
Previous Comments:
[2005-02-24 00:02:06] ceefour at gauldong dot net
Description:
Using 'wt' (write-text), any \n should be translated to \r\n (0D 0A).
However in my system, PHP 5.0.3 in Windows XP SP1, this mode translates
\n to \r only (0D), which results in MAC-style line endings.
I had to use 'wb' (write-binary) and put \r\n manually to get desired
results.
Reproduce code:
---
$fp = fopen('anyfile.txt', 'wt');
fwrite($fp, "Hello\n");
fclose($fp);
Expected result:
anyfile.txt contains "Hello" + 0D 0A (\r \n)
Actual result:
--
anyfile.txt contains "Hello" + 0D (\r only)
--
Edit this bug report at http://bugs.php.net/?id=32090&edit=1
#29726 [Fbk->NoF]: Streams socket functionality
ID: 29726 Updated by: php-bugs@lists.php.net Reported By: lists at cyberlot dot net -Status: Feedback +Status: No Feedback Bug Type: Sockets related Operating System: Fedora Core 2 PHP Version: 5.0.1 New Comment: 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". Previous Comments: [2005-02-15 00:17:44] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip [2004-09-10 13:58:59] [EMAIL PROTECTED] Please be more specific in what the problem is. Note: - PHP fgets() is line based and binary safe, changing it would break things. It only returns lines, or the last partial line before the socket (or file) is closed. - If you want to break lines on multiple different characters, you need to code your own buffer handling yourself. See stream_socket_select() for a way to avoid blocking and writing multiplexing socket servers. [2004-08-18 21:09:35] lists at cyberlot dot net This problem only exists with fread, fget which multiple examples in the docs use and the docs list as "See Also" functions. However by using stream_socket_recvfrom this problem was resovled.. This function is not at this time referenced in the manual other in the functions list so might easily overlooked as I did. One possible issue I do see, stream_socket_recvfrom looks to work because it pulls everything in the buffer up to X bytes regardless of any EOL character. On a slow single line entry settup this shouldn't be a problem and everything should work fine.. Under high load when data ends up being buffered at both sides this function would return only partial "blocks" of what a user might expect and the user would need to program his own internal buffering that checks for EOL. This should be covered in more detail in the online manual. [2004-08-18 00:59:26] lists at cyberlot dot net Description: switched from socket functions to stream functions for socket server usage because streams is supposed to be stable, and are included by default.. The problem socket_read supports PHP_NORMAL_READ which allows it to see flashes \0 as EOL... This is not possible when using streams to create a socket server as fget does not see \0 as EOL Expected result: Expect fgets to return data at \0 Actual result: -- Nothing is returned until the buffer is filled. -- Edit this bug report at http://bugs.php.net/?id=29726&edit=1
#32090 [Opn->Fbk]: fopen(..., 'wt') - fwrite($fp, ...) translates \n to \r
ID: 32090
Updated by: [EMAIL PROTECTED]
Reported By: ceefour at gauldong dot net
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: Windows XP SP1
PHP Version: 5.0.3
New Comment:
Please provide a complete test case; most of these so called bug
reports are due to the person viewing the data using the wrong tools.
FYI: "text mode" is an evil invention that usually leads to trouble.
It is generally better for the programmer to be explicit with their
line endings, as it leads to a lower WTF? factor.
Previous Comments:
[2005-02-24 00:10:09] ceefour at gauldong dot net
BTW, for *PORTABILITY* I choose 't' (text mode), so it works both for
UNIXes and Windows, even MACs.
I don't want to do this:
fopen(, 'wb')
if (strpos('win', strtolower(PHP_OS)) !== false) {
$line_ending = "\r\n";
} else {
$line_ending = "\n";
}
which is NOT PORTABLE AT ALL. Why do you suggest 'b' mode will be more
portable? The documentation is weird, IMHO.
[2005-02-24 00:02:06] ceefour at gauldong dot net
Description:
Using 'wt' (write-text), any \n should be translated to \r\n (0D 0A).
However in my system, PHP 5.0.3 in Windows XP SP1, this mode translates
\n to \r only (0D), which results in MAC-style line endings.
I had to use 'wb' (write-binary) and put \r\n manually to get desired
results.
Reproduce code:
---
$fp = fopen('anyfile.txt', 'wt');
fwrite($fp, "Hello\n");
fclose($fp);
Expected result:
anyfile.txt contains "Hello" + 0D 0A (\r \n)
Actual result:
--
anyfile.txt contains "Hello" + 0D (\r only)
--
Edit this bug report at http://bugs.php.net/?id=32090&edit=1
#32090 [Fbk->Opn]: fopen(..., 'wt') - fwrite($fp, ...) translates \n to \r
ID: 32090
User updated by: ceefour at gauldong dot net
Reported By: ceefour at gauldong dot net
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: Windows XP SP1
PHP Version: 5.0.3
New Comment:
Hi Mr. Furlong! Thanks for the feedback.
The test case is complete. And I'm viewing it using a hex editor
(doesn't matter which). The "Hello\n" will output exactly 6 bytes, the
Hello and the 0D (\r). It's a MAC document, as detected by a good text
editor. If you try to output more lines, i.e., "Hello\nWorld", the text
will get concatenated if you try to use Notepad. Viewing it in WordPad
or any other good text editor works fine.
>FYI: "text mode" is an evil invention that usually leads to trouble.
I agree with you. But it doesn't solve the problem. As stated in my
previous problem, I can write code which use explicit line endings, but
that will require me to write "if" statements for who-knows-how-many
platforms I will need to support. It's easier that way.
Do you know setlocale() ? Yeah, try EXPLICITLY specifying your
locale-specific formats without using strftime()-s formats and/or
setlocale(). Things like this IMHO should be handled at lower levels of
abstraction. And even if not, the lower level library should give the
programmer a choice, i.e.: "we recommend you NOT to use it but if you
use it we guarantee it will work correctly". In this case 'wt' doesn't
work correctly.
BTW I can even e-mail you the exact script, the exact generated file,
and even my entire PHP installation if you want to. ;-)
BTW in case you're wondering I use the mbstring extension with UTF-8
internal encoding specified in php.ini... but it shouldn't matter,
should it?
Previous Comments:
[2005-02-24 01:52:04] [EMAIL PROTECTED]
Please provide a complete test case; most of these so called bug
reports are due to the person viewing the data using the wrong tools.
FYI: "text mode" is an evil invention that usually leads to trouble.
It is generally better for the programmer to be explicit with their
line endings, as it leads to a lower WTF? factor.
[2005-02-24 00:10:09] ceefour at gauldong dot net
BTW, for *PORTABILITY* I choose 't' (text mode), so it works both for
UNIXes and Windows, even MACs.
I don't want to do this:
fopen(, 'wb')
if (strpos('win', strtolower(PHP_OS)) !== false) {
$line_ending = "\r\n";
} else {
$line_ending = "\n";
}
which is NOT PORTABLE AT ALL. Why do you suggest 'b' mode will be more
portable? The documentation is weird, IMHO.
[2005-02-24 00:02:06] ceefour at gauldong dot net
Description:
Using 'wt' (write-text), any \n should be translated to \r\n (0D 0A).
However in my system, PHP 5.0.3 in Windows XP SP1, this mode translates
\n to \r only (0D), which results in MAC-style line endings.
I had to use 'wb' (write-binary) and put \r\n manually to get desired
results.
Reproduce code:
---
$fp = fopen('anyfile.txt', 'wt');
fwrite($fp, "Hello\n");
fclose($fp);
Expected result:
anyfile.txt contains "Hello" + 0D 0A (\r \n)
Actual result:
--
anyfile.txt contains "Hello" + 0D (\r only)
--
Edit this bug report at http://bugs.php.net/?id=32090&edit=1
#27023 [Com]: CURL: CURLOPT_POSTFIELDS does not parse content types for files
ID: 27023
Comment by: jplock at yahoo dot com
Reported By: brianl at stcu dot org
Status: Open
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 4CVS, 5CVS
New Comment:
I would very much like this functionality to be implemented in PHP5 as
I need it for a project I am currently developing. Thanks.
Previous Comments:
[2004-03-07 11:54:50] brianl at stcu dot org
Since curl's ability to guess the MIME type of a file by extension is
extremely limited, this represents a very important enhancement for any
upload where the MIME type is used.
[2004-01-25 19:02:13] [EMAIL PROTECTED]
This is not bug but feature request.
Passing just "@/path/to/file.ext" works fine.
The content-type is detected by curl (if it can).
Reclassified.
[2004-01-23 13:26:19] brianl at stcu dot org
Description:
>From the cURL manual:
If you want the contents to be read from a file, use <@filename> as
contents. When specifying a file, you can also specify the file content
type by appending ';type=' to the file name.
However, specifing MIME types is not currently supported within PHP.
Reproduce code:
---
$ch= curl_init('http://www.example.com/fupl.php');
curl_setopt($ch,CURLOPT_RETURNTRANSFER,1);
curl_setopt($ch,CURLOPT_POSTFIELDS,
array('field1'=>'1','field2'=>'2','file'=>'@filepath.ext;type=application/xml'));
$result= curl_exec($ch);
curl_close($ch);
Expected result:
The file should be uploaded with a Content-Type: application/xml
header.
Actual result:
--
The entire call fails.
--
Edit this bug report at http://bugs.php.net/?id=27023&edit=1
#32091 [NEW]: PCRE 5.0 ugprade request
From: ceefour at gauldong dot net Operating system: All PHP version: 5.0.3 PHP Bug Type: PCRE related Bug description: PCRE 5.0 ugprade request Description: PCRE 5.0 is already out and ripe for grabbing. The most important feature is IMHO the ability to match general category properties of Unicode/UTF-8 strings, which is *VERY* useful for internationalized sites. I hope this will be implemented as soon as possible. Even an updated extension will be much better if it's not contained in the next release of PHP. -- Edit bug report at http://bugs.php.net/?id=32091&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32091&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32091&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32091&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32091&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32091&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32091&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32091&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32091&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32091&r=support Expected behavior: http://bugs.php.net/fix.php?id=32091&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32091&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32091&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32091&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32091&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32091&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32091&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32091&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32091&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32091&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32091&r=mysqlcfg
#31954 [Opn->Fbk]: Interbase returning bool - PHP crash
ID: 31954 Updated by: [EMAIL PROTECTED] Reported By: okke at formsma dot nl -Status: Open +Status: Feedback Bug Type: InterBase related Operating System: Windows XP SP1 PHP Version: 5.0.3 New Comment: Please try if the error can be reproduced with a php_interbase.dll built from source using the ibase.h header file that comes with Interbase 7.1 Previous Comments: [2005-02-23 22:44:05] okke at formsma dot nl I used the pre-built one from PHP.net [2005-02-23 20:51:04] [EMAIL PROTECTED] Did you build php_interbase.dll from source, or did you use the pre-built one from php.net? [2005-02-13 12:23:16] okke at formsma dot nl Description: I'm using interbase 7. I made a table using a BOOLEAN field. Everything worked fine, until I tried to extract data from the table. Then I found out that the BOOLEAN field was crashing PHP (and, in succession, apache). The error I got with PHP was (command line client): "Warning: ibase_fetch_assoc(): Dynamic SQL Error SQL error code = -804 Incorrect values within SQLDA structure in [...]" (for search-sake: the Apache error was "Parent: child process exited with status 3221225477 -- Restarting.") The problem is not a database failure; IBconsole and Database Workbench both handle the test-SQL perfectly. Reproduce code: --- I left the PHP code out, for readability. I'm using ibase_connect(), ibase_query() and ibase_fetch_assoc(). Run the following SQL first: CREATE TABLE TEST ( ID INTEGER NOT NULL, PUBLISHED BOOLEAN DEFAULT 0, CONSTRAINT PK_CMS PRIMARY KEY (ID) ) ; Fill the database with some lines, it doesn't matter what exactly: INSERT INTO TEST(ID, PUBLISHED) VALUES(1,false); INSERT INTO TEST(ID, PUBLISHED) VALUES(2,true); INSERT INTO TEST(ID, PUBLISHED) VALUES(3,false); INSERT INTO TEST(ID, PUBLISHED) VALUES(4,true); Then try to extract data from the database: SELECT * FROM TEST; Expected result: (after ibase_query()): an array with the values from the database. Actual result: -- A big fat error, where after PHP and Apache will crash. The problem occurs on the line with ibase_query(). -- Edit this bug report at http://bugs.php.net/?id=31954&edit=1
