Bug #52435 [Opn->Bgs]: the bug has kept me from earning my bonus please fix and pay me my 1 million fa
Edit report at http://bugs.php.net/bug.php?id=52435&edit=1 ID: 52435 Updated by: dtajchre...@php.net Reported by: dh123lh1 at hotmail dot com Summary: the bug has kept me from earning my bonus please fix and pay me my 1 million fa -Status: Open +Status: Bogus Type: Bug Package: *General Issues Operating System: windows 7 home premium Home thea PHP Version: Irrelevant New Comment: All your coin are belong to us Previous Comments: [2010-07-25 06:21:01] dh123lh1 at hotmail dot com Description: where its supposed to pay off the farmvill Iqtest and tell me my resultsI got this instead of my million farmville coins, i have done this Iq test please pay my million coins in facebooks farmville http://www.quizulous.com/toolbar/newaccount/conduit mysql_connect() [function.mysql-connect]: Host '74.53.23.135' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts' Test script: --- I didnt write this Expected result: you get your client quizloos to have farmville pay my million coins Actual result: -- stack trace from the page it brought up rather than my reward mysql_connect() [function.mysql-connect]: Host '74.53.23.135' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts' -- Edit this bug report at http://bugs.php.net/bug.php?id=52435&edit=1
[PHP-BUG] Bug #52436 [NEW]: Compile error if systems do not have stdint.h
From: Operating system: Solaris8 PHP version: 5.2.14 Package: Compile Failure Bug Type: Bug Bug description:Compile error if systems do not have stdint.h Description: $ ./configure ã»ã»ã» $ grep -i stdint main/php_config.h /* Define if you have the header file. */ /* #undef HAVE_STDINT_H */ $ make ã»ã»ã» /bin/ksh /tmp/php-5.2.14/libtool --silent --preserve-dup-deps --mode=compile gcc -I/tmp/php-5.2.14/ext/pcre/pcrelib -Iext/pcre/ -I/tmp/php-5.2.14/ext/pcre/ -DPHP_ATOM_INC -I/tmp/php-5.2.14/include -I/tmp/php-5.2.14/main -I/tmp/php-5.2.14 -I/tmp/php-5.2.14/ext/date/lib -I/usr/include/libxml2 -I/tmp/php-5.2.14/TSRM -I/tmp/php-5.2.14/Zend -D_POSIX_PTHREAD_SEMANTICS -I/usr/include -g -O2 -c /tmp/php-5.2.14/ext/pcre/pcrelib/pcre_chartables.c -o ext/pcre/pcrelib/pcre_chartables.lo In file included from /tmp/php-5.2.14/ext/pcre/pcrelib/pcre_chartables.c:25: /tmp/php-5.2.14/ext/pcre/pcrelib/pcre_internal.h:198:20: stdint.h: No such file or directory make: *** [ext/pcre/pcrelib/pcre_chartables.lo] Error 1 -- Edit bug report at http://bugs.php.net/bug.php?id=52436&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52436&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52436&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52436&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52436&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52436&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52436&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52436&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52436&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52436&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52436&r=support Expected behavior: http://bugs.php.net/fix.php?id=52436&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52436&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52436&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52436&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52436&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52436&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52436&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52436&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52436&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52436&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52436&r=mysqlcfg
Bug #52434 [Opn->Bgs]: mysqlnd: host cannot be a hostname
Edit report at http://bugs.php.net/bug.php?id=52434&edit=1 ID: 52434 Updated by: dtajchre...@php.net Reported by: anthon dot pang at gmail dot com Summary: mysqlnd: host cannot be a hostname -Status: Open +Status: Bogus Type: Bug Package: MySQL related Operating System: Ubuntu 10.04 PHP Version: 5.3.3 New Comment: Tell PHP where your mysql.sock file is via the DSN or pdo_mysql.default_socket in the php.ini file and your error will go away. Your conclusion is way off. http://www.php.net/manual/en/ref.pdo-mysql.connection.php Previous Comments: [2010-07-25 04:42:45] anthon dot pang at gmail dot com Description: With PDO_MYSQL, if PHP is linked with mysql client libraries (instead of mysqlnd), the DSN can contain a host parameter with a hostname, e.g., host=localhost. However, with mysqlnd, the host has to be an ip address, e.g., host=127.0.0.1. This occurs for '--with-mysqli=mysqlnd' or '--with-pdo-mysql=mysqlnd'. It appears mysqlnd wants to use a Unix socket even though the port is explictly specified, This backward incompatibility surprises users migrating from php 5.2.x and find their apps suddenly can't connect. MySQL 5.1.41 Test script: --- >From Zend Framework 1.10.6: $_isConnected = @mysqli_real_connect( $this->_connection, $this->_config['host'], $this->_config['username'], $this->_config['password'], $this->_config['dbname'], $port ); Expected result: Expect it to connect. Actual result: -- Warning: PDO::__construct() [pdo.--construct]: [2002] No such file or directory (trying to connect via unix:///tmp/mysql.sock) in /var/www/libs/Zend/Db/Adapter/Pdo/Abstract.php on line 129 SQLSTATE[HY000] [2002] No such file or directory -- Edit this bug report at http://bugs.php.net/bug.php?id=52434&edit=1
[PHP-BUG] Bug #52435 [NEW]: the bug has kept me from earning my bonus please fix and pay me my 1 million fa
From: Operating system: windows 7 home premium Home thea PHP version: Irrelevant Package: *General Issues Bug Type: Bug Bug description:the bug has kept me from earning my bonus please fix and pay me my 1 million fa Description: where its supposed to pay off the farmvill Iqtest and tell me my resultsI got this instead of my million farmville coins, i have done this Iq test please pay my million coins in facebooks farmville http://www.quizulous.com/toolbar/newaccount/conduit mysql_connect() [function.mysql-connect]: Host '74.53.23.135' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts' Test script: --- I didnt write this Expected result: you get your client quizloos to have farmville pay my million coins Actual result: -- stack trace from the page it brought up rather than my reward mysql_connect() [function.mysql-connect]: Host '74.53.23.135' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts' -- Edit bug report at http://bugs.php.net/bug.php?id=52435&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52435&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52435&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52435&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52435&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52435&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52435&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52435&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52435&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52435&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52435&r=support Expected behavior: http://bugs.php.net/fix.php?id=52435&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52435&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52435&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52435&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52435&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52435&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52435&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52435&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52435&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52435&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52435&r=mysqlcfg
[PHP-BUG] Bug #52434 [NEW]: mysqlnd: host cannot be a hostname
From: Operating system: Ubuntu 10.04 PHP version: 5.3.3 Package: MySQL related Bug Type: Bug Bug description:mysqlnd: host cannot be a hostname Description: With PDO_MYSQL, if PHP is linked with mysql client libraries (instead of mysqlnd), the DSN can contain a host parameter with a hostname, e.g., host=localhost. However, with mysqlnd, the host has to be an ip address, e.g., host=127.0.0.1. This occurs for '--with-mysqli=mysqlnd' or '--with-pdo-mysql=mysqlnd'. It appears mysqlnd wants to use a Unix socket even though the port is explictly specified, This backward incompatibility surprises users migrating from php 5.2.x and find their apps suddenly can't connect. MySQL 5.1.41 Test script: --- >From Zend Framework 1.10.6: $_isConnected = @mysqli_real_connect( $this->_connection, $this->_config['host'], $this->_config['username'], $this->_config['password'], $this->_config['dbname'], $port ); Expected result: Expect it to connect. Actual result: -- Warning: PDO::__construct() [pdo.--construct]: [2002] No such file or directory (trying to connect via unix:///tmp/mysql.sock) in /var/www/libs/Zend/Db/Adapter/Pdo/Abstract.php on line 129 SQLSTATE[HY000] [2002] No such file or directory -- Edit bug report at http://bugs.php.net/bug.php?id=52434&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52434&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52434&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52434&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52434&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52434&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52434&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52434&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52434&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52434&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52434&r=support Expected behavior: http://bugs.php.net/fix.php?id=52434&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52434&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52434&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52434&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52434&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52434&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52434&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52434&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52434&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52434&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52434&r=mysqlcfg
[PHP-BUG] Bug #52433 [NEW]: Call to undefined method mysqli::poll()
From:
Operating system: Debian 5
PHP version: 5.3.3
Package: MySQLi related
Bug Type: Bug
Bug description:Call to undefined method mysqli::poll()
Description:
The static method mysqli::poll doesn't exist. Using it creates a Fatal
error: Call
to undefined method mysqli::poll() .
mysqli_poll works fine.
Test script:
---
query("SELECT 'test'", MYSQLI_ASYNC);
$done=false;
do
{
$links = $errors = $reject = array();
$links[] = $errors[] = $reject[] = $link1;
if (!mysqli::poll($links, $errors, $reject, 1)) {
continue;
}
if ($result = $links[0]->reap_async_query()) {
$done=true;
}
}
while(!$done);
Expected result:
No output.
Actual result:
--
Fatal error: Call to undefined method mysqli::poll()
--
Edit bug report at http://bugs.php.net/bug.php?id=52433&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52433&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52433&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52433&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52433&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52433&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52433&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52433&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52433&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52433&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52433&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52433&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52433&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52433&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52433&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52433&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52433&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52433&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52433&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52433&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52433&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52433&r=mysqlcfg
Bug #46311 [Com]: Pointer aliasing issue results in miscompile on gcc4.4
Edit report at http://bugs.php.net/bug.php?id=46311&edit=1
ID: 46311
Comment by: mabi at gentoo dot org
Reported by: anton at samba dot org
Summary: Pointer aliasing issue results in miscompile on gcc4.4
Status: Assigned
Type: Bug
Package: Compile Failure
Operating System: RHEL5.2 / PowerPC64
PHP Version: 5.2.9
Assigned To: dmitry
New Comment:
There are Gentoo downstream bugs related to this issue:
https://bugs.gentoo.org/show_bug.cgi?id=295682
https://bugs.gentoo.org/show_bug.cgi?id=329753
I'd love to see this fixed upstream, but will ship a custom patch to get
this more testing shortly.
Previous Comments:
[2008-10-16 09:35:17] johan...@php.net
Dmitry, can you check this?
[2008-10-16 05:54:12] anton at samba dot org
To clarify... the Zend code reads via zval *, not long *. The cut down
test case I submitted was simplified to use a long *.
[2008-10-16 03:20:35] anton at samba dot org
I can't work out how to attach things in this tool. Here is a copy and
paste of it and a non whitespace damaged version can be found at:
http://ozlabs.org/~anton/junkcode/php_fix_aliasing.patch
Index: php-5.2.6/Zend/zend_execute.h
===
--- php-5.2.6.orig/Zend/zend_execute.h 2007-12-31 02:20:02.0
-0500
+++ php-5.2.6/Zend/zend_execute.h 2008-10-15 23:03:01.0
-0400
@@ -150,7 +150,7 @@
EG(argument_stack).top -= (delete_count+2);
while (--delete_count>=0) {
- zval *q = *(zval **)(--p);
+ zval *q = *(--p);
*p = NULL;
zval_ptr_dtor(&q);
}
[2008-10-16 03:16:05] anton at samba dot org
Description:
A recent checkout of gcc4.4 miscompiles php on PowerPC64. The following
function reads from p via long * and stores to p via void * which
violates aliasing rules:
static inline void zend_ptr_stack_clear_multiple(TSRMLS_D)
{
void **p = EG(argument_stack).top_element-2;
int delete_count = (int)(zend_uintptr_t) *p;
EG(argument_stack).top -= (delete_count+2);
while (--delete_count>=0) {
zval *q = *(zval **)(--p);
*p = NULL;
zval_ptr_dtor(&q);
}
EG(argument_stack).top_element = p;
}
More details can be found at:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37824
We can remove the (zval **) cast so that we read and write via void *p
and fix the aliasing issue. I will attach a patch.
--
Edit this bug report at http://bugs.php.net/bug.php?id=46311&edit=1
[PHP-BUG] Req #52432 [NEW]: {} with Return Value
From:
Operating system: Irrelevant
PHP version: Irrelevant
Package: Scripting Engine problem
Bug Type: Feature/Change Request
Bug description:{} with Return Value
Description:
It would be pretty cool if you were able to use { CodeHere; } as
Statement.
The Basic Idea behind this is like if the Code was a Function that had a
Return
Statement. Its only a little inefficient because the Function might only be
used
one Time, which means it would be useful to have such a Feature.
Examples are given in the TestScript
Test script:
---
Expected result:
1. Depending on the Time echoing 'It equals to True';
2. When mysql_connect returns false that it evaluates the {}-Code
3. $a = 16;
Actual result:
--
Parse Error of course
--
Edit bug report at http://bugs.php.net/bug.php?id=52432&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52432&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52432&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52432&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52432&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52432&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52432&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52432&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52432&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52432&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52432&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52432&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52432&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52432&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52432&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52432&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52432&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52432&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52432&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52432&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52432&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52432&r=mysqlcfg
Req #33604 [Com]: MYSQL: php.ini option to set character_set and allow using UTF8
Edit report at http://bugs.php.net/bug.php?id=33604&edit=1 ID: 33604 Comment by: mabi at gentoo dot org Reported by: dlacroix at erasme dot org Summary: MYSQL: php.ini option to set character_set and allow using UTF8 Status: Open Type:Feature/Change Request Package: Feature/Change Request PHP Version: 5.0.4 New Comment: Just attached the patch gentoo currently ships for this. In short: it provides a mysql.connect_charset php.ini option and uses mysql_options so that each connection will have this charset set by default. We use a similar patch for mysqli. The patch is not mine (I just adapted it to work with php-5.3.3), the original credits are: Initial patch by Stuart (?) and CHTEKK Updated for 5.3 by hoffie Previous Comments: [2005-07-07 15:43:00] dlacroix at erasme dot org Description: There is no option in php.ini to setup the character set used with the MySQL connection. I'm using PHP in UTF-8 per default, MySQL 4.1.11 in UTF-8 but when I open a connection with PHP-MySQL it use latin1. I need an option to set the character set to UTF-8 when a connection is opened like in my.cnf file for mysql client. I have written a patch for php-mysql-5.0.4. It add mysql.default_character_set variable. Like that you can set: mysql.default_character_set = utf8 I still have a problem with mysql_client_encoding function that return latin1 even if the database is well using UTF-8. But it seems to be a MySQL client problem. Without this patch PHP program like SPIP are missusing the database and thing can be double encoded in UTF-8. This patch just add the following MySQL command when a connection is opened: SET character_set_client=choosed value SET character_set_connection=choosed value SET character_set_results=choosed value Reproduce code: --- Patch is available here: http://index.erasme.org/php-5.0.4-mysql-characterset.patch else you can ask me (dlacr...@erasme.org) -- Edit this bug report at http://bugs.php.net/bug.php?id=33604&edit=1
Bug #52424 [Com]: Function naming inconsistency: htmlentities() x html_entity_decode()
Edit report at http://bugs.php.net/bug.php?id=52424&edit=1 ID: 52424 Comment by: giorgio dot liscio at email dot it Reported by: php-bugs at majkl578 dot cz Summary: Function naming inconsistency: htmlentities() x html_entity_decode() Status: Open Type:Bug Package: Unknown/Other Function PHP Version: 5.3.3 New Comment: php functions uses a lot of different syntax isset is_array isPublic but aliasing is evil and renaming is not appreciated by users... the best thing you can do is implement your renamed function in your namespace bye Previous Comments: [2010-07-24 07:11:06] php-bugs at majkl578 dot cz Description: I suggest adding a function htmlentities_decode() as a replacement for html_entity_decode() and possibly deprecate that one. It is really misleading and unintuitive because there are functions htmlspecialchars() and htmlspecialchars_decode() doing similar thing. -- Edit this bug report at http://bugs.php.net/bug.php?id=52424&edit=1
[PHP-BUG] Bug #52430 [NEW]: date_parse parse 24:xx:xx as valid time
From: Operating system: Win 7 PHP version: 5.3.3 Package: Date/time related Bug Type: Bug Bug description:date_parse parse 24:xx:xx as valid time Description: In the 24-hour time notation, the day begins at midnight, 00:00, and the last minute of the day begins at 23:59. Date_parse function returns no warning and no error when any time starting with hour "24" is used as parameter. But some error is expected, because 2010-1-1 24:59:59 is NOT valid date. This can cause serious errors in scripts that use date_parse for validating dateTime strings. Test script: --- Expected result: Array ( [year] => 2010 [month] => 1 [day] => 1 [hour] => 0 [minute] => 0 [second] => 0 [fraction] => 0 [warning_count] => 0 [warnings] => Array ( ) [error_count] => 1 [errors] => Array ([9]=>'Unexpected character') [is_localtime] =>false ) Actual result: -- Array ( [year] => 2010 [month] => 1 [day] => 1 [hour] => 24 <= wrong [minute] => 0 [second] => 0 [fraction] => 0 [warning_count] => 0 [warnings] => Array ( ) [error_count] => 0 <= wrong [errors] => Array ( ) <= wrong [is_localtime] =>false ) -- Edit bug report at http://bugs.php.net/bug.php?id=52430&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52430&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52430&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52430&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52430&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52430&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52430&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52430&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52430&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52430&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52430&r=support Expected behavior: http://bugs.php.net/fix.php?id=52430&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52430&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52430&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52430&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52430&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52430&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52430&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52430&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52430&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52430&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52430&r=mysqlcfg
Bug #46722 [Bgs]: libmysql version 5.1.30 causes PHP crash
Edit report at http://bugs.php.net/bug.php?id=46722&edit=1 ID: 46722 Updated by: paj...@php.net Reported by: bentogoa at gmail dot com Summary: libmysql version 5.1.30 causes PHP crash Status: Bogus Type: Bug Package: MySQL related Operating System: Windows XP PHP Version: 5.2.6 New Comment: This bug is the exact reason why we don't support mysql's libmysql. They keep breaking ABI and the CRT incompatibilities will cause way too much troubles to be used safely, even only for development. Previous Comments: [2010-07-24 19:33:59] neo_in_matrix at msn dot com The libmysql.dll bundled with php package is 5.0.51a. I want to use the latest version (which is 5.1.48 as of writing this comment), but the simplest mysql call ended up with the following error: --- php.exe - Application Error --- The instruction at "0x1000ac5a" referenced memory at "0x0014". The memory could not be "read". Click on OK to terminate the program Click on CANCEL to debug the program --- OK Cancel --- There is no reason that you refuse users to use newer version of libmysql. Can you just update the dll? [2008-12-01 03:46:03] bentogoa at gmail dot com so where can libmysql.dll 5.1.30 be downloaded ? [2008-11-30 17:06:07] paj...@php.net Do not use any mysql DLL but the ones we provide with PHP releases. [2008-11-30 15:15:58] bentogoa at gmail dot com Description: Upgrading libmysql.dll 5.0.51a (the one in php 5.2.6 package) to libmysql.dll 5.1.30 (from the latest version of Mysql)causes php to crash. Tried by php CLI = php proccess ends via Apache2.2.10 Web Server = The Apache server crashes. Reproduce code: --- Expected result: print Connected successfully; Actual result: -- No Response, The Servers crashes. -- Edit this bug report at http://bugs.php.net/bug.php?id=46722&edit=1
Bug #52429 [Bgs->Fbk]: date_default_timezone error
Edit report at http://bugs.php.net/bug.php?id=52429&edit=1 ID: 52429 Updated by: dtajchre...@php.net Reported by: patrice dot flahault at accessprinting dot fr Summary: date_default_timezone error -Status: Bogus +Status: Feedback Type: Bug Package: Date/time related Operating System: centos 5.5 PHP Version: 5.3.3 Previous Comments: [2010-07-24 20:30:23] dtajchre...@php.net Looks fine to me.. [da...@lyon ~]$ php t.php int(1279996161) string(25) "2010-07-24T20:29:21+02:00" [da...@lyon ~]$ cat t.php http://bugs.php.net/bug.php?id=52429&edit=1
Bug #52429 [Fbk->Bgs]: date_default_timezone error
Edit report at http://bugs.php.net/bug.php?id=52429&edit=1 ID: 52429 Updated by: dtajchre...@php.net Reported by: patrice dot flahault at accessprinting dot fr Summary: date_default_timezone error -Status: Feedback +Status: Bogus Type: Bug Package: Date/time related Operating System: centos 5.5 PHP Version: 5.3.3 New Comment: Looks fine to me.. [da...@lyon ~]$ php t.php int(1279996161) string(25) "2010-07-24T20:29:21+02:00" [da...@lyon ~]$ cat t.php http://bugs.php.net/bug.php?id=52429&edit=1
Bug #46722 [Com]: libmysql version 5.1.30 causes PHP crash
Edit report at http://bugs.php.net/bug.php?id=46722&edit=1 ID: 46722 Comment by: neo_in_matrix at msn dot com Reported by: bentogoa at gmail dot com Summary: libmysql version 5.1.30 causes PHP crash Status: Bogus Type: Bug Package: MySQL related Operating System: Windows XP PHP Version: 5.2.6 New Comment: The libmysql.dll bundled with php package is 5.0.51a. I want to use the latest version (which is 5.1.48 as of writing this comment), but the simplest mysql call ended up with the following error: --- php.exe - Application Error --- The instruction at "0x1000ac5a" referenced memory at "0x0014". The memory could not be "read". Click on OK to terminate the program Click on CANCEL to debug the program --- OK Cancel --- There is no reason that you refuse users to use newer version of libmysql. Can you just update the dll? Previous Comments: [2008-12-01 03:46:03] bentogoa at gmail dot com so where can libmysql.dll 5.1.30 be downloaded ? [2008-11-30 17:06:07] paj...@php.net Do not use any mysql DLL but the ones we provide with PHP releases. [2008-11-30 15:15:58] bentogoa at gmail dot com Description: Upgrading libmysql.dll 5.0.51a (the one in php 5.2.6 package) to libmysql.dll 5.1.30 (from the latest version of Mysql)causes php to crash. Tried by php CLI = php proccess ends via Apache2.2.10 Web Server = The Apache server crashes. Reproduce code: --- Expected result: print Connected successfully; Actual result: -- No Response, The Servers crashes. -- Edit this bug report at http://bugs.php.net/bug.php?id=46722&edit=1
Bug #37350 [Bgs->Csd]: realpath() doesn't canonicalize case on Windows
Edit report at http://bugs.php.net/bug.php?id=37350&edit=1
ID: 37350
Updated by: paj...@php.net
Reported by: k95vz5f02 at sneakemail dot com
Summary: realpath() doesn't canonicalize case on Windows
-Status: Bogus
+Status: Closed
Type: Bug
Package: Filesystem function related
Operating System: Windows XP SP2
PHP Version: 5.1.4
-Assigned To:
+Assigned To: pajoye
Previous Comments:
[2010-07-24 15:51:46] jah at jahboite dot co dot uk
Having examined CWD_API int virtual_file_ex I realise that I'm an idiot
and you should disregard my previous comment. realpath is returning the
canonicalised path:
C:\WINDOWS\system32\cmd.exe
I should have checked my bloody filesystem!
[2010-07-24 00:03:16] jah at jahboite dot co dot uk
I don't think this issue is quite fixed yet.
php.exe -r "echo realpath('C:\WINDOWS\System32\cmd.exe');"
Expected result:
C:\WINDOWS\System32\cmd.exe
Actual result:
--
C:\WINDOWS\system32\cmd.exe
System32 -> system32
This is with the PHP 5.2.14 windows binary on Windows XP SP3.
[2006-09-26 23:45:01] k95vz5f02 at sneakemail dot com
Perfect, thanks for fixing this.
Tests done to verify, using the windows version linked to above [PHP
5.2.0RC5-dev (cli) (built: Sep 27 2006 00:22:40)]:
realpath("C:\\Program Files") => C:\Program Files
realpath("c:\\PrOgRaM fIlEs") => C:\Program Files
realpath("C:\\program files\\") => C:\Program Files
realpath("C:/program files/") => C:\Program Files
realpath("C:\\pRoGrA~1")=> C:\Program Files
realpath("c:\\windows") => C:\WINDOWS
realpath("c:\\wInDoWs\\DoWnLoAdEd PrOgRaM fIlEs\\") =>
C:\WINDOWS\Downloaded Program Files
[2006-09-26 22:18:42] tony2...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-06-23 17:19:53] k95vz5f02 at sneakemail dot com
On further investigation, realpath doesn't consistently canonicalize the
case at all on Windows, I've updated the summary accordingly.
First to remember the need for this: the documentation definition for
realpath is "Returns canonicalized absolute pathname", and Wikipedia
defines canonicalization as
"Canonicalization (abbreviated c14n) is the process of converting data
that has more than one possible representation into a "standard"
canonical representation. This can be done to compare different
representations for equivalence (...)"
So clearly case should be converted to a standard form on platforms such
as Windows that are case-insensitive, and indeed Windows stores the
preferred case for every file, for example the standard directory
'C:\Program Files' should be capitalised like that, rather than, e.g.
'C:\program files' or 'C:\PROGRAM FILES', whereas 'C:\WINDOWS' is the
preferred case for that directory (on Win XP at least).
Tests:
1. realpath("C:\\Program Files") => C:\Program Files
2. realpath("c:\\PrOgRaM fIlEs") => c:\PrOgRaM fIlEs
3. realpath("C:\\program files\\") => C:\program files
4. realpath("C:/program files/") => C:\program files
5. realpath("C:\\pRoGrA~1")=> C:\Program Files
6. realpath("c:\\windows") => c:\WINDOWS
7. realpath("c:\\wInDoWs\\DoWnLoAdEd PrOgRaM fIlEs\\") =>
c:\WINDOWS\DoWnLoAdEd PrOgRaM fIlEs
Conclusion:
realpath deals with slashes consistently, but it only canonicalizes the
case of short filenames (as well as expanding them), not long file names
(anything more than 8.3, or with a space, etc); and it never capitalizes
the drive letter as it should.
A possible solution, if slightly inefficient, would be to convert path
components into short (8.3) form then apply the normal realpath logic.
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/bug.php?id=37350
--
Edit this bug report at http://bugs.php.net/bug.php?id=37350&edit=1
Bug #52429 [Opn->Fbk]: date_default_timezone error
Edit report at http://bugs.php.net/bug.php?id=52429&edit=1 ID: 52429 Updated by: ras...@php.net Reported by: patrice dot flahault at accessprinting dot fr Summary: date_default_timezone error -Status: Open +Status: Feedback Type: Bug Package: Date/time related Operating System: centos 5.5 PHP Version: 5.3.3 New Comment: Are you sure you haven't done something else wrong? I just fired up a Centos VM and tried it: http://bugs.php.net/bug.php?id=52429&edit=1
[PHP-BUG] Bug #52429 [NEW]: date_default_timezone error
From:
Operating system: centos 5.5
PHP version: 5.3.3
Package: Date/time related
Bug Type: Bug
Bug description:date_default_timezone error
Description:
The time zone Europe/Paris gives a wrong time.
date_default_timezone_set('Europe/Paris');
should be the same as :
date_default_timezone_set('Europe/Madrid');
but there is a 6 hour difference.
--
Edit bug report at http://bugs.php.net/bug.php?id=52429&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52429&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52429&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52429&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52429&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52429&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52429&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52429&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52429&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52429&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52429&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52429&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52429&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52429&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52429&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52429&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52429&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52429&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52429&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52429&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52429&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52429&r=mysqlcfg
Req #52425 [Opn->Wfx]: array_shift/array_pop: add parameter that tells how many to elements to pop
Edit report at http://bugs.php.net/bug.php?id=52425&edit=1
ID: 52425
Updated by: dtajchre...@php.net
Reported by: planet36 at gmail dot com
Summary: array_shift/array_pop: add parameter that tells how
many to elements to pop
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
Package: Unknown/Other Function
Operating System: Linux
PHP Version: 5.3.3
New Comment:
array_splice()
Previous Comments:
[2010-07-24 08:07:26] planet36 at gmail dot com
Description:
Description:
It would be nice if functions array_pop and array_shift took a parameter
that told how many elements to pop.
Example:
mixed array_pop ( array &$array , $num = 1 )
mixed array_shift ( array &$array , $num = 1 )
Test script:
---
function array_pop_mine(array &$array, $num)
{
$removed = array();
while ($num > 0)
{
//$removed[] = array_pop($array);
array_unshift($removed, array_pop($array));
--$num;
}
//return array_reverse($removed);
return $removed;
}
$arr = array(3, 1, 4, 1, 5, 9);
print_r($arr);
$rem = array_pop_mine($arr, 3);
print_r($arr);
print_r($rem);
Actual result:
--
Array
(
[0] => 3
[1] => 1
[2] => 4
[3] => 1
[4] => 5
[5] => 9
)
Array
(
[0] => 3
[1] => 1
[2] => 4
)
Array
(
[0] => 1
[1] => 5
[2] => 9
)
--
Edit this bug report at http://bugs.php.net/bug.php?id=52425&edit=1
Bug #51216 [Com]: Segmentation fault when compiling PHP with PHAR
Edit report at http://bugs.php.net/bug.php?id=51216&edit=1 ID: 51216 Comment by: sneakyimp at hotmail dot com Reported by: dtm2mcs at gmail dot com Summary: Segmentation fault when compiling PHP with PHAR Status: Bogus Type: Bug Package: PHAR related Operating System: Ubuntu 6.04 + CentOS 5.4 PHP Version: 5.3.2 New Comment: I can also confirm this problem on Mac OSX 10.5.8 with php source for 5.3.2. I'm compiling with --enable-maintainer-zts because I want to work on a php extension. Generating phar.php /bin/sh: line 1: 61359 Segmentation fault ` if test -x "/Users/christopherwalsh/src/php-5.3.2/sapi/cli/php"; then /Users/christopherwalsh/src/php-5.3.2/build/shtool echo -n -- "/Users/christopherwalsh/src/php-5.3.2/sapi/cli/php -n"; if test "x" != "x"; then /Users/christopherwalsh/src/php-5.3.2/build/shtool echo -n -- " -d extension_dir=/Users/christopherwalsh/src/php-5.3.2/modules"; for i in bz2 zlib phar; do if test -f "/Users/christopherwalsh/src/php-5.3.2/modules/$i.la"; then . /Users/christopherwalsh/src/php-5.3.2/modules/$i.la; /Users/christopherwalsh/src/php-5.3.2/build/shtool echo -n -- " -d extension=$dlname"; fi; done; fi; else /Users/christopherwalsh/src/php-5.3.2/build/shtool echo -n -- "/Users/christopherwalsh/src/php-5.3.2/sapi/cli/php"; fi;` -d 'open_basedir=' -d 'output_buffering=0' -d 'memory_limit=-1' -d phar.readonly=0 -d 'safe_mode=0' /Users/christopherwalsh/src/php-5.3.2/ext/phar/build_precommand.php > ext/phar/phar.php make: *** [ext/phar/phar.php] Error 139 Previous Comments: [2010-07-14 20:08:40] srina...@php.net closing it as not reproducible with latest release (5.3.3) [2010-07-14 04:51:15] ywliu at hotmail dot com Just tried 5.3.3RC2. This problem on the latest CentOS 5.5 is gone. [2010-07-13 23:01:20] srina...@php.net please see if this issue can be reproduced with php 5.3.3 (RC2)- http://qa.php.net/ and if yes, please provide us a stack trace as mentioned here. http://bugs.php.net/bugs-generating-backtrace.php [2010-07-08 17:00:24] bluefox012 at gmail dot com centos 5.4 have the same problem, [activating module `php5' in /home/services/web/config/httpd.conf] Installing PHP CLI binary:/usr/local/php/bin/ Installing PHP CLI man page: /usr/local/php/man/man1/ Installing build environment: /usr/local/php/lib/php/build/ Installing header files: /usr/local/php/include/php/ Installing helper programs: /usr/local/php/bin/ program: phpize program: php-config Installing man pages: /usr/local/php/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /usr/local/php/lib/php/ make[1]: *** [install-pear-installer] Segmentation fault make: *** [install-pear] Error 2 [2010-05-08 00:54:01] leonard dot f dot elia at nasa dot gov So, I tried compiling without phar: ./configure --prefix=/usr/local/php532-dist \ --with-curl=/usr/local --enable-exif --with-gd \ --with-nsapi=/usr/local/iplanet7 \ --with-mysql=/usr/local/mysql-client/mysql-5.1.40 \ --with-mysqli=/usr/local/mysql/bin/mysql_config \ --with-oci8=instantclient,/usr/local/oracle \ --with-pdo-mysql=/usr/local/mysql-client/mysql-5.1.40 \ --with-pdo-oci=/usr/local/oracle \ --with-jpeg-dir=/usr/local --with-png-dir=/usr/local \ --enable-libgcc \ --disable-phar The make now completes as expected but make install now throws up: [r...@allegro php5]# make install Installing PHP SAPI module: nsapi Installing PHP CLI binary:/usr/local/php532-dist/bin/ Installing PHP CLI man page: /usr/local/php532-dist/man/man1/ Installing build environment: /usr/local/php532-dist/lib/php/build/ Installing header files: /usr/local/php532-dist/include/php/ Installing helper programs: /usr/local/php532-dist/bin/ program: phpize program: php-config Installing man pages: /usr/local/php532-dist/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /usr/local/php532-dist/lib/php/ Segmentation Fault make[1]: *** [install-pear-installer] Error 139 make: *** [install-pear] Error 2 And this bug, my friends, isn't in the bug database (that I have found). Any ideas? My system has a working php in the path (5.3.1) and is up to date on patches etc. 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/bug.php?id=51216 --
Bug #37350 [Csd->Bgs]: realpath() doesn't canonicalize case on Windows
Edit report at http://bugs.php.net/bug.php?id=37350&edit=1
ID: 37350
Updated by: paj...@php.net
Reported by: k95vz5f02 at sneakemail dot com
Summary: realpath() doesn't canonicalize case on Windows
-Status: Closed
+Status: Bogus
Type: Bug
Package: Filesystem function related
Operating System: Windows XP SP2
PHP Version: 5.1.4
Previous Comments:
[2010-07-24 15:51:46] jah at jahboite dot co dot uk
Having examined CWD_API int virtual_file_ex I realise that I'm an idiot
and you should disregard my previous comment. realpath is returning the
canonicalised path:
C:\WINDOWS\system32\cmd.exe
I should have checked my bloody filesystem!
[2010-07-24 00:03:16] jah at jahboite dot co dot uk
I don't think this issue is quite fixed yet.
php.exe -r "echo realpath('C:\WINDOWS\System32\cmd.exe');"
Expected result:
C:\WINDOWS\System32\cmd.exe
Actual result:
--
C:\WINDOWS\system32\cmd.exe
System32 -> system32
This is with the PHP 5.2.14 windows binary on Windows XP SP3.
[2006-09-26 23:45:01] k95vz5f02 at sneakemail dot com
Perfect, thanks for fixing this.
Tests done to verify, using the windows version linked to above [PHP
5.2.0RC5-dev (cli) (built: Sep 27 2006 00:22:40)]:
realpath("C:\\Program Files") => C:\Program Files
realpath("c:\\PrOgRaM fIlEs") => C:\Program Files
realpath("C:\\program files\\") => C:\Program Files
realpath("C:/program files/") => C:\Program Files
realpath("C:\\pRoGrA~1")=> C:\Program Files
realpath("c:\\windows") => C:\WINDOWS
realpath("c:\\wInDoWs\\DoWnLoAdEd PrOgRaM fIlEs\\") =>
C:\WINDOWS\Downloaded Program Files
[2006-09-26 22:18:42] tony2...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-06-23 17:19:53] k95vz5f02 at sneakemail dot com
On further investigation, realpath doesn't consistently canonicalize the
case at all on Windows, I've updated the summary accordingly.
First to remember the need for this: the documentation definition for
realpath is "Returns canonicalized absolute pathname", and Wikipedia
defines canonicalization as
"Canonicalization (abbreviated c14n) is the process of converting data
that has more than one possible representation into a "standard"
canonical representation. This can be done to compare different
representations for equivalence (...)"
So clearly case should be converted to a standard form on platforms such
as Windows that are case-insensitive, and indeed Windows stores the
preferred case for every file, for example the standard directory
'C:\Program Files' should be capitalised like that, rather than, e.g.
'C:\program files' or 'C:\PROGRAM FILES', whereas 'C:\WINDOWS' is the
preferred case for that directory (on Win XP at least).
Tests:
1. realpath("C:\\Program Files") => C:\Program Files
2. realpath("c:\\PrOgRaM fIlEs") => c:\PrOgRaM fIlEs
3. realpath("C:\\program files\\") => C:\program files
4. realpath("C:/program files/") => C:\program files
5. realpath("C:\\pRoGrA~1")=> C:\Program Files
6. realpath("c:\\windows") => c:\WINDOWS
7. realpath("c:\\wInDoWs\\DoWnLoAdEd PrOgRaM fIlEs\\") =>
c:\WINDOWS\DoWnLoAdEd PrOgRaM fIlEs
Conclusion:
realpath deals with slashes consistently, but it only canonicalizes the
case of short filenames (as well as expanding them), not long file names
(anything more than 8.3, or with a space, etc); and it never capitalizes
the drive letter as it should.
A possible solution, if slightly inefficient, would be to convert path
components into short (8.3) form then apply the normal realpath logic.
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/bug.php?id=37350
--
Edit this bug report at http://bugs.php.net/bug.php?id=37350&edit=1
Bug #37350 [Com]: realpath() doesn't canonicalize case on Windows
Edit report at http://bugs.php.net/bug.php?id=37350&edit=1
ID: 37350
Comment by: jah at jahboite dot co dot uk
Reported by: k95vz5f02 at sneakemail dot com
Summary: realpath() doesn't canonicalize case on Windows
Status: Closed
Type: Bug
Package: Filesystem function related
Operating System: Windows XP SP2
PHP Version: 5.1.4
New Comment:
Having examined CWD_API int virtual_file_ex I realise that I'm an idiot
and you should disregard my previous comment. realpath is returning the
canonicalised path:
C:\WINDOWS\system32\cmd.exe
I should have checked my bloody filesystem!
Previous Comments:
[2010-07-24 00:03:16] jah at jahboite dot co dot uk
I don't think this issue is quite fixed yet.
php.exe -r "echo realpath('C:\WINDOWS\System32\cmd.exe');"
Expected result:
C:\WINDOWS\System32\cmd.exe
Actual result:
--
C:\WINDOWS\system32\cmd.exe
System32 -> system32
This is with the PHP 5.2.14 windows binary on Windows XP SP3.
[2006-09-26 23:45:01] k95vz5f02 at sneakemail dot com
Perfect, thanks for fixing this.
Tests done to verify, using the windows version linked to above [PHP
5.2.0RC5-dev (cli) (built: Sep 27 2006 00:22:40)]:
realpath("C:\\Program Files") => C:\Program Files
realpath("c:\\PrOgRaM fIlEs") => C:\Program Files
realpath("C:\\program files\\") => C:\Program Files
realpath("C:/program files/") => C:\Program Files
realpath("C:\\pRoGrA~1")=> C:\Program Files
realpath("c:\\windows") => C:\WINDOWS
realpath("c:\\wInDoWs\\DoWnLoAdEd PrOgRaM fIlEs\\") =>
C:\WINDOWS\Downloaded Program Files
[2006-09-26 22:18:42] tony2...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-06-23 17:19:53] k95vz5f02 at sneakemail dot com
On further investigation, realpath doesn't consistently canonicalize the
case at all on Windows, I've updated the summary accordingly.
First to remember the need for this: the documentation definition for
realpath is "Returns canonicalized absolute pathname", and Wikipedia
defines canonicalization as
"Canonicalization (abbreviated c14n) is the process of converting data
that has more than one possible representation into a "standard"
canonical representation. This can be done to compare different
representations for equivalence (...)"
So clearly case should be converted to a standard form on platforms such
as Windows that are case-insensitive, and indeed Windows stores the
preferred case for every file, for example the standard directory
'C:\Program Files' should be capitalised like that, rather than, e.g.
'C:\program files' or 'C:\PROGRAM FILES', whereas 'C:\WINDOWS' is the
preferred case for that directory (on Win XP at least).
Tests:
1. realpath("C:\\Program Files") => C:\Program Files
2. realpath("c:\\PrOgRaM fIlEs") => c:\PrOgRaM fIlEs
3. realpath("C:\\program files\\") => C:\program files
4. realpath("C:/program files/") => C:\program files
5. realpath("C:\\pRoGrA~1")=> C:\Program Files
6. realpath("c:\\windows") => c:\WINDOWS
7. realpath("c:\\wInDoWs\\DoWnLoAdEd PrOgRaM fIlEs\\") =>
c:\WINDOWS\DoWnLoAdEd PrOgRaM fIlEs
Conclusion:
realpath deals with slashes consistently, but it only canonicalizes the
case of short filenames (as well as expanding them), not long file names
(anything more than 8.3, or with a space, etc); and it never capitalizes
the drive letter as it should.
A possible solution, if slightly inefficient, would be to convert path
components into short (8.3) form then apply the normal realpath logic.
[2006-06-23 11:13:39] hanskrentel at yahoo dot de
within the windows OS there is no difference between cAsE in filenames,
a solution might be to read out the actual filename from the system and
return it by realpath.
but this won't be a valid solution afterall: next to case ignorance,
there are two filenames for a file as well: the long and the short (8.3)
one (since win/32/95 or FAT 32). so i guess a comparison will fail in
that case anyway.
additionally, for me another problem occurs:
c:\windows is a directory and could be name as c:\windows\ as well (in
my opinion it even should but that's my personal opinion anyway).
since for me there is no logical correct solution for this problem
anyway I would suggest to handle the windows filesystem more similar to
the *nix one, that meaning using / instead of \ for example to point to
directories with the needed / at the end. add
Bug #52407 [Com]: FPM module compilation fails on ARM architecture
Edit report at http://bugs.php.net/bug.php?id=52407&edit=1 ID: 52407 Comment by: f...@php.net Reported by: eugenesan at gmail dot com Summary: FPM module compilation fails on ARM architecture Status: Assigned Type: Bug Package: Compile Failure Operating System: Linux PHP Version: 5.3.3 Assigned To: fat New Comment: Can you please test & validate this patch on ARM arch ? I've added an #error if ARM && gcc <= 4.2 Previous Comments: [2010-07-24 14:36:05] f...@php.net The following patch has been added/updated: Patch Name: fpm_atomic_h_fix.patch Revision: 1279974965 URL: http://bugs.php.net/patch-display.php?bug=52407&patch=fpm_atomic_h_fix.patch&revision=1279974965 [2010-07-24 10:38:29] eugenesan at gmail dot com I wasn't aware of atomic functionality in libgcc. In older version of FPM (before W-Mark Kubacki provided current solution), I was copying atomic functions available in libc :-) Also, W-Mark Kubacki tried to propose libatomic as generic solution for all platforms, but due to stability reasons solution was declined. Anyways, provided patch is only for urgent fixing of FPM on ARM in PHP 5.3.3. Later, I would expect more serious treatment of the issue by maintainers. [2010-07-24 02:00:20] geiss...@php.net As a matter of fact, why aren't the gcc atomic builtins used in all architectures if gcc > 4.1 is used? Otherwise it is going to be a pain to port the atomic code to many architectures. I've read that icc supports them too, but I don't know since when or anything else. For the Debian packages I'm going to do that, but I'd prefer to see the change happen here too (included a cleanup of the unused atomic_*_t types -- only atomic_t needs to be defined.) [2010-07-22 17:30:10] eugenesan at gmail dot com Patch passed heavy load test. [2010-07-22 17:21:20] der...@php.net Never mind, it's there now :-) 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/bug.php?id=52407 -- Edit this bug report at http://bugs.php.net/bug.php?id=52407&edit=1
Bug #52407 [PATCH]: FPM module compilation fails on ARM architecture
Edit report at http://bugs.php.net/bug.php?id=52407&edit=1 ID: 52407 Patch added by: f...@php.net Reported by: eugenesan at gmail dot com Summary: FPM module compilation fails on ARM architecture Status: Assigned Type: Bug Package: Compile Failure Operating System: Linux PHP Version: 5.3.3 Assigned To: fat New Comment: The following patch has been added/updated: Patch Name: fpm_atomic_h_fix.patch Revision: 1279974965 URL: http://bugs.php.net/patch-display.php?bug=52407&patch=fpm_atomic_h_fix.patch&revision=1279974965 Previous Comments: [2010-07-24 10:38:29] eugenesan at gmail dot com I wasn't aware of atomic functionality in libgcc. In older version of FPM (before W-Mark Kubacki provided current solution), I was copying atomic functions available in libc :-) Also, W-Mark Kubacki tried to propose libatomic as generic solution for all platforms, but due to stability reasons solution was declined. Anyways, provided patch is only for urgent fixing of FPM on ARM in PHP 5.3.3. Later, I would expect more serious treatment of the issue by maintainers. [2010-07-24 02:00:20] geiss...@php.net As a matter of fact, why aren't the gcc atomic builtins used in all architectures if gcc > 4.1 is used? Otherwise it is going to be a pain to port the atomic code to many architectures. I've read that icc supports them too, but I don't know since when or anything else. For the Debian packages I'm going to do that, but I'd prefer to see the change happen here too (included a cleanup of the unused atomic_*_t types -- only atomic_t needs to be defined.) [2010-07-22 17:30:10] eugenesan at gmail dot com Patch passed heavy load test. [2010-07-22 17:21:20] der...@php.net Never mind, it's there now :-) [2010-07-22 17:20:49] der...@php.net I see no attachment. 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/bug.php?id=52407 -- Edit this bug report at http://bugs.php.net/bug.php?id=52407&edit=1
Bug #49246 [Com]: bug38770.phpt fails
Edit report at http://bugs.php.net/bug.php?id=49246&edit=1 ID: 49246 Comment by: men28u at yahoo dot com Reported by: atomo64 at gmail dot com Summary: bug38770.phpt fails Status: No Feedback Type: Bug Package: Strings related Operating System: Linux i686 PHP Version: 5.2.10 New Comment: There is no problem on 64bit Ubuntu 10.04 LTS - the Lucid Lynx. make test TESTS=./ext/standard/tests/strings/bug38770.phpt passes without any problem on php 5.2 version. Previous Comments: [2009-08-21 01:00:02] 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". [2009-08-13 18:56:39] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-08-13 17:38:41] atomo64 at gmail dot com Description: ext/standard/tests/strings/bug38770.phpt fails on an i686 machine Reproduce code: --- Expected result: (as per the test) Array ( [1] => 4294937296 ) Array ( [1] => -3 ) Array ( [1] => -3 ) Done Actual result: -- Array ( [1] => -3 ) Array ( [1] => -3 ) Array ( [1] => -3 ) Done -- Edit this bug report at http://bugs.php.net/bug.php?id=49246&edit=1
Bug #52396 [Bgs]: Acessing a class within a static class
Edit report at http://bugs.php.net/bug.php?id=52396&edit=1
ID: 52396
User updated by: mark at rwrightson dot f9 dot co dot uk
Reported by: mark at rwrightson dot f9 dot co dot uk
Summary: Acessing a class within a static class
Status: Bogus
Type: Bug
Package: Class/Object related
Operating System: Windows 7
PHP Version: 5.3.2
New Comment:
Apologies for posting long code here.
The code aharvey posted doesn't demonstrate the problem.
I have added a small amount of extra code to his code to demonstrate the
exact issue.
http://www.voltnet.co.uk/phperror/52396.txt
I should probably mention that this example doesn't work on php 5.2.9
but it does work on php v5.3.2
The code should output:
"ClassThatPrintsItsName hello"
If line 41 is commented out and replaced with line 42 the following
error will appear:
Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in
C:\htdocs\error.php on line 41.
Looking at the two lines below, the problem that is occurring is when
trying to statically access a static variable within a class that has
already been statically accessed.
$c::$bar::$another->hello();//this line won't work
$c::$bar->getAnother()->hello();//this line will work
The line (line 41) that won't work can be rewritten as:
$a = $c::$bar;
$a::$another->hello();
and this will make it work
I hope this better demonstrates the issue
Previous Comments:
[2010-07-23 12:20:38] ahar...@php.net
Closing, because I can't reproduce this. Even if I uncomment the right
line in your example, that is:
self::$bar->test->hello();
It appears to do what it's supposed to. I've put a much simpler version
of what I think your problem is up at http://codepad.viper-7.com/l2GN2F
and that also works normally.
Also, please note that we'd really prefer reproduce code that's no more
than about 20 lines -- I had a fair job trying to follow what was going
on in your code. :)
[2010-07-22 00:42:35] mark at rwrightson dot f9 dot co dot uk
Description:
It is currently not possible to access a class that is instantiated
within another class that is instantiated within a static object
variable.
Using the example below I would expect this line of code to function
correctly:
(where self is Foo)
self::$bar->test->hello();
however this isn't the case. A getter must be created in the bar()
class to get the test class object variable. I.e. getTest(). The above
line can then be re-written as :
self::$bar->getTest()->hello();
this works correctly. In finding this solution I also tried the same
concept in another OO language (Java). I copied the code as per below
and altered the syntax. the line above became: bar.test.hello(); which
worked ok.
For this reason, as the operation discussed here is a standard OO
concept, it could be classed as a bug within PHP.
The attached test script demonstrates the getTest() workaround.
commented out above this line are numerous error messages that I
encountered when trying to access the test class.
Many Thanks
Test script:
---
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\";>
http://www.w3.org/1999/xhtml\"; lang=\"en\"
xml:lang=\"en\">
XHTML-document
";
new foo();
echo"
";
class foo
{
public static $bar;
public static $foo2;
public function __construct()
{
echo"construct foo";
echo"create static instance of bar";
self::$bar = new bar();
echo"call hello() in bar class";
self::$bar->hello();
echo"call hello() in test class from Foo class through bar
class";
//N.B. The following methods failed. However there is one solution...
//self::$bar->$test->hello();
//Notice: Undefined variable: test in ... on line...
//Fatal error: Cannot access empty property in ... on line...
//self::$bar->test->hello();
//Notice: Undefined property: bar::$test in ... on...
//Fatal error: Call to a member function hello() on a non-object in ...
on...
//self::$bar::$test->hello();
//Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in ...
on...
//self::$bar::test->hello();
//Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in ...
on...
//self::$bar->self::$test->hello();
//Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in ...
on...
//self::$bar::self::$test->hello();
//Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in ...
on...
self::$bar->getTest()->hello();
echo"create static instance of foo2";
self::$foo2 = new foo2();
}
}
class bar
{
//N.B. the class Test() can be instantiated as either a static or a
normal variable
//p
[PHP-BUG] Bug #52428 [NEW]: $this isn't immutable
From:
Operating system: all
PHP version: 5.3.3
Package: Scripting Engine problem
Bug Type: Bug
Bug description:$this isn't immutable
Description:
As some closed bug-reports and the "PHP Fatal error: Cannot re-assign
$this"
states, the $this should be read-only/inmutable in PHP5.
but with some tricks(variable variables mostly), you can walk-around this
constraint.
See the Test script.
I don't know the importance of this restriction, and with reflection you
can shoot
you in the leg anyway, so maybe this can be left as is.
Test script:
---
foo = 'bar';
//$this = $var; // PHP Fatal error: Cannot re-assign $this
$GLOBALS['this'] = $var;
var_dump($this);
$var->foo = 'baz';
$foo = 'this';
$$foo = $var;
var_dump($this);
foo($this);
function foo($this){
//global $this; // PHP Fatal error: Cannot re-assign $this
// $this = $GLOBALS['var']; // PHP Fatal error: Cannot re-assign $this
var_dump($this);
$GLOBALS['this']->foo = 'baw';
$$GLOBALS['foo'] = $GLOBALS['this'];
var_dump($this);
}
Expected result:
PHP Fatal error: Cannot re-assign $this
for every attempt to overwrite $this
Actual result:
--
you can set $this in the global scope through $GLOBALS, with argument in
functions, and with variable variables in everywhere.
--
Edit bug report at http://bugs.php.net/bug.php?id=52428&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52428&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52428&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52428&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52428&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52428&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52428&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52428&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52428&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52428&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52428&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52428&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52428&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52428&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52428&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52428&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52428&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52428&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52428&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52428&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52428&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52428&r=mysqlcfg
Bug #52407 [Asn]: FPM module compilation fails on ARM architecture
Edit report at http://bugs.php.net/bug.php?id=52407&edit=1 ID: 52407 User updated by: eugenesan at gmail dot com Reported by: eugenesan at gmail dot com Summary: FPM module compilation fails on ARM architecture Status: Assigned Type: Bug Package: Compile Failure Operating System: Linux PHP Version: 5.3.3 Assigned To: fat New Comment: I wasn't aware of atomic functionality in libgcc. In older version of FPM (before W-Mark Kubacki provided current solution), I was copying atomic functions available in libc :-) Also, W-Mark Kubacki tried to propose libatomic as generic solution for all platforms, but due to stability reasons solution was declined. Anyways, provided patch is only for urgent fixing of FPM on ARM in PHP 5.3.3. Later, I would expect more serious treatment of the issue by maintainers. Previous Comments: [2010-07-24 02:00:20] geiss...@php.net As a matter of fact, why aren't the gcc atomic builtins used in all architectures if gcc > 4.1 is used? Otherwise it is going to be a pain to port the atomic code to many architectures. I've read that icc supports them too, but I don't know since when or anything else. For the Debian packages I'm going to do that, but I'd prefer to see the change happen here too (included a cleanup of the unused atomic_*_t types -- only atomic_t needs to be defined.) [2010-07-22 17:30:10] eugenesan at gmail dot com Patch passed heavy load test. [2010-07-22 17:21:20] der...@php.net Never mind, it's there now :-) [2010-07-22 17:20:49] der...@php.net I see no attachment. [2010-07-22 17:16:27] eugenesan at gmail dot com Description: FPM module compilation fails on ARM architecture. Fix attached while approved by original code author (W-Mark Kubacki) Test script: --- configure with --enable-fpm and build on ARM machine Expected result: Compilation should pass and binary work. -- Edit this bug report at http://bugs.php.net/bug.php?id=52407&edit=1
