#30046 [Com]: Apache crashes when $_COOKIE[] is accessed
ID: 30046
Comment by: ante dot dfg at moj dot net
Reported By: verbert_p at hotmail dot com
Status: Open
Bug Type: Apache2 related
Operating System: Win XP SP2
PHP Version: 5.0.1
New Comment:
I can also confirm this bug on Win XP under Apache 1.3.31 using release
version of php 5.0.1...
Reproduce code
[PHP]
if(isset($_COOKIE[]))
print ("Coookie");
[/PHP]
After runing the script Apache 1.3.31 craches...
Previous Comments:
[2004-09-10 04:19:04] verbert_p at hotmail dot com
Description:
When I address $_COOKIE[] instead of $_COOKIE['name'], apache (2.0.50
win32) crashes. this problem does not exist on apache 2.0.48 / php
4.3.4
Reproduce code:
---
if (isset ($_COOKIE[])) { ... }
Expected result:
false / true
Actual result:
--
apache crash
--
Edit this bug report at http://bugs.php.net/?id=30046&edit=1
#21522 [Com]: Ldap unable to load - module not found
ID: 21522 Comment by: dralibak at yahoo dot com Reported By: bool at gte dot net Status: Bogus Bug Type: LDAP related Operating System: Windots NT PHP Version: 4.3.0 New Comment: Hi, I have all the extensions downloaded from the 5.01 version of php and pecl. I keep getting the "unable to load" and the "()" ! same issues as above. I've read the install.txt with regard to the extensions. It's not recognizing the php_mysql.dll during the start. the older 4.3 cgi version with installer worked fine but.. not the 5.01 (used installer). in the php.ini, it says something about enabling the dll function doesn't work in the windows nt or 2003?.. ok any suggestions? Previous Comments: [2003-01-09 08:53:19] bool at gte dot net I fell like a dolt now... I copied the files and everything is working like a charm. Thank you very much for the help. [2003-01-08 17:51:14] [EMAIL PROTECTED] You probably missed a part in the install intructions about copying dlls\*.dll to c:\winnt\system32. [2003-01-08 12:46:16] bool at gte dot net When attempting to enable the extension php_ldap.dll from the 4.3.0 windows binary build I first copied the dll to c:\php\, set the proper variable in php.ini to tell php to look for extensions in c:\php and uncommented the line extension=php_ldap.dll. save, shutdown iis, restart to get an error telling me that module c:\php\php_ldap.dll is not found and there is a refrence to function Unknown(). After verifying that I did not screw up my copy job and the file c:\php\php_ldap.dll DID exist I came back to the site and did a serch for others having the same problem. In 2001 there were many refrences to the same error and the solution was to move libsasl.dll to the same location as php_ldap.dll. I also found documentation stating that libsasl.dll was already bundled into 4.3.0. I was unable to locate libsasl.dll anywhere in the binary zip of 4.3.0. I've noticed at least two other people here experiencing similiar problems. -- Edit this bug report at http://bugs.php.net/?id=21522&edit=1
#29312 [Opn->Fbk]: set_exception_handler does not work correctly
ID: 29312
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Zend Engine 2 problem
Operating System: WinXP w/SP1
PHP Version: 5.0.0
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-07-22 00:09:34] [EMAIL PROTECTED]
Description:
When supplying an object/method callback for set_exception_handler it
does not work if no exception message is passed. If you use a function
of a static method it works fine.
If you pass a message, it also works as expected
- Davey
Reproduce code:
---
Expected result:
object(Exception)#1 (6) {
["message:protected"]=>
string(0) ""
["string:private"]=>
string(0) ""
["code:protected"]=>
int(0)
["file:protected"]=>
string(53) "D:\web\php-mag\shafikdavey_errorhandling\listing2.txt"
["line:protected"]=>
int(12)
["trace:private"]=>
array(0) {
}
}
Actual result:
--
Fatal error: Uncaught exception 'Exception' in
D:\web\php-mag\shafikdavey_errorhandling\listing2.txt:12
Stack trace:
#0 {main}
thrown in
D:\web\php-mag\shafikdavey_errorhandling\listing2.txt on line
12
--
Edit this bug report at http://bugs.php.net/?id=29312&edit=1
#29224 [Com]: DB Error: extension not found
ID: 29224 Comment by: MikeTodd13 at hotmail dot com Reported By: marcschroeder at hotmail dot com Status: Bogus Bug Type: *Configuration Issues Operating System: Microsoft Windows XP PHP Version: 5.0.1 New Comment: I was having the same problem, running Apache 2.0.50 and PHP 5.0.1 under WinXP Professional. The only way that I could fix it was to copy libmysql.dll to the system folder. I have no clue why it can't be found when I have the PHP directory in the PATH environment variable, but it can't. Rather annoying; I would assume that this happens with all extensions, and I certainly hope that it gets fixed in the next version of PHP. I really don't like having to copy things into my system directory if it can be avoided. Previous Comments: [2004-08-27 23:27:52] at989 at earthlink dot net I think this is a IIS problem, not PHP. I had the same thing several times, and each time it goes away after I tweak something in IIS. I changed the dll to which the php extension is maped to see if I got a similar message or not (to see if this was indeed a php or iis problem). I got "module not found" message. After I restored the mapping, everything worked fine :-/ I have no idea why this happened. But i hope this will help someone who knows more about iis to figure this out. [2004-08-23 18:31:01] bentrafford at yahoo dot com Make that six users with the same problem. I've searched the bug database, the net, newsgroups, and found no resolution to this issue, other than PHP developers declaring it bogus. Well, I've got my path updated, and the following set in my php.ini: extension_dir = ".;c:/php/ext/" I'm still getting the same issue as described above. This is either a bug with PHP or a bug with the documentation. [2004-08-03 00:58:50] marcschroeder at hotmail dot com Who set the status to 'Bogus'? Why? I pretended that the current installation of PHP 5.0.0. does not install PEAR DB? 5 users claimed that they could reproduce the bug. The suggested solutions consisted in moving files around on a computer to places where "it might work". The solutions only claim to "solve the problem", but do not claim that there is no problem. Somebody else suggests that I change the system path. But I did add the following system variables already: "PHP_PEAR_SYSCONF_DIR"="C:\\php" "PHP_PEAR_INSTALL_DIR"="C:\\php\\pear" "PHP_PEAR_DOC_DIR"="C:\\php\\pear\\docs" "PHP_PEAR_BIN_DIR"="C:\\php" "PHP_PEAR_DATA_DIR"="C:\\php\\pear\\data" "PHP_PEAR_PHP_BIN"="C:\\php\\php.exe" "PHP_PEAR_TEST_DIR"="C:\\php\\pear\\tests" Do these environment variables have no effect? I start to believe that PHP is a tool for hackers only, and that the need of a controlled installation procedure is not present in the mind of the PHP community. This is really sad, as I like PHP a lot. [2004-08-02 14:02:47] dinojazz at hotmail dot com I am having the issues as well. My php_mysql.dll is located in c:\php and php.ini knows this. I've moved libmysql.dll to c:\windows\system32 as well. On top of this all, the extension=php_mysql.dll in php.ini has been uncommented. Yet, I get errors when I try to have mysql/php things loaded in my webpage. It comes up with 'Unable to load dynamic library 'c:\php\php_mysql.dll\' - The specified procedure could not be found'. I've tried the suggestions like php_mysql.dll to c:\windows\system32 and all the stuff. Even moved libmysql.dll to various places, but nothing worked. I am kind of stumped here, looks like there's some heavy bug in there. [2004-08-02 11:24:40] [EMAIL PROTECTED] Either add c:\php to your system path, or copy all dlls from that folder to system32. 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/29224 -- Edit this bug report at http://bugs.php.net/?id=29224&edit=1
#30044 [Bgs->Opn]: Don't require php tags for shell scripts.
ID: 30044 User updated by: nconantj at frontiernet dot net Reported By: nconantj at frontiernet dot net -Status: Bogus +Status: Open Bug Type: Feature/Change Request Operating System: Linux PHP Version: Irrelevant New Comment: The only option there that is approaching relevent is -r, but that requires some form of quoting to prevent the shell from parsing it, and it requires that every line have a backslash (\) just prior to the new line. Previous Comments: [2004-09-10 00:55:06] [EMAIL PROTECTED] You should read the output of: php -h [2004-09-10 00:46:16] nconantj at frontiernet dot net Description: I would deeply appreciate it if I could write a PHP shell script without the PHP required tags. As far as implementing this, make it a command line option for the CLI (--notags). PHP is a powerful language that could be more easily used for system shell scripts with this ability. I would be able to write a script as follows: #!/usr/bin/php --notags <> rather than as: #!/usr/bin/php > ?> -- Edit this bug report at http://bugs.php.net/?id=30044&edit=1
#30046 [NEW]: Apache crashes when $_COOKIE[] is accessed
From: verbert_p at hotmail dot com
Operating system: Win XP SP2
PHP version: 5.0.1
PHP Bug Type: Apache2 related
Bug description: Apache crashes when $_COOKIE[] is accessed
Description:
When I address $_COOKIE[] instead of $_COOKIE['name'], apache (2.0.50
win32) crashes. this problem does not exist on apache 2.0.48 / php 4.3.4
Reproduce code:
---
if (isset ($_COOKIE[])) { ... }
Expected result:
false / true
Actual result:
--
apache crash
--
Edit bug report at http://bugs.php.net/?id=30046&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30046&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30046&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30046&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30046&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30046&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30046&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30046&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30046&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30046&r=support
Expected behavior: http://bugs.php.net/fix.php?id=30046&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30046&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30046&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30046&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30046&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30046&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30046&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30046&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30046&r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30046&r=mysqlcfg
#30045 [NEW]: Cannot pass big integers (> 2147483647) in SOAP requests
From: paulmonk at shaw dot ca Operating system: Windows 2000 PHP version: 5.0.1 PHP Bug Type: SOAP related Bug description: Cannot pass big integers (> 2147483647) in SOAP requests Description: It seems that xsd:long values > 2147483647 are not represented correctly in SOAP requests/responses. Looks like they are being treated as PHP integers. (Unsigned longs work fine.) Reproduce code: --- When I pass the following parameters in a SoapClient::__call(): $long1 = new SoapVar(2147483647, XSD_LONG); $long2 = new SoapVar(2147483648, XSD_LONG); $long3 = new SoapVar(4294967296, XSD_LONG); $long4 = new SoapVar(8589934592, XSD_LONG); $long5 = new SoapVar(17179869184, XSD_LONG); $ulong1 = new SoapVar(2147483647, XSD_UNSIGNEDLONG); $ulong2 = new SoapVar(2147483648, XSD_UNSIGNEDLONG); $ulong3 = new SoapVar(4294967296, XSD_UNSIGNEDLONG); $ulong4 = new SoapVar(8589934592, XSD_UNSIGNEDLONG); $ulong5 = new SoapVar(17179869184, XSD_UNSIGNEDLONG); Expected result: The parameters in the SOAP request should be: ... 2147483647 2147483648 4294967296 8589934592 17179869184 2147483647 2147483648 4294967296 8589934592 17179869184 Actual result: -- The actual parameters in the SOAP request are: ... 2147483647 -2147483648 0 0 0 2147483647 2147483648 4294967296 8589934592 17179869184 -- Edit bug report at http://bugs.php.net/?id=30045&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30045&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30045&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30045&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30045&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30045&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30045&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30045&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30045&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30045&r=support Expected behavior: http://bugs.php.net/fix.php?id=30045&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30045&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30045&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30045&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30045&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30045&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30045&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30045&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30045&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30045&r=mysqlcfg
#30043 [Opn]: ODBC Column Name Truncation
ID: 30043 Updated by: [EMAIL PROTECTED] Reported By: arobins at csg dot uwaterloo dot ca Status: Open Bug Type: ODBC related Operating System: Win2k or Linux PHP Version: Irrelevant New Comment: Known issue. Was once looked into correct to provide true multi-byte support, but was side tracked. Previous Comments: [2004-09-09 22:08:24] arobins at csg dot uwaterloo dot ca Description: When retrieving ODBC results from Sybase SQL Anywhere 6 and 9, the column names are being truncated to 31 characters. This happens even if the column name is simply specified using sql 'AS' (i.e. "select column as a_really_long_name_that_is_longer_than_31_characters from crap" would still return "a_really_long_name_that_is_long" as the column name). Have tried in PHP 4 and 5, Win2K Server and SUSE Linux, all with same results. -- The buffer used by the odbc extension to store field names is only 32 bytes. Reproduce code: --- Expected result: 1: key - 4 2: a_really_long_name_that_is_longer_than_31_characters - 5 3: longer_name - 6 Actual result: -- 1: key - 4 2: a_really_long_name_that_is_long - 5 3: longer_name - 6 -- Edit this bug report at http://bugs.php.net/?id=30043&edit=1
#8416 [Com]: Unable to load dynamic library
ID: 8416 Comment by: peachapol at hotmail dot com Reported By: jcwang at mail dot cgu dot edu dot tw Status: Bogus Bug Type: IIS related Operating System: Windows 2000 - professional PHP Version: 4.0.4 New Comment: I was having extension_dir = ".;C:\php\extensions" after I changed it to extension_dir = "C:\php\extensions" it works now! (WINDOWS XP) Previous Comments: [2003-06-06 05:01:22] [EMAIL PROTECTED] User error -> Bogus [2003-06-05 18:00:42] info at ipdg3 dot com Never Mind this post answered it Stupid me I forgot to copy the new DLLs into the system32 folder. http://bugs.php.net/bug.php?id=21522 [2003-06-05 17:55:57] info at ipdg3 dot com Sorry guess left something out. It worked on the previous install I did and once I upgraded it stopped working as specified above. I have checke the files and they are there. I have also made sure there are no php.ini files on the system rebooted, stopped and started the website etc nothing seems to work. Also the Win2k server is all up to date on patches. Thought I would add that some Microsoft patches break things. [2003-06-05 17:51:50] info at ipdg3 dot com I have installed PHP4.3.2 on a Win2k Server with IIS 5.0. Everything works great till I uncomment this line. extension=php_ldap.dll ; Directory in which the loadable extensions (modules) reside. ;extension_dir = "./" extension_dir = "C:\php\extensions" I get this message. Unknown(): Unable to laod dynamic library 'C:\php\extensions\php_ldap.dll' - The operating system cannot run %1 I am not sure if it is setup right but it use to work before the update any suggestions. [2001-03-09 21:28:14] [EMAIL PROTECTED] No feedback. 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/8416 -- Edit this bug report at http://bugs.php.net/?id=8416&edit=1
#30044 [Opn->Bgs]: Don't require php tags for shell scripts.
ID: 30044 Updated by: [EMAIL PROTECTED] Reported By: nconantj at frontiernet dot net -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: Linux PHP Version: Irrelevant New Comment: You should read the output of: php -h Previous Comments: [2004-09-10 00:46:16] nconantj at frontiernet dot net Description: I would deeply appreciate it if I could write a PHP shell script without the PHP required tags. As far as implementing this, make it a command line option for the CLI (--notags). PHP is a powerful language that could be more easily used for system shell scripts with this ability. I would be able to write a script as follows: #!/usr/bin/php --notags <> rather than as: #!/usr/bin/php > ?> -- Edit this bug report at http://bugs.php.net/?id=30044&edit=1
#30044 [NEW]: Don't require php tags for shell scripts.
From: nconantj at frontiernet dot net Operating system: Linux PHP version: Irrelevant PHP Bug Type: Feature/Change Request Bug description: Don't require php tags for shell scripts. Description: I would deeply appreciate it if I could write a PHP shell script without the PHP required tags. As far as implementing this, make it a command line option for the CLI (--notags). PHP is a powerful language that could be more easily used for system shell scripts with this ability. I would be able to write a script as follows: #!/usr/bin/php --notags <> rather than as: #!/usr/bin/php > ?> -- Edit bug report at http://bugs.php.net/?id=30044&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30044&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30044&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30044&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30044&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30044&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30044&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30044&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30044&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30044&r=support Expected behavior: http://bugs.php.net/fix.php?id=30044&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30044&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30044&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30044&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30044&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30044&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30044&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30044&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30044&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30044&r=mysqlcfg
#28583 [Bgs]: create_function() with NULL string introduces unexpected results
ID: 28583 User updated by: jed at jed dot bz Reported By: jed at jed dot bz Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows XP Pro PHP Version: 5.0.0RC2 Assigned To: hholzgra New Comment: There needs to be more choices, then, because there definitely was a bug. And simply waiting for it to clear itself up and then instructing the submitter to upgrade, two versions and four months later, really makes the submitter feel he's done a good deed for the community. Previous Comments: [2004-09-09 08:03:46] [EMAIL PROTECTED] We could not find a bug, so this bug report is bogus. [2004-09-09 04:34:28] jed at jed dot bz Closed, not bogus. [2004-09-03 05:13:46] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. I\'m unable to reproduce bug with current version of php5. [2004-05-30 21:36:03] jed at jed dot bz Description: Apache/2.0.49 (Win32) PHP/5.0.0RC2 Server Using create_function() incorrectly, i.e.: $y = create_function(NULL, "cos(4);"); ...causes instability in PHP itself as no checking is done on the create_function() arguments. Every so often when this script is refreshed, PHP dumps all kinds of garbage followed by what appears to be HTTP headers (viewable in Mozilla Firefox 0.8): => d getallheaders 1 1 1 1 1 1 1 1 1 2 ) 1 1 1 1 1 1 [ 4 user 5 ] => 6 Array 1 1 1 1 1 1 1 1 2 ( 1 1 1 1 1 1 1 1 2 ) 1 2 ) 6 0 HTTP/1.1 200 OK Date: Sun, 30 May 2004 19:22:08 (...) Then the actual script output starts, which is corrupted all the same. Internet Explorer 6 on the same page attempts to refresh the page automatically numerous times, and never finishes. Could this possibly be the beginning of some kind of exploit in PHP? I have no idea what the output means but I submit it for the benefit of community review. Reproduce code: --- "; $x = get_defined_functions(); print_r($x); print ""; ?> Expected result: Array ( [internal] => Array ( [0] => zend_version (...) Actual result: -- 1 1 1 [ 2 65 5 ] => 8 unixtojd 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 66 5 ] => 8 jdtounix 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 67 5 ] => 9 cal_to_jd 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 68 5 ] => b cal_from_jd 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 69 5 ] => 11 cal_days_in_month 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 70 5 ] => 8 cal_info 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 71 5 ] => b variant_set 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 72 5 ] => b variant_add 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 73 5 ] => b variant_cat 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 74 5 ] => b variant_sub 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 75 5 ] => b variant_mul 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 76 5 ] => b variant_and 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 77 5 ] => b variant_div 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 78 5 ] => b (...) -- Edit this bug report at http://bugs.php.net/?id=28583&edit=1
#30043 [NEW]: ODBC Column Name Truncation
From: arobins at csg dot uwaterloo dot ca Operating system: Win2k or Linux PHP version: Irrelevant PHP Bug Type: ODBC related Bug description: ODBC Column Name Truncation Description: When retrieving ODBC results from Sybase SQL Anywhere 6 and 9, the column names are being truncated to 31 characters. This happens even if the column name is simply specified using sql 'AS' (i.e. "select column as a_really_long_name_that_is_longer_than_31_characters from crap" would still return "a_really_long_name_that_is_long" as the column name). Have tried in PHP 4 and 5, Win2K Server and SUSE Linux, all with same results. -- The buffer used by the odbc extension to store field names is only 32 bytes. Reproduce code: --- Expected result: 1: key - 4 2: a_really_long_name_that_is_longer_than_31_characters - 5 3: longer_name - 6 Actual result: -- 1: key - 4 2: a_really_long_name_that_is_long - 5 3: longer_name - 6 -- Edit bug report at http://bugs.php.net/?id=30043&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30043&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30043&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30043&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30043&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30043&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30043&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30043&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30043&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30043&r=support Expected behavior: http://bugs.php.net/fix.php?id=30043&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30043&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30043&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30043&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30043&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30043&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30043&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30043&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30043&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30043&r=mysqlcfg
#29973 [Opn->Asn]: Comparing COM object variable with NULL throws an exception
ID: 29973
Updated by: [EMAIL PROTECTED]
Reported By: tetikr at spytech dot cz
-Status: Open
+Status: Assigned
Bug Type: COM related
Operating System: Win2000
PHP Version: 5.0.1
-Assigned To:
+Assigned To: wez
New Comment:
in this case you should be doing:
try {
$a = new COM(...);
// use it here
} catch (exception $e) {
// failed to create it
}
in other cases, where you have been passed the object, use is_object()
to check if it is valid.
I'll see if I can fix the shorthand "if (!$a)" syntax someone in the
next month.
Previous Comments:
[2004-09-06 14:27:03] tetikr at spytech dot cz
Some objects work and some not. The following code creates an object
that works not. It throws a COM exception "Member not found". Test it
for yourself, I hope it will fail :-)
-
$o = new COM("WScript.Shell");
if (!$o)
/* dummy */ ;
else
echo $o->CurrentDirectory;
-
[2004-09-06 08:06:19] [EMAIL PROTECTED]
What is the full error message?
[2004-09-03 19:08:58] tetikr at spytech dot cz
Description:
Comparing COM object variable with NULL throws an exception
Reproduce code:
---
$a = new COM(.);
if (!$a)
{
..
}
else
{
.
}
Expected result:
If $a is non null, I expect the ELSE block to be performed.
Actual result:
--
PHP throws an exception when trying to evaluate !$a. I think it tries
to access the default COM object's property.
If this is a valid behavior, how should I test for null?
--
Edit this bug report at http://bugs.php.net/?id=29973&edit=1
#30042 [NEW]: strtotime does not use second param
From: jorge at newsengin dot com
Operating system: OS X Panther
PHP version: 5.0.1
PHP Bug Type: Date/time related
Bug description: strtotime does not use second param
Description:
This seems related to the open bug involving "now"
resetting to midnight of the current day, but it's not
identical.
If you try to adjust a time by passing strtotime() an
offset like "+2 hours", you get that offset relative to
midnight. In other words, strtotime("+2 hours",
$unixtimestamp) returns a timestamp for 2 a.m, of the
day referenced by $unixtimestamp, or of the current day
if the second argument is omitted.
Reproduce code:
---
// in PHP 4, this correctly returns 3:30 p.m. on Jan 1, 2005 but in PHP
5.0.1 returns 2:00 a.m. on Jan 1, 2005:
$timeStamp = strtotime("+2 hours", strtotime("1/1/2005 1:30pm"));
echo date("r", $timeStamp);
// in PHP 4, this correctly returns a date/time for two hours from now,
but in PHP 5.0.1 it returns 2 a.m. on the current day:
$timeStamp = strtotime("+2 hours");
echo date("r", $timeStamp);
Expected result:
two hours from given date and time or from now,
depending on whether a second timestamp argument was
provided to strtotime();
Actual result:
--
2 a.m. on relevant date.
--
Edit bug report at http://bugs.php.net/?id=30042&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30042&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30042&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30042&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30042&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30042&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30042&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30042&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30042&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30042&r=support
Expected behavior: http://bugs.php.net/fix.php?id=30042&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30042&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30042&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30042&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30042&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30042&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30042&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30042&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30042&r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30042&r=mysqlcfg
#30041 [NEW]: pdf_open_file() expects exactly 2 parameters, 1 given
From: pdowson at aea9 dot k12 dot ia dot us Operating system: FreeBSD 5.2 PHP version: 4.3.8 PHP Bug Type: *PDF functions Bug description: pdf_open_file() expects exactly 2 parameters, 1 given Description: The PHP manual describes pdf_open_file as working with just one argument (the pdf handle). The code works fine if you supply a filename as the second argument. Reproduce code: --- $pdf = pdf_new(); pdf_open_file($pdf); Expected result: It should work without an error. Should create a PDF document in memory, not in a file. Actual result: -- Warning: pdf_open_file() expects exactly 2 parameters, 1 given in /home/wwwpath/pdf.php on line 2 -- Edit bug report at http://bugs.php.net/?id=30041&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30041&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30041&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30041&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30041&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30041&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30041&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30041&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30041&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30041&r=support Expected behavior: http://bugs.php.net/fix.php?id=30041&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30041&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30041&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30041&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30041&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30041&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30041&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30041&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30041&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30041&r=mysqlcfg
#30019 [Bgs]: $_SERVER['HTTP_REFERER']; doesn't always display
ID: 30019 User updated by: asfsm at uaa dot alaska dot edu Reported By: asfsm at uaa dot alaska dot edu Status: Bogus Bug Type: *General Issues Operating System: Windows 2003 (standard) PHP Version: 5.0.1 New Comment: Yes I understand how the web works, but I don't obviously know everything. Your explanation of referer makes sense though. Previous Comments: [2004-09-09 09:01:19] [EMAIL PROTECTED] Especially if the cache is cleared and the page reloaded. Do you understand what the referrer actually means? It is the URL that a user clicked on a link to get to your page. If the user simply types in the url or does a reload, there will be no referrer in the request. This isn't a browser "issue", this is simply how the Web works. [2004-09-08 20:59:11] asfsm at uaa dot alaska dot edu Even if the cache is cleared and the page is reloaded? this is a browser issue? [2004-09-08 06:04:33] [EMAIL PROTECTED] Because clients don't always send the referrer. No bug here. PHP will have it if the client provides it, otherwise it won't. [2004-09-08 00:27:34] asfsm at uaa dot alaska dot edu Description: $_SERVER['HTTP_REFERER']; doesn't always display It displays occassionally, but not all the time. Reproduce code: --- Expected result: Actual result: -- -- Edit this bug report at http://bugs.php.net/?id=30019&edit=1
#30040 [NEW]: child pid XXXX exit signal Segmentation Fault (11)
From: dmarek1 at att dot net Operating system: Solaris 2.8 PHP version: 5.0.0 PHP Bug Type: Reproducible crash Bug description: child pid exit signal Segmentation Fault (11) Description: I have iAS 10G running and we are using PHP 5. When I restart the http server and then go to a PHP page the following error occurs child pid exit signal Segmentation Fault (11). After we cycle through about 30 processes we don't see the error again. This is also what I could grab from the core file core file = core -- program ``httpd'' on platform SUNW,Sun-Fire-V210 SIGBUS: Bus Error $c_libc_poll() + 8 data address not found Reproduce code: --- Not sure what source code calls it since it isn't specific to a page. It is just all PHP code after server restart Expected result: Not to have core dump. I have been working with Oracle also and they keep pushing to your side although I don't really agree with it. They are still investigating on there side. Actual result: -- See above desription -- Edit bug report at http://bugs.php.net/?id=30040&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30040&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30040&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30040&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30040&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30040&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30040&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30040&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30040&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30040&r=support Expected behavior: http://bugs.php.net/fix.php?id=30040&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30040&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30040&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30040&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30040&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30040&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30040&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30040&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30040&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30040&r=mysqlcfg
#30039 [Opn->Bgs]: HTTP 'Content-Language' header gets double value when 'en' is used
ID: 30039
Updated by: [EMAIL PROTECTED]
Reported By: epoc_32 at yahoo dot co dot ukXXX
-Status: Open
+Status: Bogus
Bug Type: Output Control
Operating System: FreeBSD 4.8
PHP Version: 4.3.8
New Comment:
PHP doesn't modify this header, so it can't be a bug in PHP. I suspect
it's apache playing tricks.
Previous Comments:
[2004-09-09 15:48:35] epoc_32 at yahoo dot co dot ukXXX
Description:
I am using the following line in a script:
header('Content-Language: '.$PAGE['lang']);
If $PAGE['lang'] is 'no' then the http header gets sent as expected:
Content-Language: no
However when $PAGE['lang'] is 'en' (and it definately is just 'en'
without any whitespace or uppercase characters) then this gets sent
instead:
Content-Language: en, en
Is this a bug or am I not understanding something? Or maybe something
Apache's doing afterwards? (I have version 1.3.29)
I did some testing and it seems the first 'en' is my string and the
second one is being added if that's of any help.
Reproduce code:
---
// English
header('Content-Language: en');
// Norwegian
header('Content-Language: no');
Expected result:
Content-Language: en
Content-Language: no
Actual result:
--
Content-Language: en, en
Content-Language: no
--
Edit this bug report at http://bugs.php.net/?id=30039&edit=1
#30039 [NEW]: HTTP 'Content-Language' header gets double value when 'en' is used
From: epoc_32 at yahoo dot co dot ukXXX
Operating system: FreeBSD 4.8
PHP version: 4.3.8
PHP Bug Type: Output Control
Bug description: HTTP 'Content-Language' header gets double value when 'en' is used
Description:
I am using the following line in a script:
header('Content-Language: '.$PAGE['lang']);
If $PAGE['lang'] is 'no' then the http header gets sent as expected:
Content-Language: no
However when $PAGE['lang'] is 'en' (and it definately is just 'en' without
any whitespace or uppercase characters) then this gets sent instead:
Content-Language: en, en
Is this a bug or am I not understanding something? Or maybe something
Apache's doing afterwards? (I have version 1.3.29)
I did some testing and it seems the first 'en' is my string and the second
one is being added if that's of any help.
Reproduce code:
---
// English
header('Content-Language: en');
// Norwegian
header('Content-Language: no');
Expected result:
Content-Language: en
Content-Language: no
Actual result:
--
Content-Language: en, en
Content-Language: no
--
Edit bug report at http://bugs.php.net/?id=30039&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30039&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30039&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30039&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30039&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30039&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30039&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30039&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30039&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30039&r=support
Expected behavior: http://bugs.php.net/fix.php?id=30039&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30039&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30039&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30039&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30039&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30039&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30039&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30039&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30039&r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30039&r=mysqlcfg
#29608 [Com]: OCi reports OCIStmtExecute: ORA-24324: service handle not initialized
ID: 29608
Comment by: artmotion at nurfuerspam dot de
Reported By: tomek at matrox dot pl
Status: No Feedback
Bug Type: OCI8 related
Operating System: W2k, Red Hat
PHP Version: 5.0.0
New Comment:
oci_new_connect did the job!
One of those things that must be documented much better and brought to
the developer's attention.
Previous Comments:
[2004-09-01 10:40:18] marcus dot schuelke at juj dot de
This Bug is caused by PHP 5
to fix the problem use
oci_new_connect ( username,password, db)
instead of ocilogon();
hope that will fix your problem..
[2004-09-01 02:51:44] cnichols at nmu dot edu
Same problem over here. Running PHP 5.0.1 with Apache2 and Oracle 10g.
I found a site saying that errmsg has to do with a soon-to-expire
password, but I doubt that's the case for all of you :)
[2004-08-30 10:21:46] symedeot at yahoo dot fr
I have exactly the same problem ! If works sometimes, sometime not. If
you ask the same page again, it should work or not...
Warning: oci_execute() [function.oci-execute]: OCIStmtExecute:
ORA-24324: descripteur de service non initialisé in ...
Warning: ocifetch() [function.ocifetch]: OCIFetch: ORA-24338:
descripteur d'instruction non exécuté in...
Just try to access Oracle like this :
$conn = OCILogon("GPE", "gpe","PLSE");
$stmt = OCIParse($conn,$myrequest);
OCI_Execute($stmt,OCI_DEFAULT);
while ( OCIFetch($stmt) )
{
}
OCIFreeStatement($stmt);
OCILogoff($conn);
Oracle 9.i under RedHat 9, php 5.00 and 5.01(same), any Apache 2
version.
Everything fine on same server when using PHP 4.3x
It is clearly a bug ! And we are quite a lot to report it !
[2004-08-19 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".
[2004-08-12 11:02:53] izhekov at ppartner dot com
I've tried to reproduce this problem.
I've installed 2 apache services on different ports 80 and 81 - first
of them using PHP5 and the other using PHP4 then I restarted the
system.
When first I access my scripts using PHP5 on port 80 everythings goes
fine.
Running scripts afterthat with PHP4 on port 81 also worked fine.
When I tried to access again scripts on apache service running on 80
port, errors occured again:
-
Warning: ociexecute() [function.ociexecute]: OCIStmtExecute: ORA-24324:
service handle not initialized in
C:\SERVER\HTTPD\htdocs\service\db_modul.php on line 21
Warning: ocifetch() [function.ocifetch]: OCIFetch: ORA-24338: statement
handle not executed in C:\SERVER\HTTPD\htdocs\service\db_modul.php on
line 27
--
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/29608
--
Edit this bug report at http://bugs.php.net/?id=29608&edit=1
#29917 [WFx]: isset() always return
ID: 29917
Updated by: [EMAIL PROTECTED]
Reported By: dasch at ulmail dot net
Status: Wont fix
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 5.*
Assigned To: Andi
New Comment:
PHP doesn't become inconsistent. It only doesn't allow to check for the
presense of virtual proeprties using isset()/empty().
The problem is that we cannot allow the consistency because that would
mean that we need to call __get() for every isset/empty property check
where the property is no declared. Also defining a __exists has the
same problem. Still we would need to call it for every non declared
property. So that is both a major slow down which we cannot overcome by
some __get/__set optimizations.
Previous Comments:
[2004-09-09 14:27:06] fch at hexanet dot fr
The problem was not that __set() and __get() are slow.
The problem is that, if __get() and __set() are defined in an object,
PHP becomes "unconsistent", that is to say that some functions like
isset() have not these usual behavior if __get() and __set() are
defined in an object.
And abstract properties is a very strange concept...
However, a __get() and __set() optimization is a good idea.
Fred.
[2004-09-03 20:30:43] [EMAIL PROTECTED]
We'd need to all __get() for every non existing property then which
would be worse than only a mahor slowdown.
Een a __exists() would'n help much because that, too. Would be very
slow. The only way out would be to declare abstract properties as
allowed by this patch:
http://marcus-boerger.de/php/ext/ze2/ze2-abstract-properties-20040803.diff.txt
[2004-09-03 13:48:23] fch at hexanet dot fr
offsetGet($key);
}
function __set($key, $value)
{
$this->offsetSet($key, $value);
}
function offsetExists($key)
{
return isset($this->array[$key]);
}
function offsetGet($key)
{
return $this->array[$key];
}
function offsetSet($key, $value)
{
$this->array[$key] = $value;
}
function offsetUnset($key)
{
unset($this->array[$key];
}
}
$foo = new foo();
echo (isset($foo['bar']) == true ? 'set' : 'not set');
$foo['bar'] = 'bar';
echo (isset($foo['bar']) == true ? 'set' : 'not set');
echo $foo['bar'];
#Expected result :
# not set
# set
# bar
#Real result
# not set
# set
# bar
# !! GREAT !!
#Now, the same thing with __get() and __set()
unset($foo);
$foo = new foo();
echo (isset($foo->array) == true ? 'array is set' : 'array is not
set');
echo (isset($foo->bar) == true ? 'bar is set' : 'bar is not set');
$foo->bar = 'bar';
echo (isset($foo['bar']) == true ? 'bar is set' : 'bar is not set');
echo $foo->bar;
#Expected result :
# array is set
# bar is not set
# bar is set
# bar
#Real result
# array is set # Ok !
# bar is not set # Ok !
# bar is not set # PROBLEM PROBLEM
# bar
# !! NOT GREAT !!
?>
It is abnormal !
isset() does not return the good value on property wich was set with
__set() it is return the good value on property wich was set in the
class,and isset() return the good value on value wich was set with
offsetSet() method !!
It is a paradox !
I think that isset MUST return the same value in all case.
[2004-09-01 13:51:05] dasch at ulmail dot net
If the isset() function aren't going to work with properties accessed
with a __get() call, then there should at least be a __isset() method
that allows for custom isset()-handling. eg:
$prop)) {
return TRUE;
} else {
return FALSE;
}
}
}
$foo = new Foo();
echo isset($foo->bar) ? "yes\n" : "no\n";
// Should be the same as
echo $foo->__isset('bar') ? "yes\n" : "no\n";
?>
[2004-09-01 10:24:01] fch at hexanet dot fr
Can you explain where are wrong ???
A call to __set() create a property in the object (see documentation).
Event if this property is not a real member property for PHP language
point of view, for the programers point of view, it is a property !
So, isset() MUST return true in my example.
What are difference between your example :
$o->a = 'bar';
echo isset($o->a) ? "yes\n" : "no\n";
And my example :
$o->foo = 'bar';
echo (isset($o->foo) == true ? 'foo is set' : 'foo is not set');
There is no difference ! Except that my foo property was created with a
__set() call.
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/29917
--
Edit this bug report at http://bugs.php.net/?id=29917&edit=1
#19092 [Com]: Cannot load php_xslt.dll
ID: 19092 Comment by: troels at kyberfabrikken dot dk Reported By: tony at marston-home dot demon dot co dot uk Status: Bogus Bug Type: XSLT related Operating System: Windows ME PHP Version: 4.2.2 New Comment: To make php_xslt.dll work, you need to copy the following files : sablot.dll expat.dll iconv.dll to c:\Windows\System32 or C:\WinNT\system32 Previous Comments: [2002-08-30 17:37:53] [EMAIL PROTECTED] Exactly as documented. User error => Bogus [2002-08-30 17:33:17] tony at marston-home dot demon dot co dot uk SOLVED!! I originally had all the PHP .dll files in the /php/extensions folder, and everything ran from there without a problem. It was when I tried to enable the php_xslt.dll that I started getting error messages about "unable to load dynamic library...". I checked it with Dependency Walker and this showed that two dll files were missing. It was suggested that I move all the dlls into the c:\windows\system folder, which I did, but when I checked with Dependency Walker the errors were still there. Because of the errors I did not try to run PHP with the xslt module enabled. But just today I enabled it so that I could check the error message again, but it did not appear! This seems strange because Dependency Walker will show the same errors whether the file is in the /php/extensions folder or the windows/system folder, but putting everything in the windows/system folder will NOT produce a runtime error. I can now access the xslt module, so this problem is now closed. Thanks for your efforts. [2002-08-25 18:30:33] [EMAIL PROTECTED] php_xslt.dll depends on sablot.dll which is in the dlls subdir of the php distribution. You have most likely forgotten to copy dlls to you system directory. [2002-08-25 14:25:33] tony at marston-home dot demon dot co dot uk When I try to enable 'extension=php_xslt.dll' in my php.ini file I get the following error when I start to start up Apache: "Unable to load dynamic library F:/php/extensions/php_xslt.dll - one of the library files needed to run this application cannot be found" When I look at php_xslt.dll with Dependency Walker it tells me that file APPHELP.DLL and USERENV.DLL are referenced but could not be found on my system. It also tells me that these files are being referenced from within SHLWAPI.DLL. What can I do to get this extension to work? -- Edit this bug report at http://bugs.php.net/?id=19092&edit=1
#29917 [Com]: isset() always return
ID: 29917
Comment by: fch at hexanet dot fr
Reported By: dasch at ulmail dot net
Status: Wont fix
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 5.*
Assigned To: Andi
New Comment:
The problem was not that __set() and __get() are slow.
The problem is that, if __get() and __set() are defined in an object,
PHP becomes "unconsistent", that is to say that some functions like
isset() have not these usual behavior if __get() and __set() are
defined in an object.
And abstract properties is a very strange concept...
However, a __get() and __set() optimization is a good idea.
Fred.
Previous Comments:
[2004-09-03 20:30:43] [EMAIL PROTECTED]
We'd need to all __get() for every non existing property then which
would be worse than only a mahor slowdown.
Een a __exists() would'n help much because that, too. Would be very
slow. The only way out would be to declare abstract properties as
allowed by this patch:
http://marcus-boerger.de/php/ext/ze2/ze2-abstract-properties-20040803.diff.txt
[2004-09-03 13:48:23] fch at hexanet dot fr
offsetGet($key);
}
function __set($key, $value)
{
$this->offsetSet($key, $value);
}
function offsetExists($key)
{
return isset($this->array[$key]);
}
function offsetGet($key)
{
return $this->array[$key];
}
function offsetSet($key, $value)
{
$this->array[$key] = $value;
}
function offsetUnset($key)
{
unset($this->array[$key];
}
}
$foo = new foo();
echo (isset($foo['bar']) == true ? 'set' : 'not set');
$foo['bar'] = 'bar';
echo (isset($foo['bar']) == true ? 'set' : 'not set');
echo $foo['bar'];
#Expected result :
# not set
# set
# bar
#Real result
# not set
# set
# bar
# !! GREAT !!
#Now, the same thing with __get() and __set()
unset($foo);
$foo = new foo();
echo (isset($foo->array) == true ? 'array is set' : 'array is not
set');
echo (isset($foo->bar) == true ? 'bar is set' : 'bar is not set');
$foo->bar = 'bar';
echo (isset($foo['bar']) == true ? 'bar is set' : 'bar is not set');
echo $foo->bar;
#Expected result :
# array is set
# bar is not set
# bar is set
# bar
#Real result
# array is set # Ok !
# bar is not set # Ok !
# bar is not set # PROBLEM PROBLEM
# bar
# !! NOT GREAT !!
?>
It is abnormal !
isset() does not return the good value on property wich was set with
__set() it is return the good value on property wich was set in the
class,and isset() return the good value on value wich was set with
offsetSet() method !!
It is a paradox !
I think that isset MUST return the same value in all case.
[2004-09-01 13:51:05] dasch at ulmail dot net
If the isset() function aren't going to work with properties accessed
with a __get() call, then there should at least be a __isset() method
that allows for custom isset()-handling. eg:
$prop)) {
return TRUE;
} else {
return FALSE;
}
}
}
$foo = new Foo();
echo isset($foo->bar) ? "yes\n" : "no\n";
// Should be the same as
echo $foo->__isset('bar') ? "yes\n" : "no\n";
?>
[2004-09-01 10:24:01] fch at hexanet dot fr
Can you explain where are wrong ???
A call to __set() create a property in the object (see documentation).
Event if this property is not a real member property for PHP language
point of view, for the programers point of view, it is a property !
So, isset() MUST return true in my example.
What are difference between your example :
$o->a = 'bar';
echo isset($o->a) ? "yes\n" : "no\n";
And my example :
$o->foo = 'bar';
echo (isset($o->foo) == true ? 'foo is set' : 'foo is not set');
There is no difference ! Except that my foo property was created with a
__set() call.
[2004-09-01 10:14:10] [EMAIL PROTECTED]
No, you're wrong. The behavior you see is the correct behavior.
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/29917
--
Edit this bug report at http://bugs.php.net/?id=29917&edit=1
#30038 [NEW]: Fatal error: Call to undefined function oci_new_collection()
From: v dot bolognesi at quanthink dot com Operating system: Red Hat Linux release 9 (Shrike PHP version: 5.0.1 PHP Bug Type: OCI8 related Bug description: Fatal error: Call to undefined function oci_new_collection() Description: >From phpinfo(): System: Linux cyber 2.4.20-18.9smp #1 SMP Thu May 29 6:55:05 EDT 2003 i686 Configure Command: './configure' '--prefix=/usr/local/php5-apache2' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-jpeg-dir=/usr/local/lib' '--with-jpeg' '--with-gd=/usr/local' '--with-zlib-dir=/usr/lib' '--with-png-dir=/usr/local/lib' '--with-freetype-dir=/usr/local/lib' '--with-oci8=/u01/app/oracle/product/10.1.0/client_1/' '--with-sybase-ct=/usr/local/' '--with-gettext' '--with-mysql' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-track-vars' '--enable-trans-sid' '--enable-memory-limit' '--enable-shmop' '--enable-versioning' '--enable-calendar' Reproduce code: --- note: the type T_XX is a sql type creaded with create type ... statement in sqlplus. Expected result: at least recognize the function :-) Also, I little of examples would be much appreciated. Browsing the documentation, I found that several collection-related features are available only in CVS. But nor for oci_new_collection (see: http://it.php.net/manual/en/function.oci-new-collection.php it's in english) neither for ocinewcollection, which doesn't work too. Thank you Actual result: -- Fatal error: Call to undefined function oci_new_collection() -- Edit bug report at http://bugs.php.net/?id=30038&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30038&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30038&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30038&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30038&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30038&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30038&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30038&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30038&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30038&r=support Expected behavior: http://bugs.php.net/fix.php?id=30038&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30038&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30038&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30038&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30038&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30038&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30038&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30038&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30038&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30038&r=mysqlcfg
#30028 [Opn->Csd]: stream_get_contents() doesn't respect the $maxlength
ID: 30028 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Network related Operating System: n/a PHP Version: 5CVS-2004-09-08 (dev) New Comment: Fixed by Sara. Previous Comments: [2004-09-08 18:25:55] [EMAIL PROTECTED] Description: It seems that stream_get_contents() isn't respecting the second paramether, limit. I think this only happen for http wrappers. Reproduce code: --- http://www.php.net/', 'r'); echo strlen(stream_get_contents($fp, 50)); fclose($fp); ?> Expected result: 50 Actual result: -- 30094 -- Edit this bug report at http://bugs.php.net/?id=30028&edit=1
#29131 [Com]: Compile fails on exif if mbstring is present
ID: 29131 Comment by: bt at addix dot net Reported By: james dot robinson at netregistry dot com dot au Status: Open Bug Type: Compile Failure Operating System: Debian Stable PHP Version: 5.0.0 Assigned To: moriyoshi New Comment: I am experiencing the same problem with php 5.0.1 on RedHat 9. I tried to compile it using gcc 3.3.3 with glibc 2.3.3. Previous Comments: [2004-08-18 20:36:25] smgallo at buffalo dot edu I am experiencing the same problem with php 5.0.1 on RedHat Enterprise 3 AS. [2004-08-18 20:36:23] smgallo at buffalo dot edu I am experiencing the same problem with php 5.0.1 on RedHat Enterprise 3 AS. [2004-07-18 18:35:49] itsdave101 at yahoo dot com I am also having the same problem although i am building an rpm on fedora core 1, i have successfully compiled an rpm without mbstring..' i dont personally need mbstring, but i was just trying to build an rpm with all the same options of the php4 rpm that comes with fedora., i can provide src rpm if anyone is interested. ./configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=i386-redhat-linux --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --cache-file=../config.cache --with-config-file-path=/etc --with-config-file-scan-dir=/etc/php.d --enable-force-cgi-redirect --disable-debug --enable-pic --disable-rpath --enable-inline-optimization --with-bz2 --with-db4=/usr --with-curl --with-exec-dir=/usr/bin --with-freetype-dir=/usr --with-png-dir=/usr --with-gd --enable-gd-native-ttf --with-gdbm --with-gettext --with-ncurses --with-gmp --with-iconv --with-jpeg-dir=/usr --with-openssl --with-png --with-pspell --with-regex=system --with-xml --with-expat-dir=/usr --with-dom=shared,/usr --with-dom-xslt=/usr --with-dom-exslt=/usr --with-xmlrpc=shared --with-pcre=/usr --with-zlib --with-layout=GNU --enable-bcmath --enable-exif --enable-ftp --enable-magic-quotes --enable-safe-mode --enable-sockets --enable-sysvsem --enable-sysvshm --enable-discard-path --enable-track-vars --enable-trans-sid --enable-yp --enable-wddx --without-oci8 --with-pear=/usr/share/pear --with-imap=shared --with-imap-ssl --with-kerberos --with-ldap=shared --with-mysql=shared,/usr --with-pgsql=shared --with-snmp=shared,/usr --with-snmp=shared --enable-ucd-snmp-hack --with-unixODBC=shared --enable-memory-limit --enable-bcmath --enable-shmop --enable-calendar --enable-dbx --enable-dio --enable-mcal --enable-mbstring --enable-force-cgi-redirect [2004-07-16 18:27:18] sheltren at cs dot ucsb dot edu I receive the same error during compile on Fedora Core 2. I can paste the configure options if needed, although, like the initial report, configure exited cleanly without reporting any errors. [2004-07-14 03:46:05] james dot robinson at netregistry dot com dot au Description: Compile fails with the following: gcc -Iext/exif/ -I/usr/src/php/php-5.0.0/ext/exif/ -DPHP_ATOM_INC -I/usr/src/php/php-5.0.0/include -I/usr/src/php/php-5.0.0/main -I/usr/src/php/php-5.0.0 -I/usr/local/include -I/usr/src/php/php-5.0.0/Zend -I/usr/include/libxml2 -I/usr/X11R6/include -I/usr/include/freetype2 -I/usr/include/c-client -I/usr/src/php/php-5.0.0/ext/mbstring/oniguruma -I/usr/src/php/php-5.0.0/ext/mbstring/libmbfl -I/usr/src/php/php-5.0.0/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql -I/usr/include/postgresql -I/usr/src/php/php-5.0.0/TSRM -g -O2 -c /usr/src/php/php-5.0.0/ext/exif/exif.c -o ext/exif/exif.o && echo > ext/exif/exif.lo In file included from /usr/src/php/php-5.0.0/ext/mbstring/php_mbregex.h:28, from /usr/src/php/php-5.0.0/ext/mbstring/mbstring.h:77, from /usr/src/php/php-5.0.0/ext/exif/exif.c:76: /usr/src/php/php-5.0.0/ext/mbstring/oniguruma/oniguruma.h:573: redefinition of `struct re_registers' make: *** [ext/exif/exif.lo] Error 1 Configure: ./configure \ --prefix=/usr/local/php-5.0.0 \ --with-regex=system \ --enable-calendar \ --with-iodbc \ --with-dom \ --with-curl \ --with-openssl \ --with-iconv \ --enable-filepro \ --enable-ftp \ --with-gettext \ --enable-sysvsem \ --enable-sysvshm \ --disable-debug \ --with-gd \ --with-imap=/usr \ --with-ldap=/usr \ --with-mm=/usr \ --with-mysql=/usr \ --with-pcre-regex=/usr \ --with-pgsql=/usr \ --enable-sockets \ --with-zlib \ --enable-memory-limit \ --enable-fastcgi \ --with-pear \ --enable-mbstring \ --enable-shmo
#30036 [NEW]: In_Array not works when array contain booleans
From: marek at lewczuk dot com
Operating system: Windows
PHP version: 4.3.8
PHP Bug Type: Arrays related
Bug description: In_Array not works when array contain booleans
Description:
When you have an array with boolean values, then in_array will always
return true.
Reproduce code:
---
print in_array("test it", array(true, true, "sdsd" => true))
Expected result:
should return false
Actual result:
--
true
--
Edit bug report at http://bugs.php.net/?id=30036&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30036&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30036&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30036&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30036&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30036&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30036&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30036&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30036&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30036&r=support
Expected behavior: http://bugs.php.net/fix.php?id=30036&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30036&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30036&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30036&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30036&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30036&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30036&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30036&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30036&r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30036&r=mysqlcfg
#30019 [Bgs]: $_SERVER['HTTP_REFERER']; doesn't always display
ID: 30019 Updated by: [EMAIL PROTECTED] Reported By: asfsm at uaa dot alaska dot edu Status: Bogus Bug Type: *General Issues Operating System: Windows 2003 (standard) PHP Version: 5.0.1 New Comment: Especially if the cache is cleared and the page reloaded. Do you understand what the referrer actually means? It is the URL that a user clicked on a link to get to your page. If the user simply types in the url or does a reload, there will be no referrer in the request. This isn't a browser "issue", this is simply how the Web works. Previous Comments: [2004-09-08 20:59:11] asfsm at uaa dot alaska dot edu Even if the cache is cleared and the page is reloaded? this is a browser issue? [2004-09-08 06:04:33] [EMAIL PROTECTED] Because clients don't always send the referrer. No bug here. PHP will have it if the client provides it, otherwise it won't. [2004-09-08 00:27:34] asfsm at uaa dot alaska dot edu Description: $_SERVER['HTTP_REFERER']; doesn't always display It displays occassionally, but not all the time. Reproduce code: --- Expected result: Actual result: -- -- Edit this bug report at http://bugs.php.net/?id=30019&edit=1
