Bug #51949 [Com]: open_basedir and move_uploaded_file does not harmonize!
Edit report at https://bugs.php.net/bug.php?id=51949&edit=1
ID: 51949
Comment by: jo at feuersee dot de
Reported by:lars dot plessmann at gmx dot de
Summary:open_basedir and move_uploaded_file does not
harmonize!
Status: Open
Type: Bug
Package:Filesystem function related
Operating System: Linux h1638833 2.6.18-028stab064
PHP Version:5.3.2
Block user comment: N
Private report: N
New Comment:
See http://open.silverstripe.org/ticket/5547
I'd say it's an application level bug (in this case silverstripe), not a PHP
bug.
Both move_uploaded_file and is_uploaded_file expect the 1st param to be the
unmodified temp filename inside upload_dir, but siverstripe copies the
uploaded file and then uses these function, thus they always fail.
A patch is avail
Previous Comments:
[2010-05-30 19:28:07] lars dot plessmann at gmx dot de
Description:
I have several vhosts and I'd like to use the open_basedir setting for them.
My PHP config is something like that:
Directive | Local Value | Master Value
[...]
safe_mode | Off | Off
safe_mode_exec_dir | /usr/local/php/bin | /usr/local/php/bin
safe_mode_gid | Off | Off
safe_mode_include_dir | no value | no value
upload_tmp_dir | /tmp | /tmp
open_basedir | /srv/www/vhosts/domain.tld/httpdocs;/tmp | no value
[...]
When I upload files, they do get in /tmp directory and have the privilege:
-rw-r--r-- 1 wwwrun www 647585 30. Mai 15:43 demo.jpg
The move_uploaded_file function with using absolute directories and correct
paths (I proofed this) returns always false on my PHP 5.3.1 and PHP 5.3.2
compilation!
The target directory has full rwx privileges for all user/group/others and
there is not a filesystem privilege problem!
The php log files are not very verbose, in fact, it tells me nothing about the
failed movement (also tried with report_error = E_ALL).
If I use rename instead of move_uploaded_file, PHP seems to move the file.
Test script:
---
// assumes the upload is successfully done (I can see the file in
// in the filesystem with the privileges: -rw-r--r-- 1 wwwrun www).
[...]
if(move_uploaded_file("/tmp/silverstripe-cache-srv-www-vhosts-domain.tld-httpdocs-silverstripe-v2.4.0/demo.jpg",
"/srv/www/vhosts/domain.tld/httpdocs/silverstripe-4.2.0/assets/Upload/demo.jpg"))
{
return true;
} else {
return false;
}
[...]
Expected result:
I expect that the file can be moved with the move_uploaded_file from /tmp to
the /srv/www/vhosts/domain.tld/httpdocs/silverstripe-4.2.0/assets/Upload by PHP
(apache user wwwrun) which created the file in the directory /tmp as well (just
a few seconds before). It should take care of the open_basedir setting.
The target directory and also the source directory is specified in the
open_basedir setting.
Actual result:
--
If I overwrite the open_basedir setting for the virtual host to "none", the
upload and move_uploaded_file works fine:
Directive | Local Value | Master Value
open_basedir | no value | no value
But it's not a pretty solution for me just to turn off this security feature!
When I google I only find thousends of other people having problems with
open_basedir. :-(
--
Edit this bug report at https://bugs.php.net/bug.php?id=51949&edit=1
Bug #55439 [Asn]: crypt() returns only the salt for MD5
Edit report at https://bugs.php.net/bug.php?id=55439&edit=1
ID: 55439
User updated by: jo at feuersee dot de
Reported by: jo at feuersee dot de
Summary:crypt() returns only the salt for MD5
Status: Assigned
Type: Bug
Package:*Encryption and hash functions
Operating System: Linux
PHP Version:5.3.7RC5
Assigned To:stas
Block user comment: N
Private report: N
New Comment:
Uhm ok the PHP code wasn't correct but I think you get the point:
If crypt() only stores the salt then crypt($pw, $salt) will return the salt and
comparing this to $pw is useless as the salt is a constant regardless of $pw.
Previous Comments:
[2011-08-19 21:16:03] jo at feuersee dot de
Verified for PHP5.3.7
> php -v
PHP 5.3.7 (cli)
> php -r 'printf("%s\n", crypt("password"));'
$1$p4uaO1jN
Note that only the salt is returned.
AFAIK MD5 is the default encryption type.
The big problem is that if an application stores this hashes in a database and
uses them for authentication, the problem with this bug is that
$valid = crypt($pw, $crypt);
will always be TRUE regardless of $pw
We do have a serious problem here. I suggest recalling 5.3.7 and go for a
5.3.7pl1
[2011-08-19 11:15:37] paj...@php.net
stas, could you look at this issue please? It could be related to our latest
changes there.
[2011-08-19 11:03:37] tomp at tomp dot co dot uk
Hi,
We have also experienced this problem with the official release of PHP 5.3.7.
[2011-08-19 10:12:40] noel dot butler at ausics dot net
This is confirmed bug in stable release 5.3.7
----------------
[2011-08-17 13:03:20] jo at feuersee dot de
Description:
If crypt() is executed with MD5 salts, the return value conists of the salt
only.
DES and BLOWFISH salts work as expected.
I tested with php from openSUSE PHP5 repository
> php -v
PHP 5.3.7RC6-dev (cli)
> rpm -q php5
php5-5.3.6.201108112132-94.1.x86_64
Test script:
---
printf("MD5: %s\n", crypt('password', '$1$U7AjYB.O$'));
Expected result:
MD5: $1$U7AjYB.O$L1N7ux7twaMIMw0En8UUR1
Actual result:
--
MD5: $1$U7AjYB.O
--
Edit this bug report at https://bugs.php.net/bug.php?id=55439&edit=1
Bug #55439 [Asn]: crypt() returns only the salt for MD5
Edit report at https://bugs.php.net/bug.php?id=55439&edit=1
ID: 55439
User updated by: jo at feuersee dot de
Reported by: jo at feuersee dot de
Summary:crypt() returns only the salt for MD5
Status: Assigned
Type: Bug
Package:*Encryption and hash functions
Operating System: Linux
PHP Version:5.3.7RC5
Assigned To:stas
Block user comment: N
Private report: N
New Comment:
Verified for PHP5.3.7
> php -v
PHP 5.3.7 (cli)
> php -r 'printf("%s\n", crypt("password"));'
$1$p4uaO1jN
Note that only the salt is returned.
AFAIK MD5 is the default encryption type.
The big problem is that if an application stores this hashes in a database and
uses them for authentication, the problem with this bug is that
$valid = crypt($pw, $crypt);
will always be TRUE regardless of $pw
We do have a serious problem here. I suggest recalling 5.3.7 and go for a
5.3.7pl1
Previous Comments:
[2011-08-19 11:15:37] paj...@php.net
stas, could you look at this issue please? It could be related to our latest
changes there.
[2011-08-19 11:03:37] tomp at tomp dot co dot uk
Hi,
We have also experienced this problem with the official release of PHP 5.3.7.
[2011-08-19 10:12:40] noel dot butler at ausics dot net
This is confirmed bug in stable release 5.3.7
------------
[2011-08-17 13:03:20] jo at feuersee dot de
Description:
If crypt() is executed with MD5 salts, the return value conists of the salt
only.
DES and BLOWFISH salts work as expected.
I tested with php from openSUSE PHP5 repository
> php -v
PHP 5.3.7RC6-dev (cli)
> rpm -q php5
php5-5.3.6.201108112132-94.1.x86_64
Test script:
---
printf("MD5: %s\n", crypt('password', '$1$U7AjYB.O$'));
Expected result:
MD5: $1$U7AjYB.O$L1N7ux7twaMIMw0En8UUR1
Actual result:
--
MD5: $1$U7AjYB.O
--
Edit this bug report at https://bugs.php.net/bug.php?id=55439&edit=1
[PHP-BUG] Bug #55439 [NEW]: crypt() returns only the salt for MD5
From:
Operating system: Linux
PHP version: 5.3.7RC5
Package: *Encryption and hash functions
Bug Type: Bug
Bug description:crypt() returns only the salt for MD5
Description:
If crypt() is executed with MD5 salts, the return value conists of the salt
only.
DES and BLOWFISH salts work as expected.
I tested with php from openSUSE PHP5 repository
> php -v
PHP 5.3.7RC6-dev (cli)
> rpm -q php5
php5-5.3.6.201108112132-94.1.x86_64
Test script:
---
printf("MD5: %s\n", crypt('password', '$1$U7AjYB.O$'));
Expected result:
MD5: $1$U7AjYB.O$L1N7ux7twaMIMw0En8UUR1
Actual result:
--
MD5: $1$U7AjYB.O
--
Edit bug report at https://bugs.php.net/bug.php?id=55439&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55439&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55439&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55439&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55439&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55439&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55439&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55439&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55439&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55439&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55439&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55439&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55439&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55439&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55439&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55439&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55439&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55439&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55439&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55439&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55439&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55439&r=mysqlcfg
Bug #55189 [Opn]: BC break in behavior of is_a() (1st param '' no longer accepted)
Edit report at https://bugs.php.net/bug.php?id=55189&edit=1
ID: 55189
User updated by: jo at feuersee dot de
Reported by: jo at feuersee dot de
-Summary:BC break in behavior of is_a()
+Summary:BC break in behavior of is_a() (1st param '' no
longer accepted)
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.3SVN-2011-07-12 (SVN)
Block user comment: N
Private report: N
New Comment:
Changed subject to reflect that the 1st param is the important one.
Previous Comments:
[2011-07-12 11:54:20] jo at feuersee dot de
Description:
I notice a different bahavior between PHP5.3.6 and a daily build supplied by
the openSUSE build service, designated php5-5.3.6.201107111820-83.1 with php -
output is "PHP 5.3.7RC3-dev (cli)"
In short, is_a('', '') emits a warning with php/5.3.7rc3 which did not happen
with 5.3.6 and AFAIK earlier versions.
I know that is_a('', '') doesn't make much sense, but it's a BC break. To be
more precise, I stumbled across this when upgrading a PEAR repo and to my
surprise got a bunch of warnings (Warning: Unknown class passed as parameter in
/usr/share/php5/PEAR/PEAR.php on line 252) and tracked it down to the is_a()
call.
I'm not really sure if this was planned and/or is a documentation issue, but
just to be sure it is an intentional change I put this here to be discussed.
AFAIK from reading the php.internals mailing list, such a change in behavior in
a minor update is most likely not intentional ;)
Test script:
---
In a shell type the following:
php -r 'printf("%d\n", is_a("", ""));'
(Note: in case of Windows OS the ' and " have to be replaced with each other)
Expected result:
0
Actual result:
--
Warning: Unknown class passed as parameter in Command line code on line 1
0
--
Edit this bug report at https://bugs.php.net/bug.php?id=55189&edit=1
[PHP-BUG] Bug #55189 [NEW]: BC break in behavior of is_a()
From:
Operating system: Linux
PHP version: 5.3SVN-2011-07-12 (SVN)
Package: Scripting Engine problem
Bug Type: Bug
Bug description:BC break in behavior of is_a()
Description:
I notice a different bahavior between PHP5.3.6 and a daily build supplied
by the openSUSE build service, designated php5-5.3.6.201107111820-83.1 with
php - output is "PHP 5.3.7RC3-dev (cli)"
In short, is_a('', '') emits a warning with php/5.3.7rc3 which did not
happen with 5.3.6 and AFAIK earlier versions.
I know that is_a('', '') doesn't make much sense, but it's a BC break. To
be more precise, I stumbled across this when upgrading a PEAR repo and to
my surprise got a bunch of warnings (Warning: Unknown class passed as
parameter in /usr/share/php5/PEAR/PEAR.php on line 252) and tracked it down
to the is_a() call.
I'm not really sure if this was planned and/or is a documentation issue,
but just to be sure it is an intentional change I put this here to be
discussed.
AFAIK from reading the php.internals mailing list, such a change in
behavior in a minor update is most likely not intentional ;)
Test script:
---
In a shell type the following:
php -r 'printf("%d\n", is_a("", ""));'
(Note: in case of Windows OS the ' and " have to be replaced with each
other)
Expected result:
0
Actual result:
--
Warning: Unknown class passed as parameter in Command line code on line 1
0
--
Edit bug report at https://bugs.php.net/bug.php?id=55189&edit=1
--
Try a snapshot (PHP 5.2):
https://bugs.php.net/fix.php?id=55189&r=trysnapshot52
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55189&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55189&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55189&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55189&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55189&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55189&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55189&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55189&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55189&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55189&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55189&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55189&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55189&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55189&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55189&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55189&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55189&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55189&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55189&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55189&r=mysqlcfg
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55189&r=trysnapshot54
[PHP-BUG] Bug #53630 [NEW]: optional prompt argument is treated as non-optional
From:
Operating system: Linux
PHP version: 5.3.4
Package: Readline related
Bug Type: Bug
Bug description:optional prompt argument is treated as non-optional
Description:
The readline functions prompt argument is supposed to be optional. But
omitting it raises a PHP warning.
Test script:
---
php -r 'printf("%s\n", readline());'
Replace single and double quotes vice versa for Win platform
Actual result:
--
PHP Warning: readline() expects exactly 1 parameter, 0 given in Command
line code on line 1
--
Edit bug report at http://bugs.php.net/bug.php?id=53630&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53630&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53630&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53630&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53630&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53630&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53630&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53630&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53630&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53630&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53630&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53630&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53630&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53630&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53630&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53630&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53630&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53630&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53630&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53630&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53630&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53630&r=mysqlcfg
Req #38196 [Com]: quoteIdentifier() in PDO
Edit report at http://bugs.php.net/bug.php?id=38196&edit=1
ID: 38196
Comment by: jo at feuersee dot de
Reported by:wasti dot redl at gmx dot net
Summary:quoteIdentifier() in PDO
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: Linux
PHP Version:5.1.4
Block user comment: N
New Comment:
I agree that the current PDO implementation lacks a portable way to
quote SQL identifiers like table or field names.
Some people will argue that in most cases it's better to avoid quote
identifiers at all, and I agree. But every database has it's own list of
reserved words which can't be used as a field or table name unless
quoted. As it is hardly possible to avoid all reserved words from all
databases (to improve portability between database backends),
implementing such a method in PDO would be a big help.
Alternative suggestion: instead of adding a new method quoteIdentifier()
extend PDO::quote() method to accept a new const PDO::PARAM_IDENTIFIER
which works as follows:
$sql = sprintf("SELECT %s FROM %s",
$pdo->quote('field', PDO::PARAM_IDENTIFIER),
$pdo->quote('table', PDO::PARAM_IDENTIFIER)
);
$sql would then be
for MySQL backend:
SELECT `field` FROM `table`
for SQLite:
SELECT 'field' FROM 'table'
Previous Comments:
[2006-07-24 17:49:53] wasti dot redl at gmx dot net
Description:
It would be nice if PDO supported a quoteIdentifier() method like
PEAR::MDB2 does, that quotes strings according to identifier rules of
the DBMS. In other words, I need to use arbitrary strings as field or
table names in a query and would like a DBMS-independent way of quoting
them.
--
Edit this bug report at http://bugs.php.net/bug.php?id=38196&edit=1
Req #43822 [Com]: Allow ini_set('include_path', ??) even when php_admin_value include_path is set
Edit report at http://bugs.php.net/bug.php?id=43822&edit=1
ID: 43822
Comment by: jo at feuersee dot de
Reported by: birne at 007mail dot de
Summary: Allow ini_set('include_path', ??) even when
php_admin_value include_path is set
Status: Open
Type: Feature/Change Request
Package: Feature/Change Request
Operating System: Ubuntu Linux 7.10
PHP Version: 5.2.5
New Comment:
PHP 5.3.2
As derernst corretly stated, using set_include_path() instead of
ini_set()
does not make any difference.
This behavior doesn't add any security (as you can still include files
anywhere as long as open_basedir allows it), but limits convenience (eg.
adding a framework, writing custom autoloader functions, ...)
Previous Comments:
[2009-03-20 13:13:10] derernst at gmx dot ch
Using set_include_path() instead of ini_set('include_path') does not
seem to make a difference.
I consider this change, that disables setting the include_path at
runtime, a severe backwards compatibility break. For example it can make
an application that relies on a manual PEAR installation unuseable. This
is a problem specially in shared hosting environments, where you usually
can't control the server configuration.
[2008-01-11 21:59:31] der...@php.net
I think you can use set_include_path() for this:
http://no.php.net/manual/en/function.set-include-path.php
[2008-01-11 20:55:42] birne at 007mail dot de
Description:
After the patch for #41561 was applied, ini_set() could no longer
overwrite any configuration value that was previously defined using
php_admin_*.
In #43598 sniper wrote: php_admin_* is supposed to make any such option
unusable by anybody in any script. And it's meant for hosting
companies.
I agree, that in a hosting environment no customer should be able to
overwrite configuration like open_basedir. But there is no harm in
allowing the customer to change include_path; on the contrary is it of
great use for the customer to add his own libraries.
Before the #41561 patch was applied, this was already possible for years
and that was no bug, because overwriting open_basedir was not possible
at all.
I suggest to define another "Changeable" scope (see
http://php.net/manual/en/ini.php) for configuration values like
"PHP_INI_OVERWRITEABLE" wich behaves like "PHP_INI_ALL" but in addition
to that can be overwritten using ini_set() even when previously defined
using php_admin_*. The inlude_path would be one of the new
PHP_INI_OVERWRITEABLE directives, additional harmless ones must be
defined.
Please make sure to properly document that change - the new behavior of
the patch for #41561 is still not documented anywhere (or I did not find
it..)
--
Edit this bug report at http://bugs.php.net/bug.php?id=43822&edit=1
[PHP-BUG] Bug #51393 [NEW]: DateTime::createFromFormat() fails if format string contains timezone
From:
Operating system: Linux
PHP version: 5.3.2
Package: Date/time related
Bug Type: Bug
Bug description:DateTime::createFromFormat() fails if format string contains
timezone
Description:
I was trying to process Apache logfiles with PHP. The default LogFormat
timestamp
%t translates to '[d/M/Y:H:i:s O]' in date() notation.
PHP fails to create DateTime instances if the format argument contains
timezone
placeholders like O P e
I am aware of the 3rd parameter of DateTime::createFromFormat() to pass
timezone
information.
- the documentation says 'Format accepted by date()'
- DateTime is supposed to help parsing datetime formats, not to restrict
Test script:
---
$dt = DateTime::createFromFormat('[d/M/Y:H:i:s O]', '[13/Mar/1969:23:40:00
+0100]');
print($dt->format('c'));
Expected result:
1969-03-13T23:40:00+01:00
Actual result:
--
Fatal error: Call to a member function format() on a non-object
--
Edit bug report at http://bugs.php.net/bug.php?id=51393&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51393&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51393&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51393&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51393&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51393&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51393&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51393&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51393&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51393&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51393&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51393&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51393&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51393&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51393&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51393&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51393&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51393&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51393&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51393&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51393&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51393&r=mysqlcfg
[PHP-BUG] Bug #51267 [NEW]: Performance of serialize() is poor compared to json_encode()
From:
Operating system:
PHP version: 5.3.2
Package: Arrays related
Bug Type: Bug
Bug description:Performance of serialize() is poor compared to json_encode()
Description:
The performance of serialize() decreases if the data is deeply nested, eg.
consists of array inside an array.
Surprisingly, json_encode() is not affected by this issue, thus I'd say
there should be some optimizations not used in serialize()
serialize() performs great on arrays structured (key => val), but fails ion
structs like
array(
array(key => val)
...
)
Test script:
---
Benchmark json_encode() vs. serialize() on the following data:
$arr = array();
for($i = 0; $i < $num_size; $i++) {
$arr[md5($i)] = array(
sha1($i),
SplFixedArray::fromArray(
array_fill(
0, 10, hash('sha256', rand(0, $num_size))
)
)
);
}
Expected result:
More or less the same same time comsumed.
Actual result:
--
json_encode() is >3 times faster than serialize().
This increases if the arrays nesting level increases.
--
Edit bug report at http://bugs.php.net/bug.php?id=51267&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51267&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51267&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51267&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51267&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51267&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51267&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51267&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51267&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51267&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51267&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51267&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51267&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51267&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51267&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51267&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51267&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51267&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51267&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51267&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51267&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51267&r=mysqlcfg
[PHP-BUG] Req #51150 [Opn]: spl_autoload_extensions() should accept arrays to avoid invalid separators
Edit report at http://bugs.php.net/bug.php?id=51150&edit=1
ID: 51150
User updated by: jo at feuersee dot de
Reported by: jo at feuersee dot de
Summary: spl_autoload_extensions() should accept arrays to
avoid invalid separators
Status: Open
Type: Feature/Change Request
Package: SPL related
Operating System: *
PHP Version: 5.3.1
New Comment:
This is not about that I have a list of extensions in an array and that
I am
unable to use implode to pass this to spl_autoload_extension() as a
string.
This bug report is about that the design of spl_autoload_extension()
would be
better if it accepts an array.
Using a whatether separated string implies that the whatether character
can't be
a valid part of the argument list. An array does not have this
limitation.
Previous Comments:
[2010-03-02 03:27:41] ka...@php.net
Using implode() would really be enough here, I'm not sure whether we
should add that option or not, but it is indeed not a bad idea.
As a workaround you may want to do:
spl_autoload_extensions(implode(',', $extensions));
[2010-03-01 21:16:40] j...@php.net
-Operating System: Any
+Operating System: *
[2010-03-01 20:05:58] paj...@php.net
-Package: Feature/Change Request
+Package: SPL related
----
[2010-02-25 20:22:49] jo at feuersee dot de
Description:
spl_autoload_extensions() accepts a string with a , separated list of
filename parts to register for autoloading.
This results in filenames containing a , as an extension filename
become impossible to register.
It should be possible to pass an array to circumvent any restriction
cased by the string based argument.
I know that ppl might consider it strange to use , as part of a
filename.
IMHO there may be cases where it might be necessary. Considering that
arrays are a native PHP data type, it would be a better design.
Reproduce code:
---
spl_autoload_extensions(array('.class.php', '.php'));
myclass::hello();
Expected result:
Hello world
Actual result:
--
Warning: spl_autoload_extensions() expects parameter 1 to be string,
array given in [test.php] on line ##
Fatal error: Class 'myclass' not found in [test.php] on line ##
--
Edit this bug report at http://bugs.php.net/bug.php?id=51150&edit=1
#51150 [NEW]: spl_autoload_extensions() should accept arrays to avoid invalid separators
From: jo at feuersee dot de
Operating system: Any
PHP version: 5.3.1
PHP Bug Type: SPL related
Bug description: spl_autoload_extensions() should accept arrays to avoid
invalid separators
Description:
spl_autoload_extensions() accepts a string with a , separated list of
filename parts to register for autoloading.
This results in filenames containing a , as an extension filename
become impossible to register.
It should be possible to pass an array to circumvent any restriction
cased by the string based argument.
I know that ppl might consider it strange to use , as part of a
filename.
IMHO there may be cases where it might be necessary. Considering that
arrays are a native PHP data type, it would be a better design.
Reproduce code:
---
spl_autoload_extensions(array('.class.php', '.php'));
myclass::hello();
Expected result:
Hello world
Actual result:
--
Warning: spl_autoload_extensions() expects parameter 1 to be string,
array given in [test.php] on line ##
Fatal error: Class 'myclass' not found in [test.php] on line ##
--
Edit bug report at http://bugs.php.net/?id=51150&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51150&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51150&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51150&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51150&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51150&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51150&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51150&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51150&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51150&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51150&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51150&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51150&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51150&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51150&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51150&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51150&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51150&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51150&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51150&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51150&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51150&r=mysqlcfg
#49640 [NEW]: Feature request: spl_autoload_cs
From: jo at feuersee dot de Operating system: Linux PHP version: 5.3.0 PHP Bug Type: SPL related Bug description: Feature request: spl_autoload_cs Description: This is related to #49625 Ok I agree that spl_autoload() won't be touched because of BC (Seems the convention to lowercase all filenames has been borrowed from Java and ppl are actually using it). How about a case sensitive function spl_autoload_cs() then? It should behave excactly like spl_autoload() except that it skips the lowercasing stuff. Projects using a case sensitive naming convention (PEAR, Zend Framework, ...) can unregister the default spl_autoload() and register spl_autoload_cs() and it will work. I am aware that it is possible to write an own callback in PHP. The problem is that you can't write the callback once and then put it in your codebase because the callback is the glue between your script and the codebase. I do a lot of scripting PHP on the CLI and am tired of duplicating my callback function code over and over again just to make sure the script will work with a case sensitive design paradim. Reproduce code: --- -- Edit bug report at http://bugs.php.net/?id=49640&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49640&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49640&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49640&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49640&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49640&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49640&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49640&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49640&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49640&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49640&r=support Expected behavior: http://bugs.php.net/fix.php?id=49640&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49640&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49640&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49640&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49640&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49640&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49640&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49640&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49640&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49640&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49640&r=mysqlcfg
#49625 [Bgs]: spl_autoload and case sensitivity
ID: 49625
User updated by: jo at feuersee dot de
Reported By: jo at feuersee dot de
Status: Bogus
Bug Type: SPL related
Operating System: Linux
PHP Version: 5.3.0
New Comment:
>The reason here is that is spl_autoload becomes case
>sensitive, it will break scripts which depend on spl_autoload being
>case insensitive.
spl_autoload() was introduced in PHP 5.1.2 which is case sensitive
concerning class names. This implies that if an operation on an unknown
class is done, spl_autoload() is triggered and executed with the case
sensitive name of the class.
Thus we have 4 different possibilities:
1) The class name all lower case, the file containing the class
definition is all lower case (eg. $foo = system::bar(); system.php)
This will work independent wether spl_autoload() is lowercasing or not,
since all is lowercased.
Note that if the class defined in the file system.php is actually named
System it wouldn't have ever worked because the class system is still
not defined, which would trigger an error.
2) The class name all lower case, the file containing the class
definition is uppercased (eg. $foo = system::bar(); System.php)
This wouldn't work anymore on file systems which are case sensitive if
spl_autoload() would skip lowercasing.
Note that this would only have worked if the file system is case
insensitive and the class definition in System.php would define a class
"system".
3) The class name contains upper case letters, the file containing the
class definition is lowercased (eg. $foo = System::bar(); system.php)
This is what currently isn't working at all but would work at least for
case insensitive file systems if lowercasing would be dropped.
Note that if the class defined in the file system.php is actually named
system it wouldn't have ever worked because the class System is still
not defined.
4) The class name contains upper case letters, the file containing the
class definition is uppercased (eg. $foo = System::bar(); System.php)
This is what should (and would) work, but currently doesn't.
Conclusion:
The only problem might be (2):
Class name: sample
Filename: Sample.php
Class definition in Sample.php: class sample { ... }
Note: this does work on case insensitive file systems only.
I really can't see any reason for maintaining the "Worse is better"
principle here, I really doubt that there is much code around relying on
the tolowercase feature/bug of spl_autoload().
As a compromise I propose the following:
1) spl_autoload() additionally tries to find a file _not_ lowercased.
2) Throw a E_DEPRECATED in case the filename had to be lowercased to
match.
Until then:
I really don't know why this lowercasing thing was introduced into
slp_autoload() to begin with, all it ever did was preventing classes to
be named with upper case letters on file systems which are case
sensitive. In other words: the only compatibility issue is that code
which currently works on platforms like Windows only would suddenly work
on UN*X like platforms too.
Pls confirm if this is the compatibility issue you are talking about.
Previous Comments:
[2009-09-22 16:22:22] sjo...@php.net
Thank you for your bug report.
Wontfix means: we agree that there is a bug, but there are reasons not
to fix it. The reason here is that is spl_autoload becomes case
sensitive, it will break scripts which depend on spl_autoload being case
insensitive.
----------------
[2009-09-22 16:01:15] jo at feuersee dot de
Description:
This is basically the same as PHP bug #48129.
Yes, I have read it "won't fix"
My opinion on this is "won't fix" is not an option because it _is_ a
bug and not fixing bugs does not work:
1) It is common practice in OO languages (including PHP) to give
classes case sensitive names. Even the classes of PHP itself are case
sensitive and usually start with capital letters (eg. DateTime,
Exception, ...). PHP related projects like PEAR, Zend Framework etc. do
the same.
2) In order to get a proper 1:1 mapping from class name to the file
containing the PHP class definition, projects like PEAR or Zend
Framework use the case sensitive class name, eg. System.php contains the
class System. Again, this is common practice in other OO languages like
C++.
3) What happens when the file system is case sensitive?
See example: the script fails because the PEAR class System will be
looked for in a file named system.php which does not exist because it is
called System.php
The workaround is using SPL_autoload_suxx instead. But look at the
code: there are several compatibility issues (include_path separator :
vs. ;), it does work but is not at all convenient.
4) What would happen if spl_autoload() wouldn't lowercase the class
name w
#49625 [NEW]: spl_autoload and case sensitivity
From: jo at feuersee dot de
Operating system: Linux
PHP version: 5.3.0
PHP Bug Type: SPL related
Bug description: spl_autoload and case sensitivity
Description:
This is basically the same as PHP bug #48129.
Yes, I have read it "won't fix"
My opinion on this is "won't fix" is not an option because it _is_ a bug
and not fixing bugs does not work:
1) It is common practice in OO languages (including PHP) to give classes
case sensitive names. Even the classes of PHP itself are case sensitive and
usually start with capital letters (eg. DateTime, Exception, ...). PHP
related projects like PEAR, Zend Framework etc. do the same.
2) In order to get a proper 1:1 mapping from class name to the file
containing the PHP class definition, projects like PEAR or Zend Framework
use the case sensitive class name, eg. System.php contains the class
System. Again, this is common practice in other OO languages like C++.
3) What happens when the file system is case sensitive?
See example: the script fails because the PEAR class System will be looked
for in a file named system.php which does not exist because it is called
System.php
The workaround is using SPL_autoload_suxx instead. But look at the code:
there are several compatibility issues (include_path separator : vs. ;), it
does work but is not at all convenient.
4) What would happen if spl_autoload() wouldn't lowercase the class name
when looking for a class definition?
a) Filesystem is case sensitive
It would work!
The spl_autoload() would look for a file called System.php which exists,
thus will be require'd
b) Filesystem is not case sensitive
It would still work!
The spl_autoload() would look for a file called System.php
Because the file system is case insensitive, it would use either
System.php or system.php (or sYSTEM.PHP - you got the point?).
Because on case insentive filesystems both files "System.php" and
"system.php" are not allowed in the same directory, there is _no_ issue
with backward compatibility.
The only circumstances where it would break backwards compatibility would
be on filesystem which is case insensitive but does not allow capital
letters. Any real live examples of such a file system?
Conclusion:
The current specification of spl_autoload() with implicit lowercasing is
excactly wrong. There has been, is and never will be any gain in this
'feature' since the class name itself inside PHP is case sensitive.
Reproduce code:
---
System::which('mysql'),
'mysqlbinlog' => System::which('mysqlbinlog'),
'php' => System::which('php')
);
print_r($binaries);
?>
Expected result:
Array
(
[mysql] => /usr/bin/mysql
[mysqlbinlog] => /usr/bin/mysqlbinlog
[php] => /usr/local/bin/php
)
Actual result:
--
PHP Fatal error: Class 'System' not found in
/srv/www/vhosts/www.easy-sew.de/ftpjung/bin/autoload.php on line 38
--
Edit bug report at http://bugs.php.net/?id=49625&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49625&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49625&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49625&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49625&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49625&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49625&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49625&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49625&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49625&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49625&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49625&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49625&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49625&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49625&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49625&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49625&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49625&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49625&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49625&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49625&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49625&r=mysqlcfg
#49609 [Opn]: Feature request: native DateTime support in IntlDateFormatter
ID: 49609
User updated by: jo at feuersee dot de
Reported By: jo at feuersee dot de
Status: Open
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 5.3.0
New Comment:
date_parse() and the proposed equivalent to ICU DateFormat::parse() (or
the existing IntlDateFormatter::localtime() ) do have totally different
intentions and functionality.
date_parse() returns a datetime struct from a strtotime() compatible
string.
DateFormat::parse() parses a _localized_ date/time string into a
portable Object (UDate) which is equivalent to PHP DateTime.
Localized date/time are _not_ strtotime() compatible, could be a string
with a localized date/time like
de_DE: "Sonntag, 20. September 2009"
ja_JP: "2009å¹´9æ21æ¥ 04:38:29JST"
Just take a look of the ICU API:
<http://icu-project.org/apiref/icu4c/classDateFormat.html>
Replace the C++ UDate class with DateTime and this is pretty much how
the PHP class should look like - no reason to invent another PHPish
wheel...
And I really don't want to work on silly structured hashes, I want my
PHP to be object oriented.
Previous Comments:
[2009-09-20 19:07:10] der...@php.net
There is a date_parse() already: http://uk.php.net/date_parse
--------
[2009-09-20 18:58:04] jo at feuersee dot de
I might add the request for a method parse($string) which works like
the localtime() method but returns a DateTime object (or at least a
DateTime (ISO 8601) parseable string. Like the DateFormat of ICU does.
The struct returned by localtime() is really impractical to handle (eg.
tm_mon is numbered 0-11, tm_year is defined as "years since 1900").
------------
[2009-09-20 14:39:43] jo at feuersee dot de
Description:
The usage of the ICU based IntlDateFormatter class would be much more
convenient if it would support DateTime objects, especially the format()
method.
The workaround is to parse the DateTime value to a timestamp and cast
it to int (or use getTimestamp() with PHP 5.3.0+).
The alternative localtime() structured param is a bit odd IMHO, I
really can't remember having seen any usage of this function in the last
10 years. It seems it has been chosen to circumvent the limited range of
timestamps?
In fact, the range of localtime() is limited, though not as much as
mktime():
with Linux on x686 it's approx. from UTC 1902-01-01 to 2038-01-19
The DateTime class does not have this limited range, a nice OO design,
works great with ISO 8601 formatted dates and times . why not use it in
IntlDateFormatter?
Reproduce code:
---
1) php -r '$fmt = new IntlDateFormatter("de_DE"
,IntlDateFormatter::MEDIUM, IntlDateFormatter::MEDIUM, "UTC");
$dt = new DateTime("1781-12-13");
printf("%s\n", $fmt->format($dt));'
2) php -r '$fmt = new IntlDateFormatter("de_DE"
,IntlDateFormatter::MEDIUM, IntlDateFormatter::MEDIUM, "UTC");
$dt = new DateTime("1781-12-13");
printf("%s\n", $fmt->format($dt->format("U")));'
3) php -r '$fmt = new IntlDateFormatter("de_DE"
,IntlDateFormatter::MEDIUM, IntlDateFormatter::MEDIUM, "UTC");
$dt = new DateTime("1781-12-13");
printf("%s\n", $fmt->format((int) $dt->format("U")));'
Expected result:
1) 12.12.1781 23:00:00
2) 12.12.1781 23:00:00
3) 12.12.1781 23:00:00
Actual result:
--
1)
2)
3) 12.12.1781 23:00:00
--
Edit this bug report at http://bugs.php.net/?id=49609&edit=1
#49609 [Opn]: Feature request: native DateTime support in IntlDateFormatter
ID: 49609
User updated by: jo at feuersee dot de
Reported By: jo at feuersee dot de
Status: Open
Bug Type: Feature/Change Request
Operating System: not OS related
PHP Version: 5.3.0
New Comment:
I might add the request for a method parse($string) which works like
the localtime() method but returns a DateTime object (or at least a
DateTime (ISO 8601) parseable string. Like the DateFormat of ICU does.
The struct returned by localtime() is really impractical to handle (eg.
tm_mon is numbered 0-11, tm_year is defined as "years since 1900").
Previous Comments:
[2009-09-20 14:39:43] jo at feuersee dot de
Description:
The usage of the ICU based IntlDateFormatter class would be much more
convenient if it would support DateTime objects, especially the format()
method.
The workaround is to parse the DateTime value to a timestamp and cast
it to int (or use getTimestamp() with PHP 5.3.0+).
The alternative localtime() structured param is a bit odd IMHO, I
really can't remember having seen any usage of this function in the last
10 years. It seems it has been chosen to circumvent the limited range of
timestamps?
In fact, the range of localtime() is limited, though not as much as
mktime():
with Linux on x686 it's approx. from UTC 1902-01-01 to 2038-01-19
The DateTime class does not have this limited range, a nice OO design,
works great with ISO 8601 formatted dates and times . why not use it in
IntlDateFormatter?
Reproduce code:
---
1) php -r '$fmt = new IntlDateFormatter("de_DE"
,IntlDateFormatter::MEDIUM, IntlDateFormatter::MEDIUM, "UTC");
$dt = new DateTime("1781-12-13");
printf("%s\n", $fmt->format($dt));'
2) php -r '$fmt = new IntlDateFormatter("de_DE"
,IntlDateFormatter::MEDIUM, IntlDateFormatter::MEDIUM, "UTC");
$dt = new DateTime("1781-12-13");
printf("%s\n", $fmt->format($dt->format("U")));'
3) php -r '$fmt = new IntlDateFormatter("de_DE"
,IntlDateFormatter::MEDIUM, IntlDateFormatter::MEDIUM, "UTC");
$dt = new DateTime("1781-12-13");
printf("%s\n", $fmt->format((int) $dt->format("U")));'
Expected result:
1) 12.12.1781 23:00:00
2) 12.12.1781 23:00:00
3) 12.12.1781 23:00:00
Actual result:
--
1)
2)
3) 12.12.1781 23:00:00
--
Edit this bug report at http://bugs.php.net/?id=49609&edit=1
#49609 [NEW]: Feature request: native DateTime support in IntlDateFormatter
From: jo at feuersee dot de
Operating system: not OS related
PHP version: 5.3.0
PHP Bug Type: I18N and L10N related
Bug description: Feature request: native DateTime support in IntlDateFormatter
Description:
The usage of the ICU based IntlDateFormatter class would be much more
convenient if it would support DateTime objects, especially the format()
method.
The workaround is to parse the DateTime value to a timestamp and cast it
to int (or use getTimestamp() with PHP 5.3.0+).
The alternative localtime() structured param is a bit odd IMHO, I really
can't remember having seen any usage of this function in the last 10 years.
It seems it has been chosen to circumvent the limited range of timestamps?
In fact, the range of localtime() is limited, though not as much as
mktime():
with Linux on x686 it's approx. from UTC 1902-01-01 to 2038-01-19
The DateTime class does not have this limited range, a nice OO design,
works great with ISO 8601 formatted dates and times . why not use it in
IntlDateFormatter?
Reproduce code:
---
1) php -r '$fmt = new IntlDateFormatter("de_DE"
,IntlDateFormatter::MEDIUM, IntlDateFormatter::MEDIUM, "UTC");
$dt = new DateTime("1781-12-13");
printf("%s\n", $fmt->format($dt));'
2) php -r '$fmt = new IntlDateFormatter("de_DE"
,IntlDateFormatter::MEDIUM, IntlDateFormatter::MEDIUM, "UTC");
$dt = new DateTime("1781-12-13");
printf("%s\n", $fmt->format($dt->format("U")));'
3) php -r '$fmt = new IntlDateFormatter("de_DE"
,IntlDateFormatter::MEDIUM, IntlDateFormatter::MEDIUM, "UTC");
$dt = new DateTime("1781-12-13");
printf("%s\n", $fmt->format((int) $dt->format("U")));'
Expected result:
1) 12.12.1781 23:00:00
2) 12.12.1781 23:00:00
3) 12.12.1781 23:00:00
Actual result:
--
1)
2)
3) 12.12.1781 23:00:00
--
Edit bug report at http://bugs.php.net/?id=49609&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49609&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49609&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49609&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49609&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49609&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49609&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49609&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49609&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49609&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49609&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49609&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49609&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49609&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49609&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49609&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49609&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49609&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49609&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49609&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49609&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49609&r=mysqlcfg
#49408 [Fbk->Csd]: Wrong PHP Startup error messages
ID: 49408 User updated by: jo at feuersee dot de Reported By: jo at feuersee dot de -Status: Feedback +Status: Closed Bug Type: *General Issues Operating System: Linux PHP Version: 5.3.0 New Comment: Is fixed in current PHP 5.3.1-dev, verified with 200908301030 snapshot Previous Comments: [2009-08-30 01:25:01] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-08-29 21:44:11] jo at feuersee dot de Description: After upgrading to PHP 5.3.0 I wanted to clean up the pecl repos (I had the intl extension running with PHP 4.4) by issuing $ pecl uninstall intl Unfortunately, this didn't rm the intl.so in the directory where I installed it but the intl.so of PHP 5.3.0 (totally different directory). It took some time to figure this out because both CLI and Apache mod only stated some issue with the timezone settings (which are perfectly ok). Reproduce code: --- rm eg. the intl extension (intl.so), restart apache or just issue $ php -m Expected result: Requested extension 'intl.so' missing in '/usr/lib/php5/extensions' Actual result: -- PHP Fatal error: PHP Startup: Timezone database is corrupt - this should *never* happen! in Unknown on line 0 [Sat Aug 29 22:21:19 2009] [notice] seg fault or similar nasty error detected in the parent process PHP Warning: PHP Startup: 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 'Europe/Berlin' for 'CEST/2.0/DST' instead in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/?id=49408&edit=1
#49410 [Opn->Bgs]: Wrong PHP Startup error messages
ID: 49410 User updated by: jo at feuersee dot de Reported By: jo at feuersee dot de -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: Linux PHP Version: 5.3.0 New Comment: Sry another duplicate report generated by CAPTCHA insanity Previous Comments: [2009-08-29 21:45:37] jo at feuersee dot de Description: After upgrading to PHP 5.3.0 I wanted to clean up the pecl repos (I had the intl extension running with PHP 4.4) by issuing $ pecl uninstall intl Unfortunately, this didn't rm the intl.so in the directory where I installed it but the intl.so of PHP 5.3.0 (totally different directory). It took some time to figure this out because both CLI and Apache mod only stated some issue with the timezone settings (which are perfectly ok). Reproduce code: --- rm eg. the intl extension (intl.so), restart apache or just issue $ php -m Expected result: Requested extension 'intl.so' missing in '/usr/lib/php5/extensions' Actual result: -- PHP Fatal error: PHP Startup: Timezone database is corrupt - this should *never* happen! in Unknown on line 0 [Sat Aug 29 22:21:19 2009] [notice] seg fault or similar nasty error detected in the parent process PHP Warning: PHP Startup: 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 'Europe/Berlin' for 'CEST/2.0/DST' instead in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/?id=49410&edit=1
#49409 [Opn->Bgs]: Wrong PHP Startup error messages
ID: 49409 User updated by: jo at feuersee dot de Reported By: jo at feuersee dot de -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: Linux PHP Version: 5.3.0 New Comment: Sorry, duplicate of #49408 (because of f**king CAPTCHA) Previous Comments: [2009-08-29 21:45:06] jo at feuersee dot de Description: After upgrading to PHP 5.3.0 I wanted to clean up the pecl repos (I had the intl extension running with PHP 4.4) by issuing $ pecl uninstall intl Unfortunately, this didn't rm the intl.so in the directory where I installed it but the intl.so of PHP 5.3.0 (totally different directory). It took some time to figure this out because both CLI and Apache mod only stated some issue with the timezone settings (which are perfectly ok). Reproduce code: --- rm eg. the intl extension (intl.so), restart apache or just issue $ php -m Expected result: Requested extension 'intl.so' missing in '/usr/lib/php5/extensions' Actual result: -- PHP Fatal error: PHP Startup: Timezone database is corrupt - this should *never* happen! in Unknown on line 0 [Sat Aug 29 22:21:19 2009] [notice] seg fault or similar nasty error detected in the parent process PHP Warning: PHP Startup: 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 'Europe/Berlin' for 'CEST/2.0/DST' instead in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/?id=49409&edit=1
#49410 [NEW]: Wrong PHP Startup error messages
From: jo at feuersee dot de Operating system: Linux PHP version: 5.3.0 PHP Bug Type: *General Issues Bug description: Wrong PHP Startup error messages Description: After upgrading to PHP 5.3.0 I wanted to clean up the pecl repos (I had the intl extension running with PHP 4.4) by issuing $ pecl uninstall intl Unfortunately, this didn't rm the intl.so in the directory where I installed it but the intl.so of PHP 5.3.0 (totally different directory). It took some time to figure this out because both CLI and Apache mod only stated some issue with the timezone settings (which are perfectly ok). Reproduce code: --- rm eg. the intl extension (intl.so), restart apache or just issue $ php -m Expected result: Requested extension 'intl.so' missing in '/usr/lib/php5/extensions' Actual result: -- PHP Fatal error: PHP Startup: Timezone database is corrupt - this should *never* happen! in Unknown on line 0 [Sat Aug 29 22:21:19 2009] [notice] seg fault or similar nasty error detected in the parent process PHP Warning: PHP Startup: 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 'Europe/Berlin' for 'CEST/2.0/DST' instead in Unknown on line 0 -- Edit bug report at http://bugs.php.net/?id=49410&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49410&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49410&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49410&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49410&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49410&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49410&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49410&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49410&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49410&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49410&r=support Expected behavior: http://bugs.php.net/fix.php?id=49410&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49410&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49410&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49410&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49410&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49410&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49410&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49410&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49410&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49410&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49410&r=mysqlcfg
#49409 [NEW]: Wrong PHP Startup error messages
From: jo at feuersee dot de Operating system: Linux PHP version: 5.3.0 PHP Bug Type: *General Issues Bug description: Wrong PHP Startup error messages Description: After upgrading to PHP 5.3.0 I wanted to clean up the pecl repos (I had the intl extension running with PHP 4.4) by issuing $ pecl uninstall intl Unfortunately, this didn't rm the intl.so in the directory where I installed it but the intl.so of PHP 5.3.0 (totally different directory). It took some time to figure this out because both CLI and Apache mod only stated some issue with the timezone settings (which are perfectly ok). Reproduce code: --- rm eg. the intl extension (intl.so), restart apache or just issue $ php -m Expected result: Requested extension 'intl.so' missing in '/usr/lib/php5/extensions' Actual result: -- PHP Fatal error: PHP Startup: Timezone database is corrupt - this should *never* happen! in Unknown on line 0 [Sat Aug 29 22:21:19 2009] [notice] seg fault or similar nasty error detected in the parent process PHP Warning: PHP Startup: 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 'Europe/Berlin' for 'CEST/2.0/DST' instead in Unknown on line 0 -- Edit bug report at http://bugs.php.net/?id=49409&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49409&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49409&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49409&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49409&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49409&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49409&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49409&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49409&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49409&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49409&r=support Expected behavior: http://bugs.php.net/fix.php?id=49409&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49409&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49409&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49409&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49409&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49409&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49409&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49409&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49409&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49409&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49409&r=mysqlcfg
#49408 [NEW]: Wrong PHP Startup error messages
From: jo at feuersee dot de Operating system: Linux PHP version: 5.3.0 PHP Bug Type: *General Issues Bug description: Wrong PHP Startup error messages Description: After upgrading to PHP 5.3.0 I wanted to clean up the pecl repos (I had the intl extension running with PHP 4.4) by issuing $ pecl uninstall intl Unfortunately, this didn't rm the intl.so in the directory where I installed it but the intl.so of PHP 5.3.0 (totally different directory). It took some time to figure this out because both CLI and Apache mod only stated some issue with the timezone settings (which are perfectly ok). Reproduce code: --- rm eg. the intl extension (intl.so), restart apache or just issue $ php -m Expected result: Requested extension 'intl.so' missing in '/usr/lib/php5/extensions' Actual result: -- PHP Fatal error: PHP Startup: Timezone database is corrupt - this should *never* happen! in Unknown on line 0 [Sat Aug 29 22:21:19 2009] [notice] seg fault or similar nasty error detected in the parent process PHP Warning: PHP Startup: 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 'Europe/Berlin' for 'CEST/2.0/DST' instead in Unknown on line 0 -- Edit bug report at http://bugs.php.net/?id=49408&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49408&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49408&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49408&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49408&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49408&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49408&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49408&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49408&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49408&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49408&r=support Expected behavior: http://bugs.php.net/fix.php?id=49408&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49408&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49408&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49408&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49408&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49408&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49408&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49408&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49408&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49408&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49408&r=mysqlcfg
#46964 [NEW]: PDO MySQL requires #define MYSQL_OPT_LOCAL_INFILE
From: jo at feuersee dot de
Operating system: Linux
PHP version: 5.2.8
PHP Bug Type: Compile Failure
Bug description: PDO MySQL requires #define MYSQL_OPT_LOCAL_INFILE
Description:
Compiling PDO MySQL with ancient MySQL fails because the code
assumes that MYSQL_OPT_LOCAL_INFILE has been defined. This isn't the
case with MySQL 3.* and IIRC 4.0 and some early 4.1 versions.
AFAICS it's pretty easy to fix this: tell the compiler to test via
#ifdef
In file etc/pdo_mysql/mysql_driver.c ad line 500:
#ifdef MYSQL_OPT_LOCAL_INFILE
if (mysql_options(H->server, MYSQL_OPT_LOCAL_INFILE,
(const char *)&local_infile)) {
pdo_mysql_error(dbh);
goto cleanup;
}
#endif
--
Edit bug report at http://bugs.php.net/?id=46964&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46964&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46964&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46964&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46964&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46964&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46964&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46964&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46964&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46964&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46964&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46964&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46964&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46964&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46964&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46964&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46964&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46964&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46964&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46964&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46964&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46964&r=mysqlcfg
#44506 [NEW]: nl_langinfo()
From: jo at feuersee dot de
Operating system: Linux
PHP version: 5.2.5
PHP Bug Type: I18N and L10N related
Bug description: nl_langinfo()
Description:
The documentation states that "item may be an integer value of the
element or the constant name of the element."
The 2nd way (passing the const name as a string) doesn't work, the
returned string will always be empty ("").
This may be a documentation bug.
Reproduce code:
---
[EMAIL PROTECTED] ~> php5 -r '$l = setlocale(LC_ALL, "de_DE.utf8"); printf("%s:
%s\n", $l, nl_langinfo(D_T_FMT));'
de_DE.utf8: %a %d %b %Y %T %Z
[EMAIL PROTECTED] ~> php5 -r '$l = setlocale(LC_ALL, "de_DE.utf8"); printf("%s:
%s\n", $l, nl_langinfo("D_T_FMT"));'
de_DE.utf8:
Expected result:
Both ways return
de_DE.utf8: %a %d %b %Y %T %Z
Actual result:
--
Only when using the D_T_FMT const, the result is like expected.
--
Edit bug report at http://bugs.php.net/?id=44506&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44506&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44506&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44506&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44506&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44506&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44506&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44506&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44506&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44506&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44506&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44506&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44506&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44506&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44506&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44506&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44506&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44506&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44506&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44506&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44506&r=mysqlcfg
#42063 [NEW]: strtoupper() and locales: inconsistent behavior
From: jo at feuersee dot de
Operating system: Linux
PHP version: 5.2.3
PHP Bug Type: I18N and L10N related
Bug description: strtoupper() and locales: inconsistent behavior
Description:
I stumbled about this issue while debugging a project which uses PEAR
XML_Parser which relys on the assumption that strtoupper() works for all
US-ASCII characters no matter which locale or encoding.
Unfortunately, it does not.
This has been discussed in PHP bugs
22003
21771
35583
The letter i isn't converted to I by strtoupper() when the locale is set
to turkish (via setlocale(LC_ALL, 'tr_TR'))
However, the letter i is converted to I by strtoupper() when the locale is
set to turkish (via setlocale(LC_ALL, 'tr'))
mb_strtoupper() does work under all encodings.
Now, despite blaming the Unicode guys or the turkish language or
whatever:
How are we supposed to code properly under these circumstances?
My proposal:
strtoupper/lower() claim to be locale aware, but they really aren't (try
to upperchase umlaut äöü under locale de_DE - doesn't work at all). Thus,
redefining these functions to work for 7-bit encoded (US-ASCII) data _only_
won't change anything. Skip the locale dependency, then the locale tr_TR
will work.
Reproduce code:
---
[EMAIL PROTECTED] ~> php -r 'setlocale(LC_ALL, "tr"); $text = "begin";
printf("%s
%s\n", strtoupper($text), bin2hex(strtoupper($text))); '
BEGIN 424547494e
[EMAIL PROTECTED] ~> php -r 'setlocale(LC_ALL, "tr_TR"); $text = "begin";
printf("%s
%s\n", strtoupper($text), bin2hex(strtoupper($text))); '
BEG�N 424547dd4e
[EMAIL PROTECTED] ~> php -r 'setlocale(LC_ALL, "tr_TR.UTF-8"); $text = "begin";
printf("%s %s\n", strtoupper($text), bin2hex(strtoupper($text))); '
BEGiN 424547694e
Expected result:
BEGIN 424547494e
(for all locales)
Actual result:
--
(see above)
--
Edit bug report at http://bugs.php.net/?id=42063&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42063&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42063&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42063&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42063&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42063&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42063&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42063&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42063&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42063&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42063&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42063&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42063&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42063&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42063&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42063&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42063&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42063&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42063&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42063&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42063&r=mysqlcfg
#41157 [NEW]: nl_langinfo() implementation conflicts with setlocale()
From: jo at feuersee dot de
Operating system: Linux
PHP version: 5.2.1
PHP Bug Type: I18N and L10N related
Bug description: nl_langinfo() implementation conflicts with setlocale()
Description:
nl_langinfo() seems to expect that the locale has been set in the format
ll_CC (ll being the ISO 639-1 language code and CC the ISO 3166-2 country
code). All other locales (like only setting a language like 'de' or adding
an encoding like 'ja_JP.UTF-8') do result in output which looks like
locale 'C'.
This leaves nl_langinfo() unuseable, since for languages with multiple
possible encodings it is necessary to explicitly set the encoding in
setlocale() (eg. to get the strftime() format strings in a useable defined
encoding).
I compared the PHP results with the plain C API results and the
restrictions do not appear in the C version. Thus I say the PHP
implementation of nl_langinfo() is buggy.
To compare test4 with the C equivalent, here is the code:
#include
#include
#include
// char buffer[1024];
char *buffer;
int main (void)
{
buffer = setlocale(LC_ALL, "ja_JP.UTF-8");
printf("Locale: %s\n", buffer);
printf("%s\n", nl_langinfo(D_T_FMT));
return(0);
}
Reproduce code:
---
(All examples are supposed to be typed into the shell):
test1 ~> php -r 'setlocale(LC_ALL, 'C'); printf("%d: %s\n", D_T_FMT,
nl_langinfo('D_T_FMT'));'
test2 ~> php -r 'setlocale(LC_ALL, 'ja'); printf("%d: %s\n", D_T_FMT,
nl_langinfo('D_T_FMT'));'
test3 ~> php -r 'setlocale(LC_ALL, 'ja_JP'); printf("%d: %s\n", D_T_FMT,
nl_langinfo('D_T_FMT'));'
test4> php -r 'setlocale(LC_ALL, 'ja_JP.UTF-8'); printf("%d: %s\n",
D_T_FMT, nl_langinfo(D_T_FMT));'
Expected result:
test1:
131112: %a %b %e %H:%M:%S %Y
test2:
131112: %a %b %e %H:%M:%S %Y
test3: (output of C code)
131112: %Yǯ%m�d� %H%Mʬ%S�
test4: (C code gives propert UTF-8 output)
%Y年%m月%d日 %H時%M分%S秒
Actual result:
--
test1: passed
test2: fallback to locale C (passed)
test3: (output is in undefined encoding like C code, passed)
131112: %Yǯ%m�d� %H%Mʬ%S�
test4: (fallback to C locale, _not_ passed):
131112: %a %b %e %H:%M:%S %Y
--
Edit bug report at http://bugs.php.net/?id=41157&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41157&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41157&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41157&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41157&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41157&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41157&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41157&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41157&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41157&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41157&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41157&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41157&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41157&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41157&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41157&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41157&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41157&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41157&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41157&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41157&r=mysqlcfg
#38471 [NEW]: fgetcsv(): locale dependency of delimiter / enclosure arg
From: jo at feuersee dot de Operating system: Linux PHP version: 5.1.4 PHP Bug Type: Filesystem function related Bug description: fgetcsv(): locale dependency of delimiter / enclosure arg Description: fgetcsv() is affected by locale settings in a way the PHP documentation dosen't imply. It says: "Locale setting is taken into account by this function. If LANG is e.g. en_US.UTF-8, files in one-byte encoding are read wrong by this function." In the example below, reading CSV data is broken because language settings affect the character following the delimiter (even when delimiter is a 1 byte character). I expected that fgetcsv() would work independent of locale settings as long as delimiter and enclosing are US-ASCII clean. To my surprise, using multibyte UTF-8 characters (and proper locale setting) as delimiter didn't throw a warning, but didn't work as expected. It seems that only the 1st byte (the documentation says character) is used? Other side effects: The documentation isn't clear about the enclosure arg: - The enclosure arg is optional but defaults to a " - Explicit setting an empty enclosure '' throws a warning, suggesting that the CSV data requires enclosing - But fgetcsv() (with or w/o enclosure) works on both enclosed and non-enclosed CSV data, seems it's optional anyway? - It is unclear which setlocale() category arg affects fgetcsv() behavior. By testing, LC_ALL and LC_CTYPE did work, I did expect LC_COLLATE (instead of LC_CTYPE) Reproduce code: --- And give a test.csv in UTF-8 encoding with multibyte characters in the 1st place after delimiter: A;Äbc B;bcd --eof And let the PHP process either inherit LANG=C or set it explicit or add setlocale(LC_CTYPE, 'C'); above Expected result: Array ( [0] => A [1] => Äbc ) Array ( [0] => B [1] => bcd ) Actual result: -- Array ( [0] => A [1] => bc ) Array ( [0] => B [1] => bcd ) -- Edit bug report at http://bugs.php.net/?id=38471&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38471&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38471&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38471&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38471&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38471&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38471&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38471&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38471&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38471&r=support Expected behavior:http://bugs.php.net/fix.php?id=38471&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38471&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38471&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38471&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38471&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38471&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38471&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38471&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38471&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38471&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38471&r=mysqlcfg
#32551 [Bgs]: Building GD as shared lib results into "undefined symbol"
ID: 32551 User updated by: jo at feuersee dot de Reported By: jo at feuersee dot de Status: Bogus Bug Type: GD related Operating System: Linux 2.6.11 PHP Version: 5.0.4 New Comment: I am aware of that. But it was the only way to compile PHP with iconv support, thus I thought I was doing something wrong when issueing =/usr and the like. I just recompiled PHP5.0.4 with the following options: ./configure --prefix=/usr \ --with-apxs=/usr/sbin/apxs \ --with-bz2=shared,/usr \ --with-config-file-path=/etc/httpd \ --with-curl=shared,/usr --with-curlwrapper \ --with-dom-xslt=/usr \ --with-expat-dir=/usr \ --with-gettext=shared,/usr \ --with-gd=shared --with-freetype-dir=/usr --with-jpeg-dir=/usr --with-png-dir=/usr --with-tiff-dir=/usr --with-zlib-dir=/usr --with-xpm-dir=/usr --with-t1lib=/usr/local \ --with-gmp=shared,/usr \ --with-iconv=shared,/usr/local --with-iconv-dir=/usr/local \ --with-imap=shared,/usr \ --with-imap-ssl=/usr \ --with-ldap=shared,/usr \ --with-mcal=shared,/usr \ --with-mcrypt=shared,/usr \ --with-ming=shared,/usr \ --with-mm=/usr \ --with-mysql=shared,/usr \ --with-ncurses=shared,/usr \ --with-openssl=shared,/usr \ --with-qtdom=shared,/usr \ --with-pear=/usr/local/share/php \ --with-pgsql=shared,/usr \ --with-pspell=shared,/usr \ --with-readline=shared,/usr \ --with-snmp=shared,/usr \ --with-xmlrpc=shared \ --with-xsl=shared,/usr \ --with-zlib=shared,/usr \ --enable-calendar=shared \ --enable-ctype=shared \ --enable-dba=shared --with-gdbm=/usr --with-ndbm --with-db4 --with-inifiles --with-flatfiles \ --enable-dbase=shared \ --enable-dbx=shared \ --enable-dom=shared --with-xml-dir=/usr \ --enable-exif=shared \ --enable-inline-optimization \ --disable-ipv6 \ --enable-ftp=shared \ --enable-filepro=shared \ --enable-gd-imgstrttf --enable-gd-native-ttf \ --enable-mailparse \ --enable-mbstring=shared,all \ --enable-mcal=shared \ --enable-memory-limit \ --enable-overload \ --enable-shmop=shared \ --enable-soap=shared \ --enable-sockets=shared --enable-ipc \ --enable-sysvmsg=shared --enable-sysvshm=yes \ --enable-sqlite=shared \ --enable-sqlite-utf8 \ --enable-tokenizer=shared \ --enable-trans-sid \ --enable-url-includes \ --enable-versioning \ --enable-wddx=shared \ --enable-yp=shared still the mentioned problem exists. I have installed the recent libiconv 1.9.1 in /usr/local from sources. This bug doesn't sound that BOGUS to me. Previous Comments: [2005-04-03 01:08:27] [EMAIL PROTECTED] First of all: using path '/usr/lib' is incorrect. [2005-04-03 00:40:02] jo at feuersee dot de Description: I have used the very same configure params as for PHP5.0.3 (which worked and still do work): ./configure --prefix=/usr \ --with-apxs=/usr/sbin/apxs \ --with-bz2=shared,/usr/lib \ --with-config-file-path=/etc/httpd \ --with-curl=shared,/usr/lib --with-curlwrapper \ --with-dom-xslt=/usr/lib \ --with-expat-dir=/usr/lib \ --with-gettext=shared,/usr/lib \ --with-gd=shared --with-freetype-dir=/usr --with-jpeg-dir=/usr --with-png-dir=/usr --with-tiff-dir=/usr --with-zlib-dir=/usr --with-xpm-dir=/usr --with-t1lib=/usr/local \ --with-gmp=shared,/usr/lib \ --with-iconv=shared,/usr/lib --with-iconv-dir=/usr/lib \ --with-imap=shared,/usr/lib \ --with-imap-ssl=/usr/lib \ --with-ldap=shared,/usr \ --with-mcal=shared,/usr/lib \ --with-mcrypt=shared,/usr/lib \ --with-ming=shared,/usr/lib \ --with-mm=/usr \ --with-mysql=shared,/usr/lib \ --with-ncurses=shared,/usr/lib \ --with-openssl=shared,/usr \ --with-qtdom=shared,/usr/lib \ --with-pear=/usr/local/share/php \ --with-pgsql=shared,/usr/lib \ --with-pspell=shared,/usr \ --with-readline=shared,/usr/lib \ --with-snmp=shared,/usr \ --with-xmlrpc=shared \ --with-xsl=shared,/usr \ --with-zlib=shared,/usr \ --enable-calendar=shared \ --enable-ctype=shared \ --enable-dba=shared --with-gdbm=/usr --with-ndbm --with-db4 --with-inifiles --with-flatfiles \ --enable-dbase=shared \ --enable-dbx=shared \ --enable-dom=shared --with-xml-dir=/usr \ --enable-exif=shared \ --enable-inline-optimization \ --disable-ipv6 \ --enable-ftp=shared \ --enable-filepro=shared \ --enable-gd-imgstrttf --enable-gd-native-ttf \ --enable-mailparse \ --enable-mbstring=shared,all \ --enable-mcal=shared \ --enable-memory-limit \ --enable-overload \ --enable-shmop=shared \ --enable-soap=shared \ --enable-sockets=shared --enable-ipc \ --enable-sysvmsg=shared --enable-sysvshm=yes \ --enable-sqlite=shared \ --enable-sqlite-utf8 \ --enable-tokenizer=shared \ --enable-trans-sid \ --enable-url-includes \ --enable-versioning \ --enable-wddx=shared \ --enable-yp=shared After installing, when restarting apache, the following error msg appears: Warning: PHP Startup: Unable to load dynamic library '/usr/l
#32551 [NEW]: Building GD as shared lib results into "undefined symbol"
From: jo at feuersee dot de Operating system: Linux 2.6.11 PHP version: 5.0.4 PHP Bug Type: GD related Bug description: Building GD as shared lib results into "undefined symbol" Description: I have used the very same configure params as for PHP5.0.3 (which worked and still do work): ./configure --prefix=/usr \ --with-apxs=/usr/sbin/apxs \ --with-bz2=shared,/usr/lib \ --with-config-file-path=/etc/httpd \ --with-curl=shared,/usr/lib --with-curlwrapper \ --with-dom-xslt=/usr/lib \ --with-expat-dir=/usr/lib \ --with-gettext=shared,/usr/lib \ --with-gd=shared --with-freetype-dir=/usr --with-jpeg-dir=/usr --with-png-dir=/usr --with-tiff-dir=/usr --with-zlib-dir=/usr --with-xpm-dir=/usr --with-t1lib=/usr/local \ --with-gmp=shared,/usr/lib \ --with-iconv=shared,/usr/lib --with-iconv-dir=/usr/lib \ --with-imap=shared,/usr/lib \ --with-imap-ssl=/usr/lib \ --with-ldap=shared,/usr \ --with-mcal=shared,/usr/lib \ --with-mcrypt=shared,/usr/lib \ --with-ming=shared,/usr/lib \ --with-mm=/usr \ --with-mysql=shared,/usr/lib \ --with-ncurses=shared,/usr/lib \ --with-openssl=shared,/usr \ --with-qtdom=shared,/usr/lib \ --with-pear=/usr/local/share/php \ --with-pgsql=shared,/usr/lib \ --with-pspell=shared,/usr \ --with-readline=shared,/usr/lib \ --with-snmp=shared,/usr \ --with-xmlrpc=shared \ --with-xsl=shared,/usr \ --with-zlib=shared,/usr \ --enable-calendar=shared \ --enable-ctype=shared \ --enable-dba=shared --with-gdbm=/usr --with-ndbm --with-db4 --with-inifiles --with-flatfiles \ --enable-dbase=shared \ --enable-dbx=shared \ --enable-dom=shared --with-xml-dir=/usr \ --enable-exif=shared \ --enable-inline-optimization \ --disable-ipv6 \ --enable-ftp=shared \ --enable-filepro=shared \ --enable-gd-imgstrttf --enable-gd-native-ttf \ --enable-mailparse \ --enable-mbstring=shared,all \ --enable-mcal=shared \ --enable-memory-limit \ --enable-overload \ --enable-shmop=shared \ --enable-soap=shared \ --enable-sockets=shared --enable-ipc \ --enable-sysvmsg=shared --enable-sysvshm=yes \ --enable-sqlite=shared \ --enable-sqlite-utf8 \ --enable-tokenizer=shared \ --enable-trans-sid \ --enable-url-includes \ --enable-versioning \ --enable-wddx=shared \ --enable-yp=shared After installing, when restarting apache, the following error msg appears: Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/extensions/no-debug-non-zts-20041030/gd.so' - /usr/lib/php/extensions/no-debug-non-zts-20041030/gd.so: undefined symbol: libiconv_open in Unknown on line 0 PHP5.0.4 works, but w/o any GDlib support since the shared module won't get loaded. -- Edit bug report at http://bugs.php.net/?id=32551&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32551&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32551&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32551&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32551&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32551&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32551&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32551&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32551&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32551&r=support Expected behavior: http://bugs.php.net/fix.php?id=32551&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32551&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32551&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32551&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32551&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32551&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32551&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32551&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32551&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32551&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32551&r=mysqlcfg
