#36933 [Bgs]: Fatal error: Function name must be a string in line no 1600 in smarty.class.ph
ID: 36933
User updated by: sudha_seeni at yahoo dot co dot in
Reported By: sudha_seeni at yahoo dot co dot in
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: windows xp
PHP Version: 5.1.2
New Comment:
php 5.1.1,mysql 5.0.18,windows xp,xampp 1.5.1
see i have installed xampp 1.5.1 which itself has mysql,phpmyadmin..
i have to open in browser as
http://localhost/leadtrac_project/index.php.for this i am getting a
error:-
Fatal error: Function name must be a string in line no 1600 in
smarty.class.php
Previous Comments:
[2006-04-03 07:39:31] sudha_seeni at yahoo dot co dot in
http://localhost/leadtrac/';
// $configVars['siteBasePath']='C:\\Program Files\\Apache
Group\\Apache\\htdocs\\leadtrac\\';
$configVars['siteBaseUrl'] =
'http://localhost/leadtrac_project/';
$configVars['siteBasePath']='C:\\Program
Files\\xampp\\htdocs\\leadtrac_project\\';
$dbConfig['dbhost'] = 'localhost';
$dbConfig['dbname'] = 'leadtrac_db2';
$dbConfig['dbuser'] = 'root';
$dbConfig['dbpass'] = 'pass';
$dbConfig['dbType'] = 'mysql';
$configVars['dncCode'] ='8a8s5t6u9d6n4c8';
//absolute path to smarty
//require('C:\\Satish\\PHP_DOCS\\smarty\\Smarty-2.6.10\\libs\\Smarty.class.php');
require('C:\Program
Files\xampp\php\pear\PhpDocumentor\phpDocumentor\Smarty-2.5.0\libs\Smarty.class.php');
}
$configVars['admin'] = 'admin/';
$configVars['user'] = '';
$configVars['system'] = 'system/';
$configVars['leads'] = 'leads/';
//$configVars['ecommerce'] = 'shopping/';
$configVars['magicFile'] = 'index.php'; // the file that handles all
the $actions.z
$configVars['include'] = 'include/';
$configVars['includeDirectory']=$configVars['siteBasePath'].$configVars['include'];
/*
*/
include($configVars['includeDirectory'].'PHP_timer.class.php');
$leadtracTimer = new PHP_timer();
$leadtracTimer->start();
$isMobile = false;
include($configVars['includeDirectory'].'myMobile.php');
//$isMobile = true;
if($isMobile)
{
$configVars['templates'] = 'mobileTemplates/';
$configVars['templates_c'] = 'mobileTemplates_c/';
$configVars['adminTemplates_c'] = 'adminTemplates_c/';
}
else
{
$configVars['templates'] = 'templates/';
$configVars['templates_c'] = 'templates_c/';
$configVars['adminTemplates_c'] = 'adminTemplates_c/';
}
$configVars['images'] = 'images/';
$configVars['htmlAreaUrl'] = $configVars['siteBaseUrl'].'htmlarea/';
$configVars['smartyDirectory']=$configVars['siteBasePath'].'smarty/';
$configVars['pearDirectory']=$configVars['siteBasePath'].'pear/';
$configVars['compiledTemplatesDirectory'] =
$configVars['siteBasePath'].$configVars['templates_c'];
$configVars['adminCompiledTemplatesDirectory'] =
$configVars['siteBasePath'].$configVars['adminTemplates_c'];
$configVars['loginUrl'] =
$configVars['siteBaseUrl'].'index.php?page=login';
$configVars['commonTemplates'] =
$configVars['siteBasePath'].$configVars['templates'];
$configVars['adminBaseUrl'] =
$configVars['siteBaseUrl'].$configVars['admin'];
$configVars['adminBasePath'] =
$configVars['siteBasePath'].$configVars['admin'];
$configVars['adminTemplates'] =
$configVars['siteBasePath'].$configVars['admin'].$configVars['templates'];
$configVars['adminSystemBaseUrl'] =
$configVars['siteBaseUrl'].$configVars['admin'].$configVars['system'];
$configVars['adminSystemBasePath'] =
$configVars['siteBasePath'].$configVars['admin'].$configVars['system'];
$configVars['adminLeadsBaseUrl'] =
$configVars['siteBaseUrl'].$configVars['admin'].$configVars['leads'];
$configVars['adminLeadsBasePath'] =
$configVars['siteBasePath'].$configVars['admin'].$configVars['leads'];
$configVars['userBaseUrl'] =
$configVars['siteBaseUrl'].$configVars['user'];
$configVars['userBasePath'] =
$configVars['siteBasePath'].$configVars['user'];
$configVars['userTemplates'] =
$configVars['siteBasePath'].$configVars['user'].$configVars['templates'];
$configVars['userSystemBaseUrl'] =
$configVars['siteBaseUrl'].$configVars['user'].$configVars['system'];
$configVars['userSystemBasePath'] =
$configVars['siteBasePath'].$configVars['user'].$configVars['system'];
$configVars['userLeadsBaseUrl'] =
$configVars['siteBaseUrl'].$configVars['user'].$configVars['leads'];
$configVars['userLeadsBasePath'] =
$configVars['siteBasePath'].$configVars['user'].$configVars['leads'];
$configVars['userListingTemplates'] =
$configVars['userListingBasePath'].$configVars['templates'];
$configVars['imageBaseUrl'] = $configVars['siteBaseUrl'].'images/';
$configVars['imageBasePath'] = $configVars['siteBasePath'].'images/';
$configVars['overlibPath'] =
$configVars['siteBaseUrl'].'include/overlib.js';
$configVars['htmlAreaUrl'] = $configVars['siteBaseUrl'].'htmlarea/';
$configVars['propertyImportFilesPath'] =
$configVars['siteBasePath'].'docs/';
$configVars['dncImportFilesPath'] =
$configVars['siteBasePath'].'docs/dnc/';
$configVars['userPropertyImportFilesPath'] =
$configVars['siteBasePa
#36880 [Opn->Csd]: OciLogon crashes apache
ID: 36880 User updated by: jbond007 at atsat dot com Reported By: jbond007 at atsat dot com -Status: Open +Status: Closed Bug Type: OCI8 related Operating System: Linux RH4 PHP Version: 5.1.2 New Comment: On OCI8 documentation, the ORA_NLS33 seems to be optional. But it's not. A correct value for this env var resolved my problem. Previous Comments: [2006-03-31 16:03:23] jbond007 at atsat dot com I could install oracle 10.2g normally, even could apply the patch 10.2.0.2 with no problem. I configured the whole database. Even Import production data from my old server. Could use configuration tools to connect and configure the database. Could run a little php script in CLI mode which could connect to Oracle. Fails only when we have Apache+Php, Apache Any version (1.XX or 2.XX) and Php Any version (4 or 5). [2006-03-31 15:56:04] [EMAIL PROTECTED] Still can't reproduce it. Please check that you're able to run and use other Oracle applications. [2006-03-31 15:35:11] jbond007 at atsat dot com When it occurs when it happens without I click on anything on my php page, it's only when php is compiled with debug activated. [2006-03-29 15:05:57] [EMAIL PROTECTED] >It even happened without I click on anything on my php page. Apparently this means that it's not PHP problem. [2006-03-29 14:58:21] jbond007 at atsat dot com I think I needn't test it with Instant client, as the segmentation fault could happen randomly and without using Oracle. It even happened without I click on anything on my php page. 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/36880 -- Edit this bug report at http://bugs.php.net/?id=36880&edit=1
#36956 [Opn->Bgs]: dirname returns \ for root /
ID: 36956
Updated by: [EMAIL PROTECTED]
Reported By: e dot vandeoudeweetering at marcanti dot esprit-sg dot
-Status: Open
+Status: Bogus
Bug Type: Directory function related
Operating System: Windows 2000 (5.00.2195) SP4
PHP Version: 5.1.2
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
This is expected, as Window$ uses \ everywhere instead of / on *nix.
Previous Comments:
[2006-04-03 13:33:19] e dot vandeoudeweetering at marcanti dot
esprit-sg dot
Description:
When using the function dirname, \ is returned for the root directory
/
This is what the documentation says:
//after PHP 4.3.0
dirname('c:/'); // returns 'c:'
Reproduce code:
---
print dirname('/');
print dirname('C:/');
print dirname('C:\\'); //this function works
Expected result:
/
C:
C:\
Actual result:
--
\
C:\
C:\
--
Edit this bug report at http://bugs.php.net/?id=36956&edit=1
#31701 [Opn->WFx]: (mis-) use of undeclared attributes
ID: 31701
Updated by: [EMAIL PROTECTED]
Reported By: attibln at gmx dot net
-Status: Open
+Status: Wont fix
Bug Type: Feature/Change Request
Operating System: linux
PHP Version: 5.0.3
New Comment:
This won't change in the nearest future.
Previous Comments:
[2005-01-29 18:01:43] attibln at gmx dot net
thx :)
[2005-01-28 23:19:46] [EMAIL PROTECTED]
Reclassified as feature request as there is no bug here.
[2005-01-26 19:50:17] attibln at gmx dot net
Well, there sould be a Notice then.
We agree, this behaviour is not (really) object oriented behaviour, do
we? So if it's kept for backward compatibility php5+ should show a
notice.
[2005-01-26 09:05:56] [EMAIL PROTECTED]
THis is wanted behavior, as not to break scripts with PHP 4.
[2005-01-26 03:10:37] attibln at gmx dot net
Description:
Defining an attribute within a method is possible even if it was not
declared in the class.
This is some kind of hidden/ghost attributes ... if they have not been
declared - e.g. public name etc. - it will be quite hard to understand
a class using those "ghost attribute". Especially when the are defined
in method bar() and later on used in method foo().
My system:
gentoo 2.4.26-gentoo-r9
apache 2.0.51-r1
PHP Version 5.0.3 / Zend Engine v2.0.3
(php) use flags:
-adabas +apache2 -bcmath -berkdb -birdstep +bzlib -calendar -cdb
-cpdflib +crypt -ctype +curl +curlwrappers -db2 -dba -dbase -dbm
-dbmaker -dbx -debug -dio -empress -empress-bcs -esoob +exif -fam
-fdftk -filepro -flatfile -frontbase -ftp +gd -gd-external -gdbm -gmp
-hyperwave-api -iconv -imap -informix -ingres -inifile -interbase
-iodbc +jpeg -kerberos -ldap -libedit -mcve +memlimit -mhash +mime
-ming -mnogosearch -msession -msql -mssql +mysql -mysqli +ncurses -nis
+nls -oci8 -odbc -oracle7 -ovrimos +pcntl -pcre -pfpro +png -posix
+postgres -qdbm -readline -recode -sapdb -sasl +session -shared
-sharedmem +simplexml -snmp +soap +sockets -solid -spell +spl -sqlite
+ssl -sybase -sybase-ct -sysvipc +tidy -tiff +tokenizer -truetype -wddx
+xml2 -xmlrpc -xpm +xsl +zlib
Reproduce code:
---
nev = "MyDestructableClass";
}
function show_nev()
{
print( 'nev is ' . $this->nev );
}
}
$obj = new MyDestructableClass();
$obj->show_nev();
?>
Expected result:
There should be an Error messagen ( or at least a warning) saying:
Use of undeclared attribute in ... on line ...
Actual result:
--
regarding my "example":
nev is MyDestructableClass
--
Edit this bug report at http://bugs.php.net/?id=31701&edit=1
#34211 [Asn->Fbk]: ext/oci8: Allow for data type "TIMESTAMP(0) WITH LOCAL TIME ZONE"
ID: 34211 Updated by: [EMAIL PROTECTED] Reported By: kurtb149 at yahoo dot com -Status: Assigned +Status: Feedback Bug Type: Feature/Change Request Operating System: Linux PHP Version: 6CVS-2005-08-22 (CVS) Assigned To: tony2001 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 possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Previous Comments: [2005-08-22 23:28:18] [EMAIL PROTECTED] reclassified [2005-08-22 19:11:40] kurtb149 at yahoo dot com Description: In the file: ext/pdo_oci/oci_statement.c the function oci_stmt_describe() does not allow for the data type "TIMESTAMP(0) WITH LOCAL TIME ZONE". Here is the diff of an updated oci_statement.c that would allow for the data type: $ cvs diff oci_statement.c Index: oci_statement.c === RCS file: /repository/php-src/ext/pdo_oci/oci_statement.c,v retrieving revision 1.16 diff -r1.16 oci_statement.c 407a408,410 > #ifdef SQLT_TIMESTAMP_LTZ > || dtype == SQLT_TIMESTAMP_LTZ > #endif -- Edit this bug report at http://bugs.php.net/?id=34211&edit=1
#36956 [Bgs->Opn]: dirname returns \ for root /
ID: 36956
User updated by: e dot vandeoudeweetering at marcanti dot esprit-sg dot
Reported By: e dot vandeoudeweetering at marcanti dot esprit-sg dot
-Status: Bogus
+Status: Open
Bug Type: Directory function related
Operating System: Windows 2000 (5.00.2195) SP4
PHP Version: 5.1.2
New Comment:
I did check the following documentation:
http://nl3.php.net/manual/en/function.dirname.php
dirname('c:/');
it returns c:\ (notice the backslash)
the documentation says it should return c:
suggest the following 7 examles:
$dir = 'C:\\Temp';
print "$dir\t\t: ".dirname($dir).'\\'.basename($dir)."\n";
$dir = 'C:/Temp';
print "$dir\t\t: ".dirname($dir).'/'.basename($dir)."\n";
$dir = 'C:\\';
print "$dir\t\t: ".dirname($dir).'\\'.basename($dir)."\n";
$dir = 'C:/';
print "$dir\t\t: ".dirname($dir).'/'.basename($dir)."\n";
$dir = 'server\\share';
print "$dir\t: ".dirname($dir).'\\'.basename($dir)."\n";
$dir = '//server/share';
print "$dir\t: ".dirname($dir).'/'.basename($dir)."\n";
$dir = '/usr/local';
print "$dir\t: ".dirname($dir).'/'.basename($dir)."\n";
The following output is generated:
C:\Temp : C:\\Temp
C:/Temp : C:\/Temp
C:\ : C:\\C:
C:/ : C:\/C:
\\server\share : \\server\share
//server/share : //server/share
/usr/local : /usr/local
The following output is expected:
C:\Temp : C:\Temp
C:/Temp : C:/Temp
C:\ : C:\
C:/ : C:/
\\server\share : \\server\share
//server/share : //server/share
/usr/local : /usr/local
As you see something is wrong!
Previous Comments:
[2006-04-04 09:27:14] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is expected, as Window$ uses \ everywhere instead of / on *nix.
[2006-04-03 13:33:19] e dot vandeoudeweetering at marcanti dot
esprit-sg dot
Description:
When using the function dirname, \ is returned for the root directory
/
This is what the documentation says:
//after PHP 4.3.0
dirname('c:/'); // returns 'c:'
Reproduce code:
---
print dirname('/');
print dirname('C:/');
print dirname('C:\\'); //this function works
Expected result:
/
C:
C:\
Actual result:
--
\
C:\
C:\
--
Edit this bug report at http://bugs.php.net/?id=36956&edit=1
#36967 [NEW]: ip2long returns unsigned long instead of signed long
From: php at cakkie dot be
Operating system: Linux Gentoo
PHP version: 4.4.2
PHP Bug Type: Unknown/Other Function
Bug description: ip2long returns unsigned long instead of signed long
Description:
I'm using the same code on 2 servers.
One server is a 2.6.6 debian with PHP 4.3.10
This one returns a signed long (as it should according to the
documentation)
The other server is a 2.6.14 Gentoo with PHP 4.4.0
This one returns an unsigned long (not what it should be)
Since I didn't find any bugreport, nor other information regarding this
behaviour, I decided to post a bug.
As a reference, I have an example, along with phpinfo() running at both
servers:
correct: http://www.funpages.be/index.php
incorrect: http://www.factsoflife.be/cakkie/index.php
Reproduce code:
---
echo ip2long('217.136.232.103');
Expected result:
-645339033
Actual result:
--
3649628263
--
Edit bug report at http://bugs.php.net/?id=36967&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36967&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36967&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36967&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36967&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36967&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36967&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36967&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36967&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36967&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36967&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36967&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36967&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36967&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36967&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36967&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36967&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36967&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36967&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36967&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36967&r=mysqlcfg
#36968 [NEW]: Single space is returned from MSSQL 2000 when actually a emtpy string is stored
From: mathew dot lhf at gmail dot com Operating system: Windows 2003 Server PHP version: 4.4.2 PHP Bug Type: MSSQL related Bug description: Single space is returned from MSSQL 2000 when actually a emtpy string is stored Description: A single space character is returned from MSSQL 2000 running on Windows server 2003 when actually a emtpy string is stored. -- Edit bug report at http://bugs.php.net/?id=36968&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36968&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36968&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36968&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36968&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36968&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36968&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36968&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36968&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36968&r=support Expected behavior:http://bugs.php.net/fix.php?id=36968&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36968&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36968&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36968&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36968&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36968&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36968&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36968&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36968&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36968&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36968&r=mysqlcfg
#36967 [Opn->Bgs]: ip2long returns unsigned long instead of signed long
ID: 36967
Updated by: [EMAIL PROTECTED]
Reported By: php at cakkie dot be
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Linux Gentoo
PHP Version: 4.4.2
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
It's actually correct as your 2nd machine is a 64bit machine, where
PHP's integers are also 64bit. To make this portable, use sprintf("%u",
ip2long());
Previous Comments:
[2006-04-04 15:39:09] php at cakkie dot be
Description:
I'm using the same code on 2 servers.
One server is a 2.6.6 debian with PHP 4.3.10
This one returns a signed long (as it should according to the
documentation)
The other server is a 2.6.14 Gentoo with PHP 4.4.0
This one returns an unsigned long (not what it should be)
Since I didn't find any bugreport, nor other information regarding this
behaviour, I decided to post a bug.
As a reference, I have an example, along with phpinfo() running at both
servers:
correct: http://www.funpages.be/index.php
incorrect: http://www.factsoflife.be/cakkie/index.php
Reproduce code:
---
echo ip2long('217.136.232.103');
Expected result:
-645339033
Actual result:
--
3649628263
--
Edit this bug report at http://bugs.php.net/?id=36967&edit=1
#31002 [Asn->Csd]: IA64 Unable to link php with Mysql 4.1.7
ID: 31002 Updated by: [EMAIL PROTECTED] Reported By: zeke at spamcop dot net -Status: Assigned +Status: Closed Bug Type: MySQL related Operating System: Linux 2.4.21-sgi301r1 PHP Version: 4CVS-2005-01-21 Assigned To: hholzgra New Comment: The original problem no longer exists with MySQL 4.1.18 but there is a different linking problem pending right now at least with the RPM distributions for it as these have been created with the Intel icc compiler. For details see http://bugs.mysql.com/bug.php?id=18776 Previous Comments: [2005-02-01 20:38:26] [EMAIL PROTECTED] The static libmysqlclient.a you have was not compiled using -fPIC so you either need to build MySQL shared libraries, or rebuild the static libraires using "CFLAGS=-fPIC"; either way, this is not a PHP bug. [2005-02-01 19:22:13] [EMAIL PROTECTED] Get the latest snapshot from today and try with this configure line: ./configure --disable-all --with-apxs2 --with-mysql=/usr/local/mysql --with-pic --disable-cli [2005-01-21 13:41:24] zeke at spamcop dot net Hi, I tried the latest build:php4-STABLE-200501211130 Same error during the linking step. I used the same configure options as in my original message. /usr/bin/ld: /usr/local/mysql/lib/libmysqlclient.a(libmysql.o): @gprel relocation against dynamic symbol net_buffer_length /usr/bin/ld: /usr/local/mysql/lib/libmysqlclient.a(libmysql.o): @gprel relocation against dynamic symbol max_allowed_packet /usr/bin/ld: /usr/local/mysql/lib/libmysqlclient.a(libmysql.o): @gprel relocation against dynamic symbol net_write_timeout /usr/bin/ld: /usr/local/mysql/lib/libmysqlclient.a(libmysql.o): @gprel relocation against dynamic symbol net_read_timeout collect2: ld returned 1 exit status make: *** [libphp4.la] Error 1 [2005-01-13 04:29:41] [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 [2004-12-06 22:43:50] zeke at spamcop dot net Edit: Also tried with the --with-pic option on the configure command line .. still same link errors. 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/31002 -- Edit this bug report at http://bugs.php.net/?id=31002&edit=1
#36969 [NEW]: pg_query_params fails for integer column with 'insert into..select distinct'
From: alan dot harder at sun dot com
Operating system: Debian
PHP version: 5.1.3RC2
PHP Bug Type: PostgreSQL related
Bug description: pg_query_params fails for integer column with 'insert
into..select distinct'
Description:
parameter given as integer but treated as text with particular sql syntax.
remove "distinct" from the sql and it works.
Tested with PHP 5.1.2 and PHP 5.1.3-RC2
pg_version output:
array(3) { ["client"]=> string(5) "8.1.2" ["protocol"]=> int(3)
["server"]=> string(6) "7.4.11" }
Reproduce code:
---
First in psql:
create table test (val integer);
Test code:
Expected result:
OK
Actual result:
--
Warning: pg_query_params() [function.pg-query-params]: Query failed:
ERROR: column "val" is of type integer but expression is of type text
HINT: You will need to rewrite or cast the expression. in
/usr/home/mindless/public_html/pgtest.php on line 5
ERROR: column "val" is of type integer but expression is of type text
HINT: You will need to rewrite or cast the expression.
--
Edit bug report at http://bugs.php.net/?id=36969&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36969&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36969&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36969&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36969&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36969&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36969&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36969&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36969&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36969&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36969&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36969&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36969&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36969&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36969&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36969&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36969&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36969&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36969&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36969&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36969&r=mysqlcfg
#36970 [NEW]: php cores
From: bruno dot fernandes at idw dot pt Operating system: SunOS 5.9 Generic_117171-12 PHP version: 4.4.2 PHP Bug Type: iPlanet related Bug description: php cores Description: php cores: core.webservd.28937.WEB-FTP01.60005.60005.1143637072 core.webservd.28937.WEB-FTP01.60005.60005.1143637081 core.webservd.29022.WEB-FTP01.60005.60005.1143643466 core.webservd.29022.WEB-FTP01.60005.60005.1143643476 core.webservd.29043.WEB-FTP01.60005.60005.1143659925 core.webservd.29043.WEB-FTP01.60005.60005.1143659935 core.webservd.29179.WEB-FTP01.60005.60005.1143728625 core.webservd.29179.WEB-FTP01.60005.60005.1143728635 core.webservd.29421.WEB-FTP01.60005.60005.1143750717 core.webservd.29421.WEB-FTP01.60005.60005.1143750725 core.webservd.29568.WEB-FTP01.60005.60005.1143833615 core.webservd.29568.WEB-FTP01.60005.60005.1143833625 core.webservd.961.WEB-FTP01.60005.60005.1143895781 core.webservd.961.WEB-FTP01.60005.60005.1143895791 core.webservd.1262.WEB-FTP01.60005.60005.1143918967 core.webservd.1262.WEB-FTP01.60005.60005.1143918976 core.webservd.1795.WEB-FTP01.60005.60005.1144075233 core.webservd.1795.WEB-FTP01.60005.60005.1144075243 core.webservd.2305.WEB-FTP01.60005.60005.1144141599 core.webservd.2305.WEB-FTP01.60005.60005.1144141608 core.webservd.2489.WEB-FTP01.60005.60005.1144161308 core.webservd.2489.WEB-FTP01.60005.60005.1144161317 core.webservd.2597.WEB-FTP01.60005.60005.1144169180 core.webservd.2597.WEB-FTP01.60005.60005.1144169190 Reproduce code: --- unknown code (more than 3000 clients) Actual result: -- - lwp# 60 / thread# 60 fd851cbc zend_fetch_var_address (152a0f0, e2aa5600, 1, 1f13868, fd860de0, 14c) + 3b0 fd85496c execute (2173e08, 1f13868, e2aafd68, 2175240, fd8a4fc0, 2840) + 400 fd858570 execute (21c2d98, 1f13868, e2ab9f10, 2175240, fd8a4fc0, e2ab9df8) + 4004 fd858570 execute (21c22f8, 1f13868, e2abf0f8, 2175240, fd8a4fc0, e2abef20) + 4004 fd858570 execute (21c20d8, 1f13868, fd825bd8, 2175228, e2abf4bc, e2abf3a8) + 4004 fd843cc8 zend_execute_scripts (0, 1f13868, 0, 3, e2abf52c, e2abfab8) + f0 fd80b480 php_execute_script (e2abfab8, 0, 1, 6eec0, 23af080, 2400) + 2b4 fd863038 php4_execute (41580, ff2e8fd4, 1f13868, 1f, fd89c7c0, 2608) + 858 ff1cf994 __1cNfunc_exec_str6FpnKFuncStruct_pnGpblock_pnHSession_pnHRequest__i_ (668, 41580, 1677568, 16775e0, 0, 0) + 248 ff1d0db4 INTobject_execute (7624a8, 1677568, 16775e0, 0, 38368, 7622d0) + 5e8 ff1d5de4 INTservact_service (1677568, 16775e0, ff2e7b58, 4, 40, ff2e7b30) + 4d8 ff1d64f4 INTservact_handle_processed (1677568, 16775e0, 20, 2, 1773dc0, 7a680) + 158 ff218a9c __1cLHttpRequestUUnacceleratedRespond6Mpc_v_ (16774c8, ff2e7b7c, 2f48, 50, 16775e0, 1677568) + 3c8 ff21818c __1cLHttpRequestNHandleRequest6MpnGnetbuf__i_ (16774c8, 1771498, 1773528, 1773510, 2000, 17714f8) + 62c ff216588 __1cNDaemonSessionDrun6M_v_ (16770c0, 2000, ff2ed7bc, 0, 0, ff2ed774) + 17c ff106dec ThreadMain (16770c0, 880708, 3, 0, 1, 4b8) + 24 fedd0028 _pt_root (880708, 0, 0, 0, 2, fede8d70) + d0 fec55854 _lwp_start (0, 0, 0, 0, 0, 0) - lwp# 61 / thread# 61 fec55998 __lwp_park (40868, fec68b48, 0, 0, fcc13800, fec68000) + 14 fec53358 cond_wait (40868, 75fd18, 0, 184f0, 0, 400) + 14 fec53394 pthread_cond_wait (40868, 75fd18, 400, 65c, 0, 14) + 8 fedc7a00 PR_WaitCondVar (40860, , 0, 880818, 0, c064c) + 18c ff22014c __1cPConnectionQdDueueIGetReady6MI_pnKConnection__ (b5e48, , 792e8, 6, ca8a0, 2c00) + 10c ff215e28 __1cNDaemonSessionNGetConnection6MI_i_ (16778d0, , ff2ed780, ff2e069c, 1, 2800) + 30 ff215fe8 __1cNDaemonSessionNGetConnection6M_i_ (16778d0, 1, 2, ff2e069c, fffe, 1) + 98 ff216500 __1cNDaemonSessionDrun6M_v_ (16778d0, 2000, ff2ed7bc, 0, 0, ff2ed774) + f4 ff106dec ThreadMain (16778d0, 880818, 3, 0, 1, 4b8) + 24 fedd0028 _pt_root (880818, 0, 0, 0, 2, fede8d70) + d0 fec55854 _lwp_start (0, 0, 0, 0, 0, 0) -- Edit bug report at http://bugs.php.net/?id=36970&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36970&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36970&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36970&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36970&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36970&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36970&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36970&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36970&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36970&r=support Expected behavior:http://bugs.php.net/fix.php?id=36970&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36970&r=notenoughinfo Submitted twice: http://bugs.php.ne
#33694 [NoF->Csd]: IIS needs restart when invalid MSSQL statement run
ID: 33694
Updated by: [EMAIL PROTECTED]
Reported By: spam at meyrick dot co dot nz
-Status: No Feedback
+Status: Closed
Bug Type: MSSQL related
Operating System: Windows 2003 Server Enterprise
PHP Version: 4.4.0
Assigned To: fmk
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.
Code has been added to make sure all pending results are cleared from
the server when an error happens
Previous Comments:
[2006-03-28 14:38:28] fjortiz at comunet dot es
I reproduce this bug with the latest 5.1. CVS . It also happens with
very long queries that yield timeouts: the persistent connection stops
working until you restart the web server.
I think it has to do with this:
http://support.microsoft.com/default.aspx?scid=kb;en-us;165951
Which also refers this article:
"DB-Library prevents you from sending additional queries if there are
results from a previous query that need to be handled. For more
information, see the following article in the Microsoft Knowledge
Base:
http://support.microsoft.com/kb/117143/EN-US/
I saw php_mssql.c and you can call "dbcanquery" in mssql_free_result,
but once you have triggered the error, it's impossible to regain
control, because you can't get new results to free the affected
connection (DBPROCESS).
Frank, maybe this could be solved with an explicit call to
dbcanquery(mssql_ptr->link) before returning "FALSE" in mssql_query and
mssql_execute. What do you think?
[2006-01-01 01:00:05] 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-12-24 02:24:19] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2005-10-18 16:56:05] reynardmh at nospam dot lightsky dot com
I experience the same problem with php 5.0.5, win2k, not sure what
version of sql server. As a temporary fix, you can change your code to
use mssql_connect instead of pconnect, that seems to solve the problem
for me.
[2005-07-14 11:03:03] spam at meyrick dot co dot nz
Description:
I am using IIS6 (Win2k3 Server, SQL Server 2000, PHP 4.3.4 DLL)
I am connecting to MSSQL using username/pwd and pconnect
no probs there.
My problem is that if I execute a horribly incorrect SQL statement one
of the perminant connections to MSSQL is disabled giving 'unable to
connec to database' (pconnect() == false) errors 50% of the time..
For example:
Table: [Stock Items]:
StockItemID int no nulls identity
SupplierID int no nulls <--**
test varchar(50) allow null
...
$sql = "INSERT INTO [Stock Items] (test) VALUES ('this should fail')";
$result = mssql_query($sql);
Warning: mssql_query(): message: Cannot insert the value NULL into
column 'SupplierID', table 'Database Name.dbo.Stock Items'; column does
not allow nulls. INSERT fails. (severity 16) in
C:\Inetpub\websites\sitename\public_html\acweb\includes\functions\database.php
on line 49
Warning: mssql_query(): message: The statement has been terminated.
(severity 0) in
C:\Inetpub\websites\sitename\public_html\acweb\includes\functions\database.php
on line 49
Warning: mssql_query(): General SQL Server error: Check messages from
the SQL Server. (severity 5) in
C:\Inetpub\websites\sitename\public_html\acweb\includes\functions\database.php
on line 49
Warning: mssql_query(): Query failed in
C:\Inetpub\websites\sitename\public_html\acweb\includes\functions\database.php
on line 49
Warning: mssql_query(): Attempt to initiate a new SQL Server operation
with results pending. (severity 7) in
C:\Inetpub\websites\sitename\public_html\acweb\includes\functions\database.php
on line 186
The last error is the one that is the kick in the guts as now EVERY sql
statement until the page finishes loading will fail.
When the page is refreshed pconnect() will work 50% of the time (if
they get a valid connection it works, if they get the dead connection
it fails).
The only way I can fix this problem is restarting IIS which is a pain.
I can replicate the problem by killing the process from MSSQL
Enterprise manager.
Any help would be great.
ps. an answer of "just fix your sql statement" is not what I'm looking
#31701 [WFx]: (mis-) use of undeclared attributes
ID: 31701 Updated by: [EMAIL PROTECTED] Reported By: attibln at gmx dot net Status: Wont fix Bug Type: Feature/Change Request -Operating System: linux +Operating System: * -PHP Version: 5.0.3 +PHP Version: * New Comment: Won't change anytime - this is by design. Previous Comments: [2006-04-04 09:51:52] [EMAIL PROTECTED] This won't change in the nearest future. [2005-01-29 18:01:43] attibln at gmx dot net thx :) [2005-01-28 23:19:46] [EMAIL PROTECTED] Reclassified as feature request as there is no bug here. [2005-01-26 19:50:17] attibln at gmx dot net Well, there sould be a Notice then. We agree, this behaviour is not (really) object oriented behaviour, do we? So if it's kept for backward compatibility php5+ should show a notice. [2005-01-26 09:05:56] [EMAIL PROTECTED] THis is wanted behavior, as not to break scripts with PHP 4. 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/31701 -- Edit this bug report at http://bugs.php.net/?id=31701&edit=1
#36968 [Opn->Fbk]: Single space is returned from MSSQL 2000 when actually a emtpy string is stored
ID: 36968 Updated by: [EMAIL PROTECTED] Reported By: mathew dot lhf at gmail dot com -Status: Open +Status: Feedback Bug Type: MSSQL related Operating System: Windows 2003 Server PHP Version: 4.4.2 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 possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Previous Comments: [2006-04-04 15:54:22] mathew dot lhf at gmail dot com Description: A single space character is returned from MSSQL 2000 running on Windows server 2003 when actually a emtpy string is stored. -- Edit this bug report at http://bugs.php.net/?id=36968&edit=1
#36970 [Opn->Fbk]: php cores
ID: 36970 Updated by: [EMAIL PROTECTED] Reported By: bruno dot fernandes at idw dot pt -Status: Open +Status: Feedback Bug Type: iPlanet related Operating System: SunOS 5.9 Generic_117171-12 PHP Version: 4.4.2 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 possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Previous Comments: [2006-04-04 17:37:47] bruno dot fernandes at idw dot pt Description: php cores: core.webservd.28937.WEB-FTP01.60005.60005.1143637072 core.webservd.28937.WEB-FTP01.60005.60005.1143637081 core.webservd.29022.WEB-FTP01.60005.60005.1143643466 core.webservd.29022.WEB-FTP01.60005.60005.1143643476 core.webservd.29043.WEB-FTP01.60005.60005.1143659925 core.webservd.29043.WEB-FTP01.60005.60005.1143659935 core.webservd.29179.WEB-FTP01.60005.60005.1143728625 core.webservd.29179.WEB-FTP01.60005.60005.1143728635 core.webservd.29421.WEB-FTP01.60005.60005.1143750717 core.webservd.29421.WEB-FTP01.60005.60005.1143750725 core.webservd.29568.WEB-FTP01.60005.60005.1143833615 core.webservd.29568.WEB-FTP01.60005.60005.1143833625 core.webservd.961.WEB-FTP01.60005.60005.1143895781 core.webservd.961.WEB-FTP01.60005.60005.1143895791 core.webservd.1262.WEB-FTP01.60005.60005.1143918967 core.webservd.1262.WEB-FTP01.60005.60005.1143918976 core.webservd.1795.WEB-FTP01.60005.60005.1144075233 core.webservd.1795.WEB-FTP01.60005.60005.1144075243 core.webservd.2305.WEB-FTP01.60005.60005.1144141599 core.webservd.2305.WEB-FTP01.60005.60005.1144141608 core.webservd.2489.WEB-FTP01.60005.60005.1144161308 core.webservd.2489.WEB-FTP01.60005.60005.1144161317 core.webservd.2597.WEB-FTP01.60005.60005.1144169180 core.webservd.2597.WEB-FTP01.60005.60005.1144169190 Reproduce code: --- unknown code (more than 3000 clients) Actual result: -- - lwp# 60 / thread# 60 fd851cbc zend_fetch_var_address (152a0f0, e2aa5600, 1, 1f13868, fd860de0, 14c) + 3b0 fd85496c execute (2173e08, 1f13868, e2aafd68, 2175240, fd8a4fc0, 2840) + 400 fd858570 execute (21c2d98, 1f13868, e2ab9f10, 2175240, fd8a4fc0, e2ab9df8) + 4004 fd858570 execute (21c22f8, 1f13868, e2abf0f8, 2175240, fd8a4fc0, e2abef20) + 4004 fd858570 execute (21c20d8, 1f13868, fd825bd8, 2175228, e2abf4bc, e2abf3a8) + 4004 fd843cc8 zend_execute_scripts (0, 1f13868, 0, 3, e2abf52c, e2abfab8) + f0 fd80b480 php_execute_script (e2abfab8, 0, 1, 6eec0, 23af080, 2400) + 2b4 fd863038 php4_execute (41580, ff2e8fd4, 1f13868, 1f, fd89c7c0, 2608) + 858 ff1cf994 __1cNfunc_exec_str6FpnKFuncStruct_pnGpblock_pnHSession_pnHRequest__i_ (668, 41580, 1677568, 16775e0, 0, 0) + 248 ff1d0db4 INTobject_execute (7624a8, 1677568, 16775e0, 0, 38368, 7622d0) + 5e8 ff1d5de4 INTservact_service (1677568, 16775e0, ff2e7b58, 4, 40, ff2e7b30) + 4d8 ff1d64f4 INTservact_handle_processed (1677568, 16775e0, 20, 2, 1773dc0, 7a680) + 158 ff218a9c __1cLHttpRequestUUnacceleratedRespond6Mpc_v_ (16774c8, ff2e7b7c, 2f48, 50, 16775e0, 1677568) + 3c8 ff21818c __1cLHttpRequestNHandleRequest6MpnGnetbuf__i_ (16774c8, 1771498, 1773528, 1773510, 2000, 17714f8) + 62c ff216588 __1cNDaemonSessionDrun6M_v_ (16770c0, 2000, ff2ed7bc, 0, 0, ff2ed774) + 17c ff106dec ThreadMain (16770c0, 880708, 3, 0, 1, 4b8) + 24 fedd0028 _pt_root (880708, 0, 0, 0, 2, fede8d70) + d0 fec55854 _lwp_start (0, 0, 0, 0, 0, 0) - lwp# 61 / thread# 61 fec55998 __lwp_park (40868, fec68b48, 0, 0, fcc13800, fec68000) + 14 fec53358 cond_wait (40868, 75fd18, 0, 184f0, 0, 400) + 14 fec53394 pthread_cond_wait (40868, 75fd18, 400, 65c, 0, 14) + 8 fedc7a00 PR_WaitCondVar (40860, , 0, 880818, 0, c064c) + 18c ff22014c __1cPConnectionQdDueueIGetReady6MI_pnKConnection__ (b5e48, , 792e8, 6, ca8a0, 2c00) + 10c ff215e28 __1cNDaemonSessionNGetConnection6MI_i_ (16778d0, , ff2ed780, ff2e069c, 1, 2800) + 30 ff215fe8 __1cNDaemonSessionNGetConnection6M_i_ (16778d0, 1, 2, ff2e069c, fffe, 1) + 98 ff216500 __1cNDaemonSessionDrun6M_v_ (16778d0, 2000, ff2ed7bc, 0, 0, ff2ed774) + f4 ff106dec ThreadMain (16778d0, 880818, 3, 0, 1, 4b8) + 24 fedd0028 _pt_root (880818, 0, 0, 0, 2, fede8d70) + d0 fec55854 _lwp_start (0, 0, 0, 0, 0, 0) -- Edit this bug report at http://bugs.php.net/?id=36970&edit=1
#36968 [Fbk->Bgs]: Single space is returned from MSSQL 2000 when actually a emtpy string is stored
ID: 36968 Updated by: [EMAIL PROTECTED] Reported By: mathew dot lhf at gmail dot com -Status: Feedback +Status: Bogus Bug Type: MSSQL related Operating System: Windows 2003 Server PHP Version: 4.4.2 New Comment: This is a bug in the DB library used in the extension. The only workarround is to trim the value and that would be wrong if the data storred actually was a space. Previous Comments: [2006-04-04 18:51:22] [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 to avoid embedding huge scripts into the report. [2006-04-04 15:54:22] mathew dot lhf at gmail dot com Description: A single space character is returned from MSSQL 2000 running on Windows server 2003 when actually a emtpy string is stored. -- Edit this bug report at http://bugs.php.net/?id=36968&edit=1
#36971 [NEW]: unset() no longer works on $this in PHP5
From: k at phpkoala dot com
Operating system: Linux
PHP version: 5.1.2
PHP Bug Type: Class/Object related
Bug description: unset() no longer works on $this in PHP5
Description:
In PHP4, calling unset($this) within a class worked fine, and destroyed
that class instance. This was a very useful way technique, one that I and
others have used many times.
In PHP5, it simply no longer works. There is no error message - not even a
strict - the instance is just unaffected.
PHP4 also offers another method - setting $this = NULL, but PHP5 gives an
error that $this cannot be reassigned.
I would like to see this functionality restored, or, an alternate
mechanism for destroying class instances internally should be pointed out
(and put into the manual), or, if for some unknown reason this useful
functionality is now declared by the PHP staff to be evil, the reasons
should be revealed and the appropriate details put into the manual so that
we know it know longer works in PHP5, and why.
I figure it's just a bug ;)
Reproduce code:
---
class test {
function f1() {
unset($this);
}
function f2() {
$this = NULL;
}
}
$obj = new test;
var_dump($obj);
$obj->f1();
var_dump($obj);
$obj->f2();
var_dump($obj);
unset($obj);
var_dump($obj);
Expected result:
object(test)(0) {
}
NULL
NULL
NULL
Note: if f1() worked, there would be no need to run f2(), because $obj
would have been unset. But, both methods should result in $obj being
NULL.
OR:
object(test)(0) {
}
object(test)(0) {
}
NULL
NULL
This would also be an acceptable result, because there is an alternate
method (f2()) that can be used. This is the result from the latest version
of PHP4.
Actual result:
--
>From PHP5:
Fatal error: Cannot re-assign $this in /home/test2.php on line 6
So, f2(), which sets $this to NULL, doesn't work. Commenting that out
produces:
object(test)#1 (0) {
}
object(test)#1 (0) {
}
NULL
So, neither of the methods f1() or f2() work.
>From the latest version of PHP4:
object(test)(0) {
}
object(test)(0) {
}
NULL
NULL
This is fine, as the desired effect can still be accomplished.
In earlier versions of PHP4, both f1() and f2() work fine.
--
Edit bug report at http://bugs.php.net/?id=36971&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36971&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36971&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36971&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36971&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36971&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36971&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36971&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36971&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36971&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36971&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36971&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36971&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36971&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36971&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36971&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36971&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36971&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36971&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36971&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36971&r=mysqlcfg
#36971 [Opn->Bgs]: unset() no longer works on $this in PHP5
ID: 36971
Updated by: [EMAIL PROTECTED]
Reported By: k at phpkoala dot com
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: Linux
PHP Version: 5.1.2
New Comment:
I can't believe you're serious.
Previous Comments:
[2006-04-04 19:25:26] k at phpkoala dot com
Description:
In PHP4, calling unset($this) within a class worked fine, and destroyed
that class instance. This was a very useful way technique, one that I
and others have used many times.
In PHP5, it simply no longer works. There is no error message - not
even a strict - the instance is just unaffected.
PHP4 also offers another method - setting $this = NULL, but PHP5 gives
an error that $this cannot be reassigned.
I would like to see this functionality restored, or, an alternate
mechanism for destroying class instances internally should be pointed
out (and put into the manual), or, if for some unknown reason this
useful functionality is now declared by the PHP staff to be evil, the
reasons should be revealed and the appropriate details put into the
manual so that we know it know longer works in PHP5, and why.
I figure it's just a bug ;)
Reproduce code:
---
class test {
function f1() {
unset($this);
}
function f2() {
$this = NULL;
}
}
$obj = new test;
var_dump($obj);
$obj->f1();
var_dump($obj);
$obj->f2();
var_dump($obj);
unset($obj);
var_dump($obj);
Expected result:
object(test)(0) {
}
NULL
NULL
NULL
Note: if f1() worked, there would be no need to run f2(), because $obj
would have been unset. But, both methods should result in $obj being
NULL.
OR:
object(test)(0) {
}
object(test)(0) {
}
NULL
NULL
This would also be an acceptable result, because there is an alternate
method (f2()) that can be used. This is the result from the latest
version of PHP4.
Actual result:
--
>From PHP5:
Fatal error: Cannot re-assign $this in /home/test2.php on line 6
So, f2(), which sets $this to NULL, doesn't work. Commenting that out
produces:
object(test)#1 (0) {
}
object(test)#1 (0) {
}
NULL
So, neither of the methods f1() or f2() work.
>From the latest version of PHP4:
object(test)(0) {
}
object(test)(0) {
}
NULL
NULL
This is fine, as the desired effect can still be accomplished.
In earlier versions of PHP4, both f1() and f2() work fine.
--
Edit this bug report at http://bugs.php.net/?id=36971&edit=1
#36941 [Asn->Csd]: ArrayIterator does not clone itself
ID: 36941 Updated by: [EMAIL PROTECTED] Reported By: ce at netage dot bg -Status: Assigned +Status: Closed Bug Type: SPL related Operating System: * PHP Version: 5.1.3RC2 Assigned To: helly 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: [2006-04-02 17:11:28] [EMAIL PROTECTED] Fixed most of the issue in head but not like you expected to. If you clone an ArrayIterator you also clone its reference thus the described behavior below is correct. If you clone an ArrayObject you clone the array, too. However the behavior is not completely correct yet. [2006-04-01 21:17:04] [EMAIL PROTECTED] Marcus, could you plz look at it? [2006-04-01 16:29:25] ce at netage dot bg Description: ArrayIterator does not clone itself Reproduce code: --- $a = new ArrayIterator(); $a[] = 1; $b = clone $a; var_dump($a[0], $b[0]); $b[0] = $b[0] + 1; var_dump($a[0], $b[0]); Expected result: int(1) int(1) int(1) int(2) Actual result: -- int(1) int(1) int(2) int(2) -- Edit this bug report at http://bugs.php.net/?id=36941&edit=1
#36973 [NEW]: Can't connect from outside
From: xota2004 at gmail dot com Operating system: windows xp sp2 PHP version: 5.1.2 PHP Bug Type: Network related Bug description: Can't connect from outside Description: hi i'm a lil noob so there it goes: i use wamp server 5 and when i try to acess to phpmyadmin from other place besides my home it just give me an error Expected result: i wanna just acess to phpmyadmin outside my home Actual result: -- Error Mysql said: #2003 the server is not responding -- Edit bug report at http://bugs.php.net/?id=36973&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36973&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36973&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36973&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36973&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36973&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36973&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36973&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36973&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36973&r=support Expected behavior:http://bugs.php.net/fix.php?id=36973&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36973&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36973&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36973&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36973&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36973&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36973&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36973&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36973&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36973&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36973&r=mysqlcfg
#36973 [Opn->Bgs]: Can't connect from outside
ID: 36973 Updated by: [EMAIL PROTECTED] Reported By: xota2004 at gmail dot com -Status: Open +Status: Bogus Bug Type: Network related Operating System: windows xp sp2 PHP Version: 5.1.2 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: [2006-04-04 20:07:51] xota2004 at gmail dot com Description: hi i'm a lil noob so there it goes: i use wamp server 5 and when i try to acess to phpmyadmin from other place besides my home it just give me an error Expected result: i wanna just acess to phpmyadmin outside my home Actual result: -- Error Mysql said: #2003 the server is not responding -- Edit this bug report at http://bugs.php.net/?id=36973&edit=1
#36974 [NEW]: ORA-01405: fetched column value is NULL on LOB fields in 10g
From: crescentfreshpot at yahoo dot com
Operating system: Win 2000, Win XP
PHP version: 5.1.2
PHP Bug Type: PDO related
Bug description: ORA-01405: fetched column value is NULL on LOB fields in 10g
Description:
pdo_oci does not convert oracle nulls to php nulls when fetching from lob
fields. Appears in 5.0.5 to 5.1.2 versions of php/pdo/pdo_oci. Oracle
version is 10g. Non-lob fields appear to convert just fine.
Setting the PDO::ATTR_ORACLE_NULLS driver attribute to PDO::NULL_TO_STRING
and/or PDO::NULL_EMPTY_STRING has no effect.
I'm aware that this behaviour is 'by design' for oracle but was led to
believe by the docs that pdo handled nulls for me so I don't have to
resort to using NVL(...) in my queries.
Reproduce code:
---
setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);
var_dump($dbh->query("SELECT * FROM
SCOTT.EMP")->fetch(PDO::FETCH_ASSOC));
if($dbh->exec("ALTER TABLE SCOTT.EMP ADD (PIC BLOB)") === false) {
die("ALTER TABLE failed.");
}
var_dump($dbh->query("SELECT * FROM
SCOTT.EMP")->fetch(PDO::FETCH_ASSOC));
$dbh->exec("ALTER TABLE SCOTT.EMP DROP (PIC)");
?>
Expected result:
array(8) {
["EMPNO"]=>
string(4) "7369"
["ENAME"]=>
string(5) "SMITH"
["JOB"]=>
string(5) "CLERK"
["MGR"]=>
string(4) "7902"
["HIREDATE"]=>
string(9) "17-DEC-80"
["SAL"]=>
string(3) "800"
["COMM"]=>
NULL
["DEPTNO"]=>
string(2) "20"
}
array(8) {
["EMPNO"]=>
string(4) "7369"
["ENAME"]=>
string(5) "SMITH"
["JOB"]=>
string(5) "CLERK"
["MGR"]=>
string(4) "7902"
["HIREDATE"]=>
string(9) "17-DEC-80"
["SAL"]=>
string(3) "800"
["COMM"]=>
NULL
["DEPTNO"]=>
string(2) "20"
["PIC"]=>
NULL
}
Actual result:
--
array(8) {
["EMPNO"]=>
string(4) "7369"
["ENAME"]=>
string(5) "SMITH"
["JOB"]=>
string(5) "CLERK"
["MGR"]=>
string(4) "7902"
["HIREDATE"]=>
string(9) "17-DEC-80"
["SAL"]=>
string(3) "800"
["COMM"]=>
NULL
["DEPTNO"]=>
string(2) "20"
}
Warning: PDOStatement::fetch() [function.fetch]: SQLSTATE[HY000]: General error:
1405 OCIStmtFetch: ORA-01405: fetched column value is NULL
(..\pecl_5_0\pdo_oci\oci_statement.c:446) in C:\dev\tests\db.php
on line 13
bool(false)
--
Edit bug report at http://bugs.php.net/?id=36974&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36974&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36974&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36974&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36974&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36974&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36974&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36974&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36974&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36974&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36974&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36974&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36974&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36974&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36974&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36974&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36974&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36974&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36974&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36974&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36974&r=mysqlcfg
#36975 [NEW]: natcasesort
From: ateixeira at gmail dot com
Operating system: Linux 2.6.11
PHP version: 5.1.2
PHP Bug Type: Arrays related
Bug description: natcasesort
Description:
After using natcasesort, using the array_pop and array_push (or arr[] =
$value construct) in conjunction cause the following error (on
array_push):
Warning: Cannot add element to the array as the next element is already
occupied in x.php on Line xx
Also, the value doesn't get pushed onto the array.
Reproduce code:
---
$fileList = array('aa', 'aa', 'bb', 'bb', 'cc', 'cc');
$test = natcasesort($fileList);
if ($test) {
echo "natcasesort success!\n";
}
$val = array_pop($fileList);
$fileList[] = $val;
print_r($fileList);
Expected result:
natcasesort success!
Array
(
[0] => aa
[1] => aa
[2] => bb
[3] => bb
[4] => cc
[5] => cc
)
Actual result:
--
natcasesort success!
PHP Warning: Cannot add element to the array as the next element is
already occupied in /webroot/root/projects/RPMfe/j.php on line 10
Warning: Cannot add element to the array as the next element is already
occupied in /webroot/root/projects/RPMfe/j.php on line 10
Array
(
[0] => aa
[1] => aa
[3] => bb
[2] => bb
[5] => cc
)
--
Edit bug report at http://bugs.php.net/?id=36975&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36975&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36975&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36975&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36975&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36975&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36975&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36975&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36975&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36975&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36975&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36975&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36975&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36975&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36975&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36975&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36975&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36975&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36975&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36975&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36975&r=mysqlcfg
#36978 [NEW]: PHP Crashes and issues a windows message box
From: thomas dot ene at gmail dot com Operating system: Windows PHP version: 5.1.2 PHP Bug Type: Reproducible crash Bug description: PHP Crashes and issues a windows message box Description: The code below produces: Fatal error: Couldn't execute method demo::__set in Unknown on line 0 and also a windows message box. Reproduce code: --- a++; } } $obj = new demo(); $obj->play(); ?> Expected result: It should set the property a to 1 in the demo class Actual result: -- The code below produces: Fatal error: Couldn't execute method demo::__set in Unknown on line 0 and also a windows message box. -- Edit bug report at http://bugs.php.net/?id=36978&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36978&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36978&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36978&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36978&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36978&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36978&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36978&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36978&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36978&r=support Expected behavior:http://bugs.php.net/fix.php?id=36978&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36978&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36978&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36978&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36978&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36978&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36978&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36978&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36978&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36978&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36978&r=mysqlcfg
#36971 [Bgs->Opn]: unset() no longer works on $this in PHP5
ID: 36971
User updated by: k at phpkoala dot com
Reported By: k at phpkoala dot com
-Status: Bogus
+Status: Open
Bug Type: Class/Object related
Operating System: Linux
PHP Version: 5.1.2
New Comment:
Mike, I am serious or I would not have taken the time to post this bug
report.
The manual page for unset, over at
http://www.php.net/manual/en/function.unset.php, does not mention this
change in functionality. Like I said in my first message, this is
something that works in PHP4 but no longer works in PHP5.
If you can't believe I am serious, please point out why you think this
is a joke? How do you destroy a class instance internally in PHP5? And
if this is never going to happen, can't you say this in the manual,
along with an explanation?
If nothing else, the very fact that it worked in PHP4 and does not work
in PHP5 should merit a mention in the documentation. (Just Google for
this issue and you will see many pieces of software that have broken
because of this, when used on PHP5.)
Back to you, Mike.
Previous Comments:
[2006-04-04 19:33:07] [EMAIL PROTECTED]
I can't believe you're serious.
[2006-04-04 19:25:26] k at phpkoala dot com
Description:
In PHP4, calling unset($this) within a class worked fine, and destroyed
that class instance. This was a very useful way technique, one that I
and others have used many times.
In PHP5, it simply no longer works. There is no error message - not
even a strict - the instance is just unaffected.
PHP4 also offers another method - setting $this = NULL, but PHP5 gives
an error that $this cannot be reassigned.
I would like to see this functionality restored, or, an alternate
mechanism for destroying class instances internally should be pointed
out (and put into the manual), or, if for some unknown reason this
useful functionality is now declared by the PHP staff to be evil, the
reasons should be revealed and the appropriate details put into the
manual so that we know it know longer works in PHP5, and why.
I figure it's just a bug ;)
Reproduce code:
---
class test {
function f1() {
unset($this);
}
function f2() {
$this = NULL;
}
}
$obj = new test;
var_dump($obj);
$obj->f1();
var_dump($obj);
$obj->f2();
var_dump($obj);
unset($obj);
var_dump($obj);
Expected result:
object(test)(0) {
}
NULL
NULL
NULL
Note: if f1() worked, there would be no need to run f2(), because $obj
would have been unset. But, both methods should result in $obj being
NULL.
OR:
object(test)(0) {
}
object(test)(0) {
}
NULL
NULL
This would also be an acceptable result, because there is an alternate
method (f2()) that can be used. This is the result from the latest
version of PHP4.
Actual result:
--
>From PHP5:
Fatal error: Cannot re-assign $this in /home/test2.php on line 6
So, f2(), which sets $this to NULL, doesn't work. Commenting that out
produces:
object(test)#1 (0) {
}
object(test)#1 (0) {
}
NULL
So, neither of the methods f1() or f2() work.
>From the latest version of PHP4:
object(test)(0) {
}
object(test)(0) {
}
NULL
NULL
This is fine, as the desired effect can still be accomplished.
In earlier versions of PHP4, both f1() and f2() work fine.
--
Edit this bug report at http://bugs.php.net/?id=36971&edit=1
#36971 [Com]: unset() no longer works on $this in PHP5
ID: 36971
Comment by: scottmacvicar at ntlworld dot com
Reported By: k at phpkoala dot com
Status: Open
Bug Type: Class/Object related
Operating System: Linux
PHP Version: 5.1.2
New Comment:
Destroying an object internally is an absurd concept, how can you
destroy something that is currently in the scope of execution?
The reason it works in PHP 4 and not in PHP 5 is that object types are
no longer mutable.
Previous Comments:
[2006-04-04 23:18:38] k at phpkoala dot com
Mike, I am serious or I would not have taken the time to post this bug
report.
The manual page for unset, over at
http://www.php.net/manual/en/function.unset.php, does not mention this
change in functionality. Like I said in my first message, this is
something that works in PHP4 but no longer works in PHP5.
If you can't believe I am serious, please point out why you think this
is a joke? How do you destroy a class instance internally in PHP5? And
if this is never going to happen, can't you say this in the manual,
along with an explanation?
If nothing else, the very fact that it worked in PHP4 and does not work
in PHP5 should merit a mention in the documentation. (Just Google for
this issue and you will see many pieces of software that have broken
because of this, when used on PHP5.)
Back to you, Mike.
[2006-04-04 19:33:07] [EMAIL PROTECTED]
I can't believe you're serious.
[2006-04-04 19:25:26] k at phpkoala dot com
Description:
In PHP4, calling unset($this) within a class worked fine, and destroyed
that class instance. This was a very useful way technique, one that I
and others have used many times.
In PHP5, it simply no longer works. There is no error message - not
even a strict - the instance is just unaffected.
PHP4 also offers another method - setting $this = NULL, but PHP5 gives
an error that $this cannot be reassigned.
I would like to see this functionality restored, or, an alternate
mechanism for destroying class instances internally should be pointed
out (and put into the manual), or, if for some unknown reason this
useful functionality is now declared by the PHP staff to be evil, the
reasons should be revealed and the appropriate details put into the
manual so that we know it know longer works in PHP5, and why.
I figure it's just a bug ;)
Reproduce code:
---
class test {
function f1() {
unset($this);
}
function f2() {
$this = NULL;
}
}
$obj = new test;
var_dump($obj);
$obj->f1();
var_dump($obj);
$obj->f2();
var_dump($obj);
unset($obj);
var_dump($obj);
Expected result:
object(test)(0) {
}
NULL
NULL
NULL
Note: if f1() worked, there would be no need to run f2(), because $obj
would have been unset. But, both methods should result in $obj being
NULL.
OR:
object(test)(0) {
}
object(test)(0) {
}
NULL
NULL
This would also be an acceptable result, because there is an alternate
method (f2()) that can be used. This is the result from the latest
version of PHP4.
Actual result:
--
>From PHP5:
Fatal error: Cannot re-assign $this in /home/test2.php on line 6
So, f2(), which sets $this to NULL, doesn't work. Commenting that out
produces:
object(test)#1 (0) {
}
object(test)#1 (0) {
}
NULL
So, neither of the methods f1() or f2() work.
>From the latest version of PHP4:
object(test)(0) {
}
object(test)(0) {
}
NULL
NULL
This is fine, as the desired effect can still be accomplished.
In earlier versions of PHP4, both f1() and f2() work fine.
--
Edit this bug report at http://bugs.php.net/?id=36971&edit=1
#36957 [Opn->Csd]: serialize() doesn't ends
ID: 36957
Updated by: [EMAIL PROTECTED]
Reported By: andyjunkie at tiscali dot it
-Status: Open
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: *nix, Windows XP sp2
PHP Version: 5.1.2
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:
[2006-04-03 13:35:24] andyjunkie at tiscali dot it
Description:
Starts eating memory and never ends.
Expected result:
Serialized $GLOBALS array, with some {RECURSION} reference
--
Edit this bug report at http://bugs.php.net/?id=36957&edit=1
#36473 [Com]: Foreign Images w/getimagesize() crash Apache2
ID: 36473
Comment by: nospam at fidk dot com
Reported By: punkpuke at terraimpetus dot com
Status: No Feedback
Bug Type: Apache2 related
Operating System: Windows XP Pro
PHP Version: 4.4.2
New Comment:
Get the same problem (PHP crashes) with fopen as well as file and
file_get_contents. Under 4.2.2. Try this code:
http://".$host.$location;
$fd = fopen($pirepUrl, "rb");
echo("Done");
?>
Previous Comments:
[2006-03-16 15:07:48] jaroslav dot povolny at gmail dot com
I have just installed back 4.4.1 version and the bug disappeared. It is
definetelly 4.4.2 bug, it is somewhere in file() or file_get_contents().
Platform: Windows XP
[2006-03-16 15:03:45] jaroslav dot povolny at gmail dot com
I am getting the same error without Apache environment when using
function file_get_contents() and file() with http protocol... I think
it is connected
[2006-03-01 01:00:03] 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".
[2006-02-27 21:33:42] stitched at mindspring dot com
I can confirm that this problem is fixed with 5.1.2. I didn't see a
backtrace version for 4.4.2 so was unable to get one. But something is
certainly broken in 4.4.2.
Dave
[2006-02-27 17:16:40] stitched at mindspring dot com
This also happens with Apache 1.3.33 and 2.0.54 consistently with 4.4.2
on Windows 2000. Will try to get a backtrack but given where and when
it's crashing it may not work.
Dave
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/36473
--
Edit this bug report at http://bugs.php.net/?id=36473&edit=1
#36979 [NEW]: Cant set COM properties
From: sharonlp at hotmail dot com
Operating system: Windows XP
PHP version: 5.1.2
PHP Bug Type: COM related
Bug description: Cant set COM properties
Description:
I am using PHP 5.1.2 on Apache 2.0. In my PHP code I am trying to set a
COM OLE poprerty:
$simcase->ObjectValue($inobj1, $inpropname1,"",$inunits1)=$inval1;
($simcase is a COM object)
Using:
echo $simcase->ObjectValue($inobj1, $inpropname1,"",$inunits1);
works fine.
Expected result:
I expected the method to execute and set the property without any problem.
According to the type library what I have written is perfectly legal and
works with VBScript etc.
HRESULT ObjectValue([in] IDispatch* object, [in] BSTR variable,
[in,optional] BSTR subVariable, [in,optional] BSTR units, [out, retval]
double* value);
[helpstring("Sets"),propput,helpcontext(NO_HELP_PANEL)]
HRESULT ObjectValue([in] IDispatch* object, [in] BSTR variable,
[in,optional] BSTR subVariable, [in,optional] BSTR units, [in] double
value);
[helpstring("Gets"),propget,helpcontext(NO_HELP_PANEL)]
Actual result:
--
Fatal error: Can't use method return value in write context...
With com_set being gone, I cant find any work around. I also found a
comment somewhere saying "we cant support ()= so we have "[]=".
But what do you do if your property also takes arguments?
--
Edit bug report at http://bugs.php.net/?id=36979&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36979&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36979&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36979&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36979&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36979&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36979&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36979&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36979&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36979&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36979&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36979&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36979&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36979&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36979&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36979&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36979&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36979&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36979&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36979&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36979&r=mysqlcfg
#36978 [Opn->Bgs]: PHP Crashes and issues a windows message box
ID: 36978 Updated by: [EMAIL PROTECTED] Reported By: thomas dot ene at gmail dot com -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Windows PHP Version: 5.1.2 New Comment: A "Fatal Error" ain't a crash. You can't use in/decrement operators on overloaded properties. Previous Comments: [2006-04-04 23:06:09] thomas dot ene at gmail dot com Description: The code below produces: Fatal error: Couldn't execute method demo::__set in Unknown on line 0 and also a windows message box. Reproduce code: --- a++; } } $obj = new demo(); $obj->play(); ?> Expected result: It should set the property a to 1 in the demo class Actual result: -- The code below produces: Fatal error: Couldn't execute method demo::__set in Unknown on line 0 and also a windows message box. -- Edit this bug report at http://bugs.php.net/?id=36978&edit=1
#36979 [Opn->Bgs]: Cant set COM properties
ID: 36979
Updated by: [EMAIL PROTECTED]
Reported By: sharonlp at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: COM related
Operating System: Windows XP
PHP Version: 5.1.2
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:
[2006-04-05 03:32:31] sharonlp at hotmail dot com
Description:
I am using PHP 5.1.2 on Apache 2.0. In my PHP code I am trying to set a
COM OLE poprerty:
$simcase->ObjectValue($inobj1, $inpropname1,"",$inunits1)=$inval1;
($simcase is a COM object)
Using:
echo $simcase->ObjectValue($inobj1, $inpropname1,"",$inunits1);
works fine.
Expected result:
I expected the method to execute and set the property without any
problem. According to the type library what I have written is perfectly
legal and works with VBScript etc.
HRESULT ObjectValue([in] IDispatch* object, [in] BSTR variable,
[in,optional] BSTR subVariable, [in,optional] BSTR units, [out, retval]
double* value);
[helpstring("Sets"),propput,helpcontext(NO_HELP_PANEL)]
HRESULT ObjectValue([in] IDispatch* object, [in] BSTR variable,
[in,optional] BSTR subVariable, [in,optional] BSTR units, [in] double
value);
[helpstring("Gets"),propget,helpcontext(NO_HELP_PANEL)]
Actual result:
--
Fatal error: Can't use method return value in write context...
With com_set being gone, I cant find any work around. I also found a
comment somewhere saying "we cant support ()= so we have "[]=".
But what do you do if your property also takes arguments?
--
Edit this bug report at http://bugs.php.net/?id=36979&edit=1
#36473 [NoF->Csd]: Foreign Images w/getimagesize() crash Apache2
ID: 36473
Updated by: [EMAIL PROTECTED]
Reported By: punkpuke at terraimpetus dot com
-Status: No Feedback
+Status: Closed
Bug Type: Apache2 related
Operating System: Windows XP Pro
PHP Version: 4.4.2
New Comment:
This bug has been fixed in CVS 3 months ago.
Previous Comments:
[2006-04-05 02:57:51] nospam at fidk dot com
Get the same problem (PHP crashes) with fopen as well as file and
file_get_contents. Under 4.2.2. Try this code:
http://".$host.$location;
$fd = fopen($pirepUrl, "rb");
echo("Done");
?>
[2006-03-16 15:07:48] jaroslav dot povolny at gmail dot com
I have just installed back 4.4.1 version and the bug disappeared. It is
definetelly 4.4.2 bug, it is somewhere in file() or file_get_contents().
Platform: Windows XP
[2006-03-16 15:03:45] jaroslav dot povolny at gmail dot com
I am getting the same error without Apache environment when using
function file_get_contents() and file() with http protocol... I think
it is connected
[2006-03-01 01:00:03] 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".
[2006-02-27 21:33:42] stitched at mindspring dot com
I can confirm that this problem is fixed with 5.1.2. I didn't see a
backtrace version for 4.4.2 so was unable to get one. But something is
certainly broken in 4.4.2.
Dave
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/36473
--
Edit this bug report at http://bugs.php.net/?id=36473&edit=1
