[PHP-BUG] Req #54555 [NEW]: Late static binding effect for __NAMESPACE__
From: Operating system: Linux PHP version: 5.3.6 Package: *General Issues Bug Type: Feature/Change Request Bug description:Late static binding effect for __NAMESPACE__ Description: I've been chilling around with the latest PHP features and noticed that there is something missing - there is no way to get the current namespace if inheriting some implementation, which limit us on some implementations. For example, we have an abstract class in one namespace and adapter for the very same class in another namespace. If we try to use the __NAMESPACE__ within the abstract class, it uses its own one and not the one of the inheriting class. I've checked the documentation to find some notes on this one to no avail. Test script: --- getNamespace()); } Expected result: nikola@nikola-pc:~$ php test2.php string(13) "SomeNamespace\Adapters" Actual result: -- nikola@nikola-pc:~$ php test2.php string(13) "SomeNamespace" -- Edit bug report at http://bugs.php.net/bug.php?id=54555&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54555&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54555&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54555&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54555&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54555&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54555&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54555&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54555&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54555&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54555&r=support Expected behavior: http://bugs.php.net/fix.php?id=54555&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54555&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54555&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54555&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54555&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54555&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54555&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54555&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54555&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54555&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54555&r=mysqlcfg
Bug #54529 [Opn]: SAPI crashes on apache_config.c:197
Edit report at http://bugs.php.net/bug.php?id=54529&edit=1
ID: 54529
User updated by:aigors at inbox dot lv
Reported by:aigors at inbox dot lv
Summary:SAPI crashes on apache_config.c:197
Status: Open
Type: Bug
Package:Apache2 related
Operating System: Debian x86_64 GNU/Linux
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Seems the bug disappears when the line
php_admin_value sendmail_path "/usr/sbin/sendmail -t -i
-fi...@example.com"
is removed from the Apache virtual host configuration.
Previous Comments:
[2011-04-14 09:45:28] aigors at inbox dot lv
Description:
Segfault is happening sometimes on our test environment, Production
environment
has segmentation faults more frequent (has more requests apparently).
Have set Apache core dump configation and compiled PHP with debug mode
on the
test.
Receiving such error:
Program terminated with signal 11, Segmentation fault.
#0 0x7f3d13e2b9a4 in apply_config (dummy=0x182d078) at /root/php-
5.3.6/sapi/apache2handler/apache_config.c:197
197 if (zend_alter_ini_entry(str, str_len, data->value,
data->value_len,
data->status,
data->htaccess?PHP_INI_STAGE_HTACCESS:PHP_INI_STAGE_ACTIVATE) ==
FAILURE) {
Apache compiled with such configuration:
./configure --prefix=/usr/local/httpd-2.2.17 --with-mpm=worker
--with-ssl --
enable-rewrite --enable-ssl --disable-cgi --enable-expires
--enable-headers --en
able-so --enable-cache --enable-mem-cache --enable-exception-hook
PHP compiled with such parameters:
./configure --prefix=/usr/local/php5.3.6 --sysconfdir=/etc --with-
apxs2=/usr/local/httpd-2.2.17/bin/apxs --with-config-file-path=/etc/php/
--with-
config-file-scan-dir=/etc/php/ext-active --enable-bcmath
--enable-calendar --
with-curl --enable-exif --enable-ftp --with-gettext --enable-mbstring
--with-
mcrypt --with-mhash --with-openssl --with-openssl-dir --with-pgsql
--enable-soap
--enable-sockets --with-xmlrpc --with-xsl --enable-zip --with-zlib
--with-
freetype-dir --with-jpeg-dir --with-png-dir --with-gd --with-pdo-pgsql
--with-
kerberos --disable-ipv6 --with-libdir=lib64 --enable-debug
Actual result:
--
Full backtrace we're having for the failing thread:
--
#0 0x7f3d13e2b9a4 in apply_config (dummy=0x182d078) at /root/php-
5.3.6/sapi/apache2handler/apache_config.c:197
d = 0x182d078
str = 0x1750f70 "sendmail_path"
str_len = 14
data = 0x0
#1 0x7f3d13e2ac09 in php_handler (r=0x219bec0) at /root/php-
5.3.6/sapi/apache2handler/sapi_apache2.c:568
ctx = 0x0
conf = 0x182d078
brigade = 0x219c148
bucket = 0x182e8a0
rv = 0
parent_req = 0x0
tsrm_ls = 0x236ccc0
#2 0x00444710 in ap_run_handler (r=0x219bec0) at config.c:158
n = 6
rv = 0
#3 0x00447d6e in ap_invoke_handler (r=0x219bec0) at
config.c:376
handler = 0x1821500 "application/javascript"
result = 25302272
old_handler = 0x0
ignore =
#4 0x0047a058 in ap_process_request (r=0x219bec0) at
http_request.c:282
access_status = 0
#5 0x00477010 in ap_process_http_connection (c=0x21980c8) at
http_core.c:190
r = 0x219bec0
csd = 0x2197eb0
#6 0x0044bcf8 in ap_run_process_connection (c=0x21980c8) at
connection.c:43
n = 0
rv = 0
#7 0x00496d37 in process_socket (thd=,
dummy=) at worker.c:544
current_conn =
conn_id =
csd = 25
sbh = 0x21980c0
#8 worker_thread (thd=, dummy=) at
worker.c:894
process_slot = 0
thread_slot = 20
csd = 0x2197eb0
bucket_alloc =
last_ptrans =
ptrans = 0x2197e28
rv =
is_idle =
#9 0x7f3d14d608ba in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#10 0x7f3d148c402d in clone () from /lib/libc.so.6
No symbol table info available.
#11 0x in ?? ()
No symbol table info available.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54529&edit=1
[PHP-BUG] Bug #54556 [NEW]: array access to empty class member does not trigger a notice
From: Operating system: Ubuntu 10.04.2 LTS PHP version: trunk-SVN-2011-04-18 (snap) Package: Class/Object related Bug Type: Bug Bug description:array access to empty class member does not trigger a notice Description: see script Test script: --- bar['yeah']); } } $foo = new Foo(); $foo->nonotice(); Expected result: notice: access to undefined array blah Actual result: -- NULL -- Edit bug report at http://bugs.php.net/bug.php?id=54556&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54556&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54556&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54556&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54556&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54556&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54556&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54556&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54556&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54556&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54556&r=support Expected behavior: http://bugs.php.net/fix.php?id=54556&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54556&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54556&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54556&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54556&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54556&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54556&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54556&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54556&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54556&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54556&r=mysqlcfg
Bug #54553 [Opn->Asn]: OCI-Collection::getelem() Unknown or unsupported type of element
Edit report at http://bugs.php.net/bug.php?id=54553&edit=1
ID: 54553
Updated by: johan...@php.net
Reported by:richard dot strba at email dot cz
Summary:OCI-Collection::getelem() Unknown or unsupported
type of element
-Status: Open
+Status: Assigned
Type: Bug
Package:OCI8 related
Operating System: Windows XP Professional SP3
PHP Version:5.3.6
-Assigned To:
+Assigned To:sixd
Block user comment: N
Private report: N
Previous Comments:
[2011-04-18 02:21:20] richard dot strba at email dot cz
Description:
function OCI-Collection::getelem() returns "Unknown or unsupported type
of element: 108 when collection returned from oracle sql stored
function. database version is 10g Release 2
Test script:
---
SQL:
CREATE TABLE AAAPOKUS2 ("COLUMN1" VARCHAR2(20 BYTE) ) TABLESPACE "USERS"
;
CREATE OR REPLACE TYPE AAATYPE1 AS object ( column1 VARCHAR2(20 CHAR)
);
CREATE OR REPLACE TYPE AAATYPE1_TABLE is table of AAATYPE1;
CREATE OR REPLACE FUNCTION FUNCTION3
(
PARAM2 OUT AAATYPE1_TABLE
) RETURN number AS
BEGIN
SELECT AAATYPE1(column1)
bulk collect into PARAM2 FROM
AAAPOKUS1;
RETURN 8;
END FUNCTION3;
PHP:
$query = " BEGIN :v_Return := FUNCTION3(:PARAM2);end;\n";
$s = oci_parse($conn, $query);
$var3 = ' 3';
$collection = oci_new_collection($conn,"AAATYPE1_TABLE","KSM");
oci_bind_by_name($s, ":PARAM2", $collection,-1,OCI_B_NTY);
oci_bind_by_name($s, ":v_Return", $var3);
oci_execute($s, OCI_DEFAULT);
echo($collection->size());
$elem = $collection->getElem(1);
Expected result:
expected is some values (array of values) returned from stored function
Actual result:
--
false
--
Edit this bug report at http://bugs.php.net/bug.php?id=54553&edit=1
Bug #54556 [Com]: array access to empty class member does not trigger a notice
Edit report at http://bugs.php.net/bug.php?id=54556&edit=1 ID: 54556 Comment by: kal dot el dot ias at gmx dot net Reported by:kal dot el dot ias at gmx dot net Summary:array access to empty class member does not trigger a notice Status: Open Type: Bug Package:Class/Object related Operating System: Ubuntu 10.04.2 LTS PHP Version:trunk-SVN-2011-04-18 (snap) Block user comment: N Private report: N New Comment: hmm, it's the same for normal variables and it's not an error reporting problem. bar['yeah']); } } $foo = new Foo(); $foo->nonotice(); Expected result: notice: access to undefined array blah Actual result: -- NULL -- Edit this bug report at http://bugs.php.net/bug.php?id=54556&edit=1
Req #47550 [Opn->Bgs]: mysql_real_escape_strings_set()
Edit report at http://bugs.php.net/bug.php?id=47550&edit=1 ID: 47550 Updated by: johan...@php.net Reported by:alexander at vourtsis dot com Summary:mysql_real_escape_strings_set() -Status: Open +Status: Bogus Type: Feature/Change Request Package:MySQL related Operating System: Windows Linux OSX PHP Version:5.3.0beta1 Block user comment: N Private report: N New Comment: I don't fully understand what you want. But I assume you want to have some magic to escape some random strings in some situations magically. We won't do that. MAgic makes debugging, etc. way harder! Explicit code makes checking simpler. Previous Comments: [2009-03-03 10:41:15] alexander at vourtsis dot com Description: I'd want to suggest a function to switch escaping of input strings for an sql query. So far escaping occurs by the use of mysql_real_escape_string(). Using this for each variable can result into a clutter like, mysql_real_escape_string($test1); mysql_real_escape_string($test2); mysql_real_escape_string($test3); mysql_real_escape_string($test4); I suggest to create a function to turn real escape string on and off like, mysql_real_escape_strings_set(1); and to get if escaping is on: mysql_real_escape_strings_get(); Thank you in Advance, Reproduce code: --- --- >From manual page: function.mysql-real-escape-string --- -- Edit this bug report at http://bugs.php.net/bug.php?id=47550&edit=1
Req #45276 [Opn->Wfx]: feature request: mysql_fetch_object_dynamic
Edit report at http://bugs.php.net/bug.php?id=45276&edit=1
ID: 45276
Updated by: johan...@php.net
Reported by:darrel dot opry at gmail dot com
Summary:feature request: mysql_fetch_object_dynamic
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
Package:MySQL related
PHP Version:5.3CVS-2008-06-15 (CVS)
Block user comment: N
Private report: N
New Comment:
It is hard to do properly in a generic way which works for most cases.
Which we have to do at the level. You can build an iterator or such
doing what you need quite efficiently.
Previous Comments:
[2008-06-15 19:39:45] darrel dot opry at gmail dot com
Description:
Current you can specify a class name for mysql_fetch_object to
instantiate a class in the request. For some of my applications
I do not know the proper class at the point I'm querying the
database. Normally this happens when working with child classes
that have identical database data requirements as their parents.
Currently I use factory functions that query the database and
instantiate the proper class based on the row object, and pass the
row object into the constructor to initialized the object.
It would be nice to be able to specify a table column that contains the
class name for an object. Something along the lines of:
/**
* @param mysql_result $result
* @param string $class_column to column of the row containing
* the class name that should be initilized.
* @param array $ctor_args arguments to pass to the class constructor.
*/
mysql_fetch_object_dynamic($result, $class_column, $ctor_args)
Example Use Case:
Loading child classes from with identical data storage.
Given:
table strings(id, class, value);
class string {
$id = 0;
$value = '';
function set_value($value) {
if (!$this->validate($value)) return false;
$this->value = $value;
return true;
}
function validate($value) {
return is_string($value);
}
function print() {
print $this->value();
}
function save() {
if ($this->id) {
mysql_query("UPDATE strings
SET value='$this->value'
WHERE id=$this->id");
}
else {
mysql_query('INSERT INTO {strings}
($this->is, __CLASS__, $this->value));
}
}
}
class email extends string {
function validate($value) {
return is_email($value);
}
function print() {
print "$this->value\";
}
}
$result = mysql_query('SELECT * FROM strings');
while($string = mysql_fetch_object_dynamic($result, 'class')) {
$string->print();
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=45276&edit=1
Req #42901 [Asn->Wfx]: Add a flag to PDO_mysql for reconnection in case of timeouts
Edit report at http://bugs.php.net/bug.php?id=42901&edit=1 ID: 42901 Updated by: johan...@php.net Reported by:soenke at jimdo dot com Summary:Add a flag to PDO_mysql for reconnection in case of timeouts -Status: Assigned +Status: Wont fix Type: Feature/Change Request Package:MySQL related Operating System: Irrelevant PHP Version:5.2.4 Assigned To:mysql Block user comment: N Private report: N New Comment: Doing this in the driver level means that your application will "suddenly" loose its state (transactions, temp table, session vars, probably including encoding settings, ...) this is fine for vhost configuration as there's not much state, in an application it's better to do it inside an database wrapper and react properly. Previous Comments: [2007-10-09 13:50:22] soenke at jimdo dot com Here is working code from lighttpd mod_mysql_vhost: http://trac.lighttpd.net/trac/browser/branches/lighttpd-1.4.x/src/mod_mysql_vhost.c?rev=1965 [2007-10-09 13:45:52] soenke at jimdo dot com Description: For long-running PHP script with database connections it would be nice if the database driver automatically reconnects in case of a server/network timeout. This could be integrated with a reconnect flag for PDO. At least in libmysqlclient >= 5.0.13 MYSQL_OPT_RECONNECT is available. -- Edit this bug report at http://bugs.php.net/bug.php?id=42901&edit=1
Bug #54025 [Com]: ResourceBundle fails to read files with uppercase characters
Edit report at http://bugs.php.net/bug.php?id=54025&edit=1
ID: 54025
Comment by: david dot zuelke at bitextender dot com
Reported by:bschussek at gmail dot com
Summary:ResourceBundle fails to read files with uppercase
characters
Status: Open
Type: Bug
Package:I18N and L10N related
Operating System: Ubuntu 10.10
PHP Version:5.3SVN-2011-02-15 (snap)
Block user comment: N
Private report: N
New Comment:
Duplicate of http://bugs.php.net/54540
Previous Comments:
[2011-02-15 14:28:28] bschussek at gmail dot com
Description:
A bundle named "supplementalData" can't be read by ResourceBundle. If
the bundle
is named "supplementaldata" instead, loading works.
To reproduce, create a supplementalData.txt with this content:
--- BEGIN ---
supplementalData{
}
--- END ---
Then run genrb on the CLI:
$ genrb supplementalData.txt
which will generate a supplementalData.res needed by the test. genrb
will output
a warning, but you can ignore that for the purpose of this test.
Test script:
---
http://bugs.php.net/bug.php?id=54025&edit=1
Bug #37777 [Com]: shm_put_var does not work with resource vars
Edit report at http://bugs.php.net/bug.php?id=3&edit=1 ID: 3 Comment by: kjakobi at goodgamestudios dot com Reported by:matthias dot etienne at gmail dot com Summary:shm_put_var does not work with resource vars Status: Bogus Type: Bug Package:Semaphore related Operating System: Debian 3.1 PHP Version:5.1.4 Block user comment: N Private report: N New Comment: The documentation is still wrong.. Previous Comments: [2006-06-11 16:47:38] matthias dot etienne at gmail dot com I did double-check the documentation and it tells: shm_put_var() inserts or updates the variable with the given variable_key. *All* variable-types are supported. See: http://fr.php.net/manual/en/function.shm-put-var.php So the documentation is wrong. [2006-06-11 15:46:06] il...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php You cannot store resources in shared memory. [2006-06-11 00:44:28] matthias dot etienne at gmail dot com Description: You cannot store var of type resource or retrieve a var of type resource with shm_put_var or shm_get_var. It always returns a int(0). Reproduce code: --- Expected result: Array ( [0] => hello [1] => world [2] => 1 [3] => 2 [4] => 3 ) Array ( [0] => hello [1] => world [2] => 4 [3] => 5 [4] => 6 ) resource(6) of type (stream) Actual result: -- Array ( [0] => hello [1] => world [2] => 1 [3] => 2 [4] => 3 ) Array ( [0] => hello [1] => world [2] => 4 [3] => 5 [4] => 6 ) int(0) -- Edit this bug report at http://bugs.php.net/bug.php?id=3&edit=1
[PHP-BUG] Bug #54558 [NEW]: configure not finding libraries
From: Operating system: RHEL 6 PHP version: 5.2.17 Package: Compile Failure Bug Type: Bug Bug description:configure not finding libraries Description: When I ran configure it was unable to find libjpeg.so, libpng.so, libXpm.so and libmysqlclient in spite of being told to look in /usr/lib64 I had to create symbolic links in /usr/lib for configure to find them. I tried everything from things like --with-jpeg-dir=/usr/lib64 to --with-libdir=lib64 yet configure would always end with the error unable to find. -- Edit bug report at http://bugs.php.net/bug.php?id=54558&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54558&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54558&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54558&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54558&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54558&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54558&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54558&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54558&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54558&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54558&r=support Expected behavior: http://bugs.php.net/fix.php?id=54558&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54558&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54558&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54558&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54558&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54558&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54558&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54558&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54558&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54558&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54558&r=mysqlcfg
Req #41310 [Com]: make extension_dir optional and use absolute paths in "extension = ..."
Edit report at http://bugs.php.net/bug.php?id=41310&edit=1 ID: 41310 Comment by: tyra3l at gmail dot com Reported by:mastamind at users dot sourceforge dot net Summary:make extension_dir optional and use absolute paths in "extension = ..." Status: Open Type: Feature/Change Request Package:PHP options/info functions Operating System: * PHP Version:* Block user comment: N Private report: N New Comment: it works for me with 5.3.6: extension /usr/lib/php5/20090626/pdo.so correctly loads the pdo extension from the absolute path. Tyrael Previous Comments: [2010-12-29 11:45:59] j...@php.net See also bug #9095 [2007-05-07 00:44:27] mastamind at users dot sourceforge dot net Description: using extension_dir = "/usr/local/lib/php" extension = "../pgsql.so" makes php search for pgsql.so in /usr/local/lib. It would be nice if php allows absolute paths for extension loading: extension = /usr/local/lib/pgsql.so as specifing it relative to the extension_dir is quite strange and probably makes extension_dir useless. specifing absolute paths with dl() may result in a security problem, but using it in php.ini may be ok. -- Edit this bug report at http://bugs.php.net/bug.php?id=41310&edit=1
[PHP-BUG] Bug #54559 [NEW]: php ignoring date.timezone setting
From:
Operating system: RHEL 6
PHP version: 5.3.6
Package: Date/time related
Bug Type: Bug
Bug description:php ignoring date.timezone setting
Description:
In my php.ini file I have
date.timezone = "America/New_York"
However I keep getting the error
Warning: phpinfo() [function.phpinfo]: It is not safe to rely on the
system's timezone settings. You are *required* to use the date.timezone
setting or the date_default_timezone_set() function. In case you used any
of those methods and you are still getting this warning, you most likely
misspelled the timezone identifier. We selected 'America/New_York' for
'EDT/-4.0/DST' instead in /var/www/html/gallery3/test.php on line 2
and this isn't just for phpinfo but everything I've tried dealing with
dates and times.
The only workaround I've found is to put
date_default_timezone_set('America/New_York');
at the start of all my scripts.
--
Edit bug report at http://bugs.php.net/bug.php?id=54559&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54559&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54559&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54559&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54559&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54559&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54559&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54559&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54559&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54559&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54559&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54559&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54559&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54559&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54559&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54559&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54559&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54559&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54559&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54559&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54559&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54559&r=mysqlcfg
Bug #54558 [Opn]: configure not finding libraries
Edit report at http://bugs.php.net/bug.php?id=54558&edit=1 ID: 54558 User updated by:jistanidiot at gmail dot com Reported by:jistanidiot at gmail dot com Summary:configure not finding libraries Status: Open Type: Bug Package:Compile Failure Operating System: RHEL 6 -PHP Version:5.2.17 +PHP Version:5.3.2 Block user comment: N Private report: N New Comment: Must have misclicked as the Version I'm on is 5.3.2 not 5.2.x Previous Comments: [2011-04-18 15:55:15] jistanidiot at gmail dot com Description: When I ran configure it was unable to find libjpeg.so, libpng.so, libXpm.so and libmysqlclient in spite of being told to look in /usr/lib64 I had to create symbolic links in /usr/lib for configure to find them. I tried everything from things like --with-jpeg-dir=/usr/lib64 to --with-libdir=lib64 yet configure would always end with the error unable to find. -- Edit this bug report at http://bugs.php.net/bug.php?id=54558&edit=1
Bug #51051 [Com]: DateTime modify wrong result with DST change
Edit report at http://bugs.php.net/bug.php?id=51051&edit=1
ID: 51051
Comment by: halde at freenet dot de
Reported by:mehdi dot rande at aliasource dot fr
Summary:DateTime modify wrong result with DST change
Status: Assigned
Type: Bug
Package:Date/time related
Operating System: Linux
PHP Version:5.3.1
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
reproduced issue of previous poster on a linux machine (timestamps are
not
equal):
$ php -a
Interactive shell
php > $dt = new DateTime('now', new DateTimeZone('Europe/Berlin'));
php > $dt->setTimestamp(1288483200);
php > echo $dt->getTimestamp();
1288486800
php > echo phpversion();
5.3.3-1ubuntu9.3
php > exit
$ uname -a
Linux wum128229 2.6.35-28-generic #49-Ubuntu SMP Tue Mar 1 14:39:03 UTC
2011
x86_64 GNU/Linux
Previous Comments:
[2011-02-24 17:07:56] j dot ek at gmx dot net
Think I found a related issue, reproduce it with:
setTimestamp(1288483200);
// but returns timestamp of 2010-10-31T02:00:00+0100
echo $dt->getTimestamp(); // outputs 1288486800
?>
WinXP 32, PHP 5.3.2 (cli) (built: Mar 3 2010 20:36:54)
[2010-12-25 02:46:45] danielc at analysisandsolutions dot com
DateTime::diff() is similarly afflicted with daylight/standard change
over issues. Naturally, diff/add/sub all need to be in sync so
intervals returned by diff can be passed to add/sub and produce the
original datetime.
[2010-12-25 02:27:22] dani...@php.net
I just attached a test script that covers issues in the spring and fall.
[2010-12-25 02:26:16] dani...@php.net
The following patch has been added/updated:
Patch Name: bug51051test.php.txt
Revision: 1293240376
URL:
http://bugs.php.net/patch-display.php?bug=51051&patch=bug51051test.php.txt&revision=1293240376
[2010-08-24 14:34:22] glennpratt+php at gmail dot com
Correction for the Expected result above.
Expected Result
---
2011-03-13T03:00:00-05:00 America/Chicago
2011-03-13T01:58:00-06:00 America/Chicago
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=51051
--
Edit this bug report at http://bugs.php.net/bug.php?id=51051&edit=1
Bug #54559 [Opn->Bgs]: php ignoring date.timezone setting
Edit report at http://bugs.php.net/bug.php?id=54559&edit=1
ID: 54559
Updated by: dtajchre...@php.net
Reported by:jistanidiot at gmail dot com
Summary:php ignoring date.timezone setting
-Status: Open
+Status: Bogus
Type: Bug
Package:Date/time related
Operating System: RHEL 6
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Are you modifying the right configuration file for the SAPI you're
using?
phpinfo() and php --ini will show you which configuration files are
loaded... is
that the file you have date.timezone = "America/New_York" in?
Previous Comments:
[2011-04-18 17:05:40] jistanidiot at gmail dot com
Description:
In my php.ini file I have
date.timezone = "America/New_York"
However I keep getting the error
Warning: phpinfo() [function.phpinfo]: It is not safe to rely on the
system's timezone settings. You are *required* to use the date.timezone
setting or the date_default_timezone_set() function. In case you used
any of those methods and you are still getting this warning, you most
likely misspelled the timezone identifier. We selected
'America/New_York' for 'EDT/-4.0/DST' instead in
/var/www/html/gallery3/test.php on line 2
and this isn't just for phpinfo but everything I've tried dealing with
dates and times.
The only workaround I've found is to put
date_default_timezone_set('America/New_York');
at the start of all my scripts.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54559&edit=1
[PHP-BUG] Req #54561 [NEW]: Expose ICU version info
From: Operating system: Mac OS X 10.6.7 PHP version: 5.3.6 Package: *Languages/Translation Bug Type: Feature/Change Request Bug description:Expose ICU version info Description: It should be possible to detect the ICU version number - this is important in order to figure out what the structure of the data is, since that changes over time with LDML changes; there is U_ICU_DATA_VERSION, but that's not in older releases, so we can only use U_ICU_VERSION. -- Edit bug report at http://bugs.php.net/bug.php?id=54561&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54561&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54561&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54561&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54561&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54561&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54561&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54561&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54561&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54561&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54561&r=support Expected behavior: http://bugs.php.net/fix.php?id=54561&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54561&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54561&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54561&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54561&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54561&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54561&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54561&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54561&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54561&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54561&r=mysqlcfg
Req #54561 [Opn->Asn]: Expose ICU version info
Edit report at http://bugs.php.net/bug.php?id=54561&edit=1 ID: 54561 Updated by: johan...@php.net Reported by:david dot zuelke at bitextender dot com Summary:Expose ICU version info -Status: Open +Status: Assigned Type: Feature/Change Request Package:*Languages/Translation Operating System: Mac OS X 10.6.7 PHP Version:5.3.6 -Assigned To: +Assigned To:stas Block user comment: N Private report: N Previous Comments: [2011-04-18 18:17:52] david dot zuelke at bitextender dot com Description: It should be possible to detect the ICU version number - this is important in order to figure out what the structure of the data is, since that changes over time with LDML changes; there is U_ICU_DATA_VERSION, but that's not in older releases, so we can only use U_ICU_VERSION. -- Edit this bug report at http://bugs.php.net/bug.php?id=54561&edit=1
Bug #54025 [Opn->Dup]: ResourceBundle fails to read files with uppercase characters
Edit report at http://bugs.php.net/bug.php?id=54025&edit=1
ID: 54025
Updated by: johan...@php.net
Reported by:bschussek at gmail dot com
Summary:ResourceBundle fails to read files with uppercase
characters
-Status: Open
+Status: Duplicate
Type: Bug
Package:I18N and L10N related
Operating System: Ubuntu 10.10
PHP Version:5.3SVN-2011-02-15 (snap)
Block user comment: N
Private report: N
New Comment:
As David said :-)
Previous Comments:
[2011-04-18 14:53:16] david dot zuelke at bitextender dot com
Duplicate of http://bugs.php.net/54540
[2011-02-15 14:28:28] bschussek at gmail dot com
Description:
A bundle named "supplementalData" can't be read by ResourceBundle. If
the bundle
is named "supplementaldata" instead, loading works.
To reproduce, create a supplementalData.txt with this content:
--- BEGIN ---
supplementalData{
}
--- END ---
Then run genrb on the CLI:
$ genrb supplementalData.txt
which will generate a supplementalData.res needed by the test. genrb
will output
a warning, but you can ignore that for the purpose of this test.
Test script:
---
http://bugs.php.net/bug.php?id=54025&edit=1
Bug #53669 [Com]: PHP does not return memory to system
Edit report at http://bugs.php.net/bug.php?id=53669&edit=1
ID: 53669
Comment by: jeffwhiting at hotmail dot com
Reported by:jille at hexon dot cx
Summary:PHP does not return memory to system
Status: Wont fix
Type: Bug
Package:Scripting Engine problem
Operating System: Linux 2.6.29.2-smp
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
Is allocating memory really that much of a performance hit? It seems
like allocating memory is pretty cheap. I could see a large performance
hit if you were defragmenting the heap. Also something like that would
be easily tunable via php.ini so users could choose if they wanted the
performance penalty.
We are currently working around the situation by using the following
prepend file. What it does is monitor's the memory usage and tells the
apache child to gracefully terminate after you get above a memory usage
threshold. Sorry jille it is only useful with the apache sapi.
Honestly it is a pretty ugly hack but it works...
apache memory monitor: ".
// "using $memUseMB MB of $maxMem MB.");
if ($memUseMB > $maxMem && function_exists('posix_kill'))
{
error_log(getmypid()."> apache memory monitor: ".
"$memUseMB MB > $maxMem MB. Sending graceful stop.");
// Terminate Apache 2 child process after request has been
// done by sending a SIGUSR1 POSIX signal (10) which
// is a graceful stop.
function killApacheChildOnExit()
{
error_log('posix_kill: '.getmypid());
posix_kill( getmypid(), 10 );
}
register_shutdown_function( 'killApacheChildOnExit' );
}
?>
Previous Comments:
[2011-04-12 22:40:42] jille at hexon dot cx
I understand it won't be possible to free all of the used memory, mostly
due to
fragmentation. Our scripts use over 100MB of memory and I don't believe
every
page is used.
When looking at zend_alloc.c in _zend_mm_free_int: (5.3.6)
if (ZEND_MM_IS_FIRST_BLOCK(mm_block) &&
ZEND_MM_IS_GUARD_BLOCK(ZEND_MM_BLOCK_AT(mm_block, size))) {
zend_mm_del_segment(heap, (zend_mm_segment *) ((char *)mm_block -
ZEND_MM_AL
IGNED_SEGMENT_SIZE));
} else [...]
Shouldn't that free every segment no longer used? As segments are 2MB by
default, it could be possible there are some parts used in every
segment, but I
don't think that is very likely when running over hundreds of
megabytes.
If above isn't suppose to "fix my problem", would it be possible to
create a
function that checks whether it can remove any segments? That way the
performance hit can be controlled.
[2011-04-12 22:17:07] ras...@php.net
There are plenty random things that stay on the heap across requests.
Persistent
connections, the statcache and a number of other things, so it is pretty
much
impossible to do this in a heap-based allocator. For mmap stuff it would
be
technically possible, but again, the performance hit for doing so would
be pretty
nasty.
[2011-04-12 21:42:10] jille at hexon dot cx
When looking at zend_alloc.c it seems to support several memory
allocators. As
far as I know when you munmap() pages they should be returned to the
system. Am I
looking in the wrong page and is the problem somewhere the munmap()?
We are using the CLI sapi instead of the Apache sapi as jeffwhiting
does.
[2011-04-12 19:58:56] jeffwhiting at hotmail dot com
Thanks for the reply. What you're saying makes sense and I understand
how difficult it would be to it across operating systems as they handle
things very differently. However the one thing I don't understand
(sorry about my ignorance) is why it can't just free everything when the
request ends? That way you don't have to worry about the 1mb sitting at
the top of the heap. The request is done so we don't need to keep
anything around.
I also tried playing around with apache's MaxFreeMem
(http://httpd.apache.org/docs/2.0/mod/mpm_common.html#maxmemfree) as it
seemed applicable but to no avail.
We also have a hard time farming off the requests as the entire
application is heavily object oriented. So the circular reference heap
allocation issue (as shown in the bug) ends up being a big deal for us.
We are actively working on reducing our memory foot print which should
help some.
[2011-04-12 18:48:16] ras...@php.net
There is no clean and portable way to do this across the various
operating
systems. Even on a single operating system like Linux, returning heap
memory
back
to the system after a process has touched it is extremely tricky. Yo
Bug #53669 [Wfx]: PHP does not return memory to system
Edit report at http://bugs.php.net/bug.php?id=53669&edit=1
ID: 53669
Updated by: ras...@php.net
Reported by:jille at hexon dot cx
Summary:PHP does not return memory to system
Status: Wont fix
Type: Bug
Package:Scripting Engine problem
Operating System: Linux 2.6.29.2-smp
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
Yes, it is a significant performance hit, and you should have a look at
the
apache_child_terminate() function.
Previous Comments:
[2011-04-18 20:43:35] jeffwhiting at hotmail dot com
Is allocating memory really that much of a performance hit? It seems
like allocating memory is pretty cheap. I could see a large performance
hit if you were defragmenting the heap. Also something like that would
be easily tunable via php.ini so users could choose if they wanted the
performance penalty.
We are currently working around the situation by using the following
prepend file. What it does is monitor's the memory usage and tells the
apache child to gracefully terminate after you get above a memory usage
threshold. Sorry jille it is only useful with the apache sapi.
Honestly it is a pretty ugly hack but it works...
apache memory monitor: ".
// "using $memUseMB MB of $maxMem MB.");
if ($memUseMB > $maxMem && function_exists('posix_kill'))
{
error_log(getmypid()."> apache memory monitor: ".
"$memUseMB MB > $maxMem MB. Sending graceful stop.");
// Terminate Apache 2 child process after request has been
// done by sending a SIGUSR1 POSIX signal (10) which
// is a graceful stop.
function killApacheChildOnExit()
{
error_log('posix_kill: '.getmypid());
posix_kill( getmypid(), 10 );
}
register_shutdown_function( 'killApacheChildOnExit' );
}
?>
[2011-04-12 22:40:42] jille at hexon dot cx
I understand it won't be possible to free all of the used memory, mostly
due to
fragmentation. Our scripts use over 100MB of memory and I don't believe
every
page is used.
When looking at zend_alloc.c in _zend_mm_free_int: (5.3.6)
if (ZEND_MM_IS_FIRST_BLOCK(mm_block) &&
ZEND_MM_IS_GUARD_BLOCK(ZEND_MM_BLOCK_AT(mm_block, size))) {
zend_mm_del_segment(heap, (zend_mm_segment *) ((char *)mm_block -
ZEND_MM_AL
IGNED_SEGMENT_SIZE));
} else [...]
Shouldn't that free every segment no longer used? As segments are 2MB by
default, it could be possible there are some parts used in every
segment, but I
don't think that is very likely when running over hundreds of
megabytes.
If above isn't suppose to "fix my problem", would it be possible to
create a
function that checks whether it can remove any segments? That way the
performance hit can be controlled.
[2011-04-12 22:17:07] ras...@php.net
There are plenty random things that stay on the heap across requests.
Persistent
connections, the statcache and a number of other things, so it is pretty
much
impossible to do this in a heap-based allocator. For mmap stuff it would
be
technically possible, but again, the performance hit for doing so would
be pretty
nasty.
[2011-04-12 21:42:10] jille at hexon dot cx
When looking at zend_alloc.c it seems to support several memory
allocators. As
far as I know when you munmap() pages they should be returned to the
system. Am I
looking in the wrong page and is the problem somewhere the munmap()?
We are using the CLI sapi instead of the Apache sapi as jeffwhiting
does.
[2011-04-12 19:58:56] jeffwhiting at hotmail dot com
Thanks for the reply. What you're saying makes sense and I understand
how difficult it would be to it across operating systems as they handle
things very differently. However the one thing I don't understand
(sorry about my ignorance) is why it can't just free everything when the
request ends? That way you don't have to worry about the 1mb sitting at
the top of the heap. The request is done so we don't need to keep
anything around.
I also tried playing around with apache's MaxFreeMem
(http://httpd.apache.org/docs/2.0/mod/mpm_common.html#maxmemfree) as it
seemed applicable but to no avail.
We also have a hard time farming off the requests as the entire
application is heavily object oriented. So the circular reference heap
allocation issue (as shown in the bug) ends up being a big deal for us.
We are actively working on reducing our memory foot print which should
help some.
The remainder of the comments for this rep
[PHP-BUG] Bug #54563 [NEW]: invalid crt parameters on stream_select
From: Operating system: windows 7 PHP version: 5.3.6 Package: Streams related Bug Type: Bug Bug description:invalid crt parameters on stream_select Description: Apparently there are some errors selecting streams on windows platforms when calling some native win functions. linux wouldnt reproduce 5.3.6 vc9 Test script: --- http://bugs.php.net/bug.php?id=54563&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54563&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54563&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54563&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54563&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54563&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54563&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54563&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54563&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54563&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54563&r=support Expected behavior: http://bugs.php.net/fix.php?id=54563&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54563&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54563&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54563&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54563&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54563&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54563&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54563&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54563&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54563&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54563&r=mysqlcfg
Bug #54559 [Bgs]: php ignoring date.timezone setting
Edit report at http://bugs.php.net/bug.php?id=54559&edit=1
ID: 54559
User updated by:jistanidiot at gmail dot com
Reported by:jistanidiot at gmail dot com
Summary:php ignoring date.timezone setting
Status: Bogus
Type: Bug
Package:Date/time related
Operating System: RHEL 6
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Ah you're right it is looking for php.ini in /usr/local/etc which is not
the right place. I've recompiled and added the option
--with-config-file-path=/etc and now everything is good. Thanks!
Previous Comments:
[2011-04-18 17:44:18] dtajchre...@php.net
Are you modifying the right configuration file for the SAPI you're
using?
phpinfo() and php --ini will show you which configuration files are
loaded... is
that the file you have date.timezone = "America/New_York" in?
[2011-04-18 17:05:40] jistanidiot at gmail dot com
Description:
In my php.ini file I have
date.timezone = "America/New_York"
However I keep getting the error
Warning: phpinfo() [function.phpinfo]: It is not safe to rely on the
system's timezone settings. You are *required* to use the date.timezone
setting or the date_default_timezone_set() function. In case you used
any of those methods and you are still getting this warning, you most
likely misspelled the timezone identifier. We selected
'America/New_York' for 'EDT/-4.0/DST' instead in
/var/www/html/gallery3/test.php on line 2
and this isn't just for phpinfo but everything I've tried dealing with
dates and times.
The only workaround I've found is to put
date_default_timezone_set('America/New_York');
at the start of all my scripts.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54559&edit=1
Req #41310 [Opn->Csd]: make extension_dir optional and use absolute paths in "extension = ..."
Edit report at http://bugs.php.net/bug.php?id=41310&edit=1 ID: 41310 Updated by: johan...@php.net Reported by:mastamind at users dot sourceforge dot net Summary:make extension_dir optional and use absolute paths in "extension = ..." -Status: Open +Status: Closed Type: Feature/Change Request Package:PHP options/info functions Operating System: * PHP Version:* -Assigned To: +Assigned To:johannes Block user comment: N Private report: N New Comment: That was fixed with PHP 5.3.0 Previous Comments: [2011-04-18 16:46:57] tyra3l at gmail dot com it works for me with 5.3.6: extension /usr/lib/php5/20090626/pdo.so correctly loads the pdo extension from the absolute path. Tyrael [2010-12-29 11:45:59] j...@php.net See also bug #9095 [2007-05-07 00:44:27] mastamind at users dot sourceforge dot net Description: using extension_dir = "/usr/local/lib/php" extension = "../pgsql.so" makes php search for pgsql.so in /usr/local/lib. It would be nice if php allows absolute paths for extension loading: extension = /usr/local/lib/pgsql.so as specifing it relative to the extension_dir is quite strange and probably makes extension_dir useless. specifing absolute paths with dl() may result in a security problem, but using it in php.ini may be ok. -- Edit this bug report at http://bugs.php.net/bug.php?id=41310&edit=1
Req #47802 [Com]: PDO_MYSQL doesn't use the charset parameter
Edit report at http://bugs.php.net/bug.php?id=47802&edit=1
ID: 47802
Comment by: ircmaxell at gmail dot com
Reported by:disbursement at dublin dot com
Summary:PDO_MYSQL doesn't use the charset parameter
Status: Closed
Type: Feature/Change Request
Package:MySQL related
Operating System: all
PHP Version:5.2.9
Assigned To:kalle
Block user comment: N
Private report: N
New Comment:
Re-opening this as it has security implications for 5.2.x. It should be
backported and re-released as a security fix for 5.2.x.
As it stands now, PDO::quote() does not protect against security
vulnerabilities
without the ability to set the character set in the C api. 5.3.6 closes
this
hole when supplied with the optional charset parameter (by appropriately
setting
the character set). However this will need to be expressed in the
documentation
(I will file another issue on this topic).
Proof Of Concept Code:
$dsn = 'mysql:dbname=INFORMATION_SCHEMA;host=127.0.0.1;charset=GBK';
$pdo = new PDO($dsn, $user, $pass);
$pdo->exec('SET NAMES GBK');
$string = chr(0xbf) . chr(0x27) . ' OR 1 = 1; /*';
$sql = "SELECT TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME LIKE ".$pdo->quote($string).";";
$stmt = $pdo->query($sql);
var_dump($stmt->rowCount());
Expected: int(0)
Actual: the number of tables on the server
Previous Comments:
[2011-01-17 11:46:00] ka...@php.net
Will appear in PHP 5.3.6 :)
[2011-01-17 10:54:23] ka...@php.net
Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revision&revision=307529
Log: MFT: Implemented FR #47802 (Support for setting character sets in
DSN strings)
[2011-01-07 18:18:31] ka...@php.net
Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revision&revision=307228
Log: Added test case for #47802 and fixed macro name after the move to
mysql_options()
[2011-01-07 15:40:32] ka...@php.net
Implemented in trunk for now
[2011-01-07 15:39:58] ka...@php.net
Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revision&revision=307224
Log: Implemented FR #47802, support for character sets in DSN strings
for PDO_MYSQL
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=47802
--
Edit this bug report at http://bugs.php.net/bug.php?id=47802&edit=1
Req #47802 [Csd->ReO]: PDO_MYSQL doesn't use the charset parameter
Edit report at http://bugs.php.net/bug.php?id=47802&edit=1
ID: 47802
Updated by: col...@php.net
Reported by:disbursement at dublin dot com
Summary:PDO_MYSQL doesn't use the charset parameter
-Status: Closed
+Status: Re-Opened
Type: Feature/Change Request
Package:MySQL related
Operating System: all
PHP Version:5.2.9
Assigned To:kalle
Block user comment: N
Private report: N
New Comment:
Re-opening because of 5_2 backport request by some user.
Previous Comments:
[2011-04-18 22:34:03] ircmaxell at gmail dot com
Re-opening this as it has security implications for 5.2.x. It should be
backported and re-released as a security fix for 5.2.x.
As it stands now, PDO::quote() does not protect against security
vulnerabilities
without the ability to set the character set in the C api. 5.3.6 closes
this
hole when supplied with the optional charset parameter (by appropriately
setting
the character set). However this will need to be expressed in the
documentation
(I will file another issue on this topic).
Proof Of Concept Code:
$dsn = 'mysql:dbname=INFORMATION_SCHEMA;host=127.0.0.1;charset=GBK';
$pdo = new PDO($dsn, $user, $pass);
$pdo->exec('SET NAMES GBK');
$string = chr(0xbf) . chr(0x27) . ' OR 1 = 1; /*';
$sql = "SELECT TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME LIKE ".$pdo->quote($string).";";
$stmt = $pdo->query($sql);
var_dump($stmt->rowCount());
Expected: int(0)
Actual: the number of tables on the server
[2011-01-17 11:46:00] ka...@php.net
Will appear in PHP 5.3.6 :)
[2011-01-17 10:54:23] ka...@php.net
Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revision&revision=307529
Log: MFT: Implemented FR #47802 (Support for setting character sets in
DSN strings)
[2011-01-07 18:18:31] ka...@php.net
Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revision&revision=307228
Log: Added test case for #47802 and fixed macro name after the move to
mysql_options()
[2011-01-07 15:40:32] ka...@php.net
Implemented in trunk for 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=47802
--
Edit this bug report at http://bugs.php.net/bug.php?id=47802&edit=1
[PHP-BUG] Req #54564 [NEW]: extension_dir should be used for loading zend_extensions
From: Operating system: PHP version: 5.3.6 Package: Scripting Engine problem Bug Type: Feature/Change Request Bug description:extension_dir should be used for loading zend_extensions Description: I've brought this topic on the internals http://marc.info/?l=php-internals&m=130314285822279&w=2 and I think that it would be useful and more consistent, if this could be changed, so one could easily load both "normal" and zend extensions without the need to use absolute paths. Test script: --- php -n -d zend_extension=xdebug.so -r '' Actual result: -- Failed loading xdebug.so: xdebug.so: cannot open shared object file: No such file or directory -- Edit bug report at http://bugs.php.net/bug.php?id=54564&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54564&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54564&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54564&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54564&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54564&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54564&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54564&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54564&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54564&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54564&r=support Expected behavior: http://bugs.php.net/fix.php?id=54564&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54564&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54564&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54564&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54564&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54564&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54564&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54564&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54564&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54564&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54564&r=mysqlcfg
[PHP-BUG] Bug #54565 [NEW]: E_STRICT errors shown even if display_errors is off
From: Operating system: PHP version: 5.3.6 Package: Unknown/Other Function Bug Type: Bug Bug description:E_STRICT errors shown even if display_errors is off Description: If you set error_reporting to E_ALL | E_STRICT through php.ini and set display_errors to false through .htaccess, no errors should be displayed at all, regardless of the error_reporting setting. Instead, e_strict warnings are still shown. Note that I am not disabling display_errors at runtime (that would be expected behavior since most e_strict errors are generated at compile time): I am disabling display_error with .htaccess. The workaround is to exclude E_STRICT from error reporting but what if one wants them to be reported (e.g. logged) but not displayed? -- Edit bug report at http://bugs.php.net/bug.php?id=54565&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54565&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54565&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54565&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54565&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54565&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54565&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54565&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54565&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54565&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54565&r=support Expected behavior: http://bugs.php.net/fix.php?id=54565&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54565&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54565&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54565&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54565&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54565&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54565&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54565&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54565&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54565&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54565&r=mysqlcfg
Req #47802 [ReO->Tbd]: PDO_MYSQL doesn't use the charset parameter
Edit report at http://bugs.php.net/bug.php?id=47802&edit=1
ID: 47802
Updated by: johan...@php.net
Reported by:disbursement at dublin dot com
Summary:PDO_MYSQL doesn't use the charset parameter
-Status: Re-Opened
+Status: To be documented
Type: Feature/Change Request
Package:MySQL related
Operating System: all
PHP Version:5.2.9
-Assigned To:kalle
+Assigned To:
Block user comment: N
Private report: N
New Comment:
If a developer shots himself it is noting we can prevent. Tis does not
justify a security release of PHP as the only one who can exploit this
is the one writing code ...
This should however be made clear in the documentation: Executing SET
NAMES doesn't tell anything to the client library (libmysql / mysqlnd
used by PHP) so they can't do proper encoding. Therefore only Latin 1,
Utf-8 and other encodings using lower 7 bits in an ASCII compatible way
can be used safely. For other encodings the mentioned option, introduced
later in 5.3.6 should be used.
Previous Comments:
[2011-04-18 22:38:48] col...@php.net
Re-opening because of 5_2 backport request by some user.
[2011-04-18 22:34:03] ircmaxell at gmail dot com
Re-opening this as it has security implications for 5.2.x. It should be
backported and re-released as a security fix for 5.2.x.
As it stands now, PDO::quote() does not protect against security
vulnerabilities
without the ability to set the character set in the C api. 5.3.6 closes
this
hole when supplied with the optional charset parameter (by appropriately
setting
the character set). However this will need to be expressed in the
documentation
(I will file another issue on this topic).
Proof Of Concept Code:
$dsn = 'mysql:dbname=INFORMATION_SCHEMA;host=127.0.0.1;charset=GBK';
$pdo = new PDO($dsn, $user, $pass);
$pdo->exec('SET NAMES GBK');
$string = chr(0xbf) . chr(0x27) . ' OR 1 = 1; /*';
$sql = "SELECT TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME LIKE ".$pdo->quote($string).";";
$stmt = $pdo->query($sql);
var_dump($stmt->rowCount());
Expected: int(0)
Actual: the number of tables on the server
[2011-01-17 11:46:00] ka...@php.net
Will appear in PHP 5.3.6 :)
[2011-01-17 10:54:23] ka...@php.net
Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revision&revision=307529
Log: MFT: Implemented FR #47802 (Support for setting character sets in
DSN strings)
[2011-01-07 18:18:31] ka...@php.net
Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revision&revision=307228
Log: Added test case for #47802 and fixed macro name after the move to
mysql_options()
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=47802
--
Edit this bug report at http://bugs.php.net/bug.php?id=47802&edit=1
Req #47802 [Com]: PDO_MYSQL doesn't use the charset parameter
Edit report at http://bugs.php.net/bug.php?id=47802&edit=1
ID: 47802
Comment by: ircmaxell at gmail dot com
Reported by:disbursement at dublin dot com
Summary:PDO_MYSQL doesn't use the charset parameter
Status: To be documented
Type: Feature/Change Request
Package:MySQL related
Operating System: all
PHP Version:5.2.9
Block user comment: N
Private report: N
New Comment:
I won't argue the decision, but I'd like to clarify one point. Right
now, in
5.2.x (and <=5.3.5) it's impossible to write a secure query using
PDO::quote. So
if you use another character set, it would automatically make all code
vulnerable
to SQL Injection (with no built-in method to fix it). So that leaves
existing
the code 3 options: Switch to MySQLi, Implement their own quoting
mechanism, or
switch to prepared statements (the best solution). But as it stands,
the API
does not deliver its promise.
Just an observation...
Previous Comments:
[2011-04-19 01:07:20] johan...@php.net
If a developer shots himself it is noting we can prevent. Tis does not
justify a security release of PHP as the only one who can exploit this
is the one writing code ...
This should however be made clear in the documentation: Executing SET
NAMES doesn't tell anything to the client library (libmysql / mysqlnd
used by PHP) so they can't do proper encoding. Therefore only Latin 1,
Utf-8 and other encodings using lower 7 bits in an ASCII compatible way
can be used safely. For other encodings the mentioned option, introduced
later in 5.3.6 should be used.
[2011-04-18 22:38:48] col...@php.net
Re-opening because of 5_2 backport request by some user.
[2011-04-18 22:34:03] ircmaxell at gmail dot com
Re-opening this as it has security implications for 5.2.x. It should be
backported and re-released as a security fix for 5.2.x.
As it stands now, PDO::quote() does not protect against security
vulnerabilities
without the ability to set the character set in the C api. 5.3.6 closes
this
hole when supplied with the optional charset parameter (by appropriately
setting
the character set). However this will need to be expressed in the
documentation
(I will file another issue on this topic).
Proof Of Concept Code:
$dsn = 'mysql:dbname=INFORMATION_SCHEMA;host=127.0.0.1;charset=GBK';
$pdo = new PDO($dsn, $user, $pass);
$pdo->exec('SET NAMES GBK');
$string = chr(0xbf) . chr(0x27) . ' OR 1 = 1; /*';
$sql = "SELECT TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME LIKE ".$pdo->quote($string).";";
$stmt = $pdo->query($sql);
var_dump($stmt->rowCount());
Expected: int(0)
Actual: the number of tables on the server
[2011-01-17 11:46:00] ka...@php.net
Will appear in PHP 5.3.6 :)
[2011-01-17 10:54:23] ka...@php.net
Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revision&revision=307529
Log: MFT: Implemented FR #47802 (Support for setting character sets in
DSN strings)
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=47802
--
Edit this bug report at http://bugs.php.net/bug.php?id=47802&edit=1
[PHP-BUG] Bug #54566 [NEW]: bug into recursive function
From: Operating system: Linux,Windows PHP version: Irrelevant Package: Output Control Bug Type: Bug Bug description:bug into recursive function Description: When you try to make recursive function and send the counter directly. you have an error, to fix this, you need increment before the counter, and after send this counter. Test script: --- Expected result: 1 2 3 4 5 6 7 8 ... 97 98 99 100 End Process Actual result: -- 0...000 Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 523800 bytes) in /home/paridin/public_html/bug.php on line 5 -- Edit bug report at http://bugs.php.net/bug.php?id=54566&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54566&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54566&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54566&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54566&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54566&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54566&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54566&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54566&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54566&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54566&r=support Expected behavior: http://bugs.php.net/fix.php?id=54566&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54566&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54566&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54566&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54566&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54566&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54566&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54566&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54566&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54566&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54566&r=mysqlcfg
Bug #54566 [Opn->Bgs]: bug into recursive function
Edit report at http://bugs.php.net/bug.php?id=54566&edit=1 ID: 54566 Updated by: dtajchre...@php.net Reported by:paridin at paridin dot com Summary:bug into recursive function -Status: Open +Status: Bogus Type: Bug Package:Output Control Operating System: Linux,Windows PHP Version:Irrelevant Block user comment: N Private report: N New Comment: return foo(++$i); instead of return foo($i++); foo($i++); will always call foo(0); Previous Comments: [2011-04-19 02:10:49] paridin at paridin dot com Description: When you try to make recursive function and send the counter directly. you have an error, to fix this, you need increment before the counter, and after send this counter. Test script: --- Expected result: 1 2 3 4 5 6 7 8 ... 97 98 99 100 End Process Actual result: -- 0...000 Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 523800 bytes) in /home/paridin/public_html/bug.php on line 5 -- Edit this bug report at http://bugs.php.net/bug.php?id=54566&edit=1
Bug #54566 [Com]: bug into recursive function
Edit report at http://bugs.php.net/bug.php?id=54566&edit=1 ID: 54566 Comment by: paridin at paridin dot com Reported by:paridin at paridin dot com Summary:bug into recursive function Status: Bogus Type: Bug Package:Output Control Operating System: Linux,Windows PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Yes, dtajchreber, this behavior is very rarely 'cause into python work well, but into C or PHP not run, i tested this same example into this three languages but, maybe Python support the bad logic, and i thinking i have a bad logic when i try send a counter while increment this. thanks for the fast answer. Previous Comments: [2011-04-19 02:58:19] dtajchre...@php.net return foo(++$i); instead of return foo($i++); foo($i++); will always call foo(0); [2011-04-19 02:10:49] paridin at paridin dot com Description: When you try to make recursive function and send the counter directly. you have an error, to fix this, you need increment before the counter, and after send this counter. Test script: --- Expected result: 1 2 3 4 5 6 7 8 ... 97 98 99 100 End Process Actual result: -- 0...000 Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 523800 bytes) in /home/paridin/public_html/bug.php on line 5 -- Edit this bug report at http://bugs.php.net/bug.php?id=54566&edit=1
[PHP-BUG] Req #54567 [NEW]: DateTimeZone does not serialize
From:
Operating system: -
PHP version: 5.3.6
Package: Date/time related
Bug Type: Feature/Change Request
Bug description:DateTimeZone does not serialize
Description:
http://bugs.php.net/bug.php?id=41334 -- DateTime serialization was added in
PHP 5.3, but DateTimeZone still serializes to an empty object, it's
serialized string is always:
O:12:"DateTimeZone":0:{}
Test script:
---
getName()."\n";
$x = serialize($x);
$x = unserialize($x);
echo $x->getName()."\n";
?>
Expected result:
Australia/Victoria
Australia/Victoria
Actual result:
--
Australia/Victoria
PHP Warning: DateTimeZone::getName(): The DateTimeZone object has not been
correctly initialized by its constructor in - on line 7
Warning: DateTimeZone::getName(): The DateTimeZone object has not been
correctly initialized by its constructor in - on line 7
--
Edit bug report at http://bugs.php.net/bug.php?id=54567&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54567&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54567&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54567&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54567&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54567&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54567&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54567&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54567&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54567&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54567&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54567&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54567&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54567&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54567&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54567&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54567&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54567&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54567&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54567&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54567&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54567&r=mysqlcfg
Req #54550 [Opn->Wfx]: mail.log
Edit report at http://bugs.php.net/bug.php?id=54550&edit=1 ID: 54550 Updated by: ahar...@php.net Reported by:mv at zvyk dot com Summary:mail.log -Status: Open +Status: Wont fix Type: Feature/Change Request -Package:*General Issues +Package:Mail related Operating System: Linux 2.6.31-gentoo-r PHP Version:5.3.6 Block user comment: N Private report: N New Comment: I don't see any reason to complicate what's meant to be a simple debugging aid with different output formats. Previous Comments: [2011-04-17 19:04:06] mv at zvyk dot com Description: --- >From manual page: http://www.php.net/mail.configuration --- [mail function] ;as well as it is mail.log = /filename.log ;log record format (to add timestamp | full date ...) . . ;log in csv?? mail.log_format = [default|csv|...] = from: mail() on [/dir/subdir/script.php:259]: To: -_...@x.com -- Headers: From: x...@zvyk.com to: [Sun Apr 17 18:35:55 2011] mail() on [/dir/subdir/script.php:259]: To: -_...@x.com -- Headers: From: x...@zvyk.com or to(csv format): 2011-04-17; 18:35:55; mail(); /dir/subdir/script.php; 259; To: -_...@x.com; Headers: From: x...@zvyk.com Expected result: from: mail() on [/dir/subdir/script.php:259]: To: -_...@x.com -- Headers: From: x...@zvyk.com to: [Sun Apr 17 18:35:55 2011] mail() on [/dir/subdir/script.php:259]: To: -_...@x.com -- Headers: From: x...@zvyk.com -- Edit this bug report at http://bugs.php.net/bug.php?id=54550&edit=1
Bug #54534 [Opn->Wfx]: Sessions fail when running PHP as multiple users
Edit report at http://bugs.php.net/bug.php?id=54534&edit=1 ID: 54534 Updated by: ahar...@php.net Reported by:fredrik at dolda2000 dot com Summary:Sessions fail when running PHP as multiple users -Status: Open +Status: Wont fix Type: Bug Package:Session related Operating System: Debian PHP Version:trunk-SVN-2011-04-14 (snap) Block user comment: N Private report: N New Comment: You can already handle this corner case with a custom session handler. I don't think it's a common enough problem in practice to justify changing the long-standing behaviour of PHP's default session handler. Previous Comments: [2011-04-14 16:29:48] fredrik at dolda2000 dot com Description: I'm running a website on which PHP runs as multiple different users on the operating system, and I'm encountering problems when a visitor to the site goes from a part where PHP runs as one user to another part where PHP runs as another user. Since PHP saves all sessions in one directory, it will attempt to load the same session data as long as the visitor uses the same SID. When the session was created by one user, it cannot be loaded by another. That is of course, in itself, as it should. I would argue, however, that the session filenames should contain the UID of the user running PHP, so as to remove such conflicts. The resultant behavior is probably reasonable, as the different users running PHP will most likely not want to share session data with each other. -- Edit this bug report at http://bugs.php.net/bug.php?id=54534&edit=1
Bug #54527 [Opn->Fbk]: When %00 on POST deletes key-value pair
Edit report at http://bugs.php.net/bug.php?id=54527&edit=1
ID: 54527
Updated by: ahar...@php.net
Reported by:qiq9 at eloy dot serralaban dot com dot ar
Summary:When %00 on POST deletes key-value pair
-Status: Open
+Status: Feedback
Type: Bug
Package:Unknown/Other Function
Operating System: Linux kernel:2.6.18-194.26.1.el5
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Which SAPI, Web server and version of PHP are you using, and what is the
filter.default configuration setting set to in phpinfo()? Additionally,
do you have any extensions loaded that may change the way PHP operates,
such as Suhosin?
I can't reproduce this under Apache (using the apache2handler SAPI), for
the record.
Previous Comments:
[2011-04-14 04:12:56] qiq9 at eloy dot serralaban dot com dot ar
Description:
When posting %00, it does not add it to $_POST or $_REQUEST arrays.
Example:
POST http://kemio.com.ar/bug.php HTTP/1.1
Host: kemio.com.ar
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0b11) Gecko/20100101
Firefox/4.0b11
Content-Length: 15
Connection: Keep-Alive
uno=1%002&dos=2
Test script:
---
...
$_POST
$v)
print("$k$v\n");
?>$_SERVER
...
Expected result:
...
$_POST
uno1
dos2
$_SERVER
...
Actual result:
--
...
$_POST
dos2
$_SERVER
...
--
Edit this bug report at http://bugs.php.net/bug.php?id=54527&edit=1
Bug #54530 [Opn->Bgs]: strnatcasecmp treats alphanumeric values before symbols
Edit report at http://bugs.php.net/bug.php?id=54530&edit=1
ID: 54530
Updated by: ahar...@php.net
Reported by:chatfielddaniel at googlemail dot com
Summary:strnatcasecmp treats alphanumeric values before
symbols
-Status: Open
+Status: Bogus
Type: Bug
-Package:Unknown/Other Function
+Package:Strings related
Operating System: Windows 7
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Just like all of the other comparison functions, strnatcmp() and
strnatcasecmp() eventually fall back to a straight byte value by byte
value comparison if the "natural" alphanumeric sorting logic isn't
triggered. Since the underscore character has a higher character code
than any number or uppercase letter (and case-insensitive comparisons
are done on uppercased strings), it's always "after" letters and
numbers.
This behaviour isn't going to change.
Previous Comments:
[2011-04-14 12:59:37] chatfielddaniel at googlemail dot com
Description:
---
>From manual page: http://www.php.net/function.strnatcasecmp
---
The strnatcasecmp is set that '_' is after letters and numbers which is
illogical
and should be changed.
Test script:
---
echo strnatcasecmp('1','2');//-1
echo strnatcasecmp('_','2');//1 (incorrect)
echo strnatcasecmp('_','a');//1 (incorrect)
echo strnatcasecmp('a','b');//-1
echo strnatcasecmp(2,'a');//-1
--
Edit this bug report at http://bugs.php.net/bug.php?id=54530&edit=1
Bug #54524 [Opn->Bgs]: intval doesn't throw warning when value is bigger than the maximum allowed
Edit report at http://bugs.php.net/bug.php?id=54524&edit=1 ID: 54524 Updated by: ahar...@php.net Reported by:dosergio at ig dot com dot br Summary:intval doesn't throw warning when value is bigger than the maximum allowed -Status: Open +Status: Bogus Type: Bug Package:*General Issues Operating System: all PHP Version:Irrelevant Block user comment: N Private report: N New Comment: No, it doesn't. This is expected and documented behaviour. Previous Comments: [2011-04-13 16:17:29] dosergio at ig dot com dot br Description: If you use intval with an argument that is bigger than 2147483647 the result will always be 2147483647. That's a problem that PHP doesn't throw an Error or Warning, because at the first glance, it looks like a mistery from where comes this magic number ? If someone used intval with an argument that is bigger than 2147483647 IMHO php should die with some message like this: 'Warning: Argument too big for intval. Maximum allowed is 2147483647' or 'Error: Argument too big for intval. Maximum allowed is 2147483647' I lost almost one hour to discover from where the magic number came... If there was the Error or Warning, it would be MUCH EASIER to solve the problem. Test script: --- Expected result: Throwing an Error (die) or Warning showing that the argument passed for intval was TOO BIG. Actual result: -- The function does NOT give any type of hint of the problem, and returns a fixed value 2147483647 as result, DOES NOT MATTER what the argument is, as long as it is bigger than 2147483647... -- Edit this bug report at http://bugs.php.net/bug.php?id=54524&edit=1
