#35215 [NEW]: Design Discussion: setlocale and type juggling
From: timo dot hummel at 4fb dot de Operating system: any PHP version: 5.0.5 PHP Bug Type: Strings related Bug description: Design Discussion: setlocale and type juggling Description: Currently, the whole way PHP does type juggling is affected using setlocale. Right now, PHP respects the setlocale-Settings for LC_NUMERIC when doing type-juggling (e.g. converting a float to a string or when outputting data): $float = 0.12; setlocale(LC_ALL, de_DE); echo $float; The simple example above outputs 0,12. If you need to build up SQL queries, this behaviour is unwanted and causes errors: $float = 0.12; setlocale(LC_ALL, de_DE); $sql = SELECT * FROM test WHERE value=$float;; The query will be juggled to SELECT * FROM test WHERE value=0,12; - which is not the expected result. If setlocale is used, there's no way (at least not to my knowledge) to access the original, english (I also call it technical) representation of a floating point number. This is not really a bug, but rather a limitation by design, but it effectively prevents PHP developers from implementing multi-lingual applications. Reproduce code: --- ?php /* Nicer output for browsers */ echo pre; /* Predefine some variables to play around with */ $float = 0.12; $sql = SELECT * FROM test WHERE amount=; setlocale(LC_ALL, C); // Set standard locale echo strval($float). \n; // Outputs 0.12, which is OK echo $sql . $float.\n;// Outputs SELECT * FROM test WHERE amount=0.12, which can be used by a database. setlocale(LC_ALL, de_DE); // Set german locale echo strval($float). \n; // Outputs 0,12, which is OK for display purposes, but not for data processing echo $sql . $float.\n;// Outputs SELECT * FROM test WHERE amount=0,12, which cannot be used by a database with english locale. echo /pre; ? -- Edit bug report at http://bugs.php.net/?id=35215edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35215r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=35215r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=35215r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=35215r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=35215r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35215r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=35215r=needscript Try newer version: http://bugs.php.net/fix.php?id=35215r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35215r=support Expected behavior: http://bugs.php.net/fix.php?id=35215r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35215r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35215r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=35215r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35215r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=35215r=dst IIS Stability: http://bugs.php.net/fix.php?id=35215r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35215r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35215r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35215r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=35215r=mysqlcfg
#35215 [Bgs]: Design Discussion: setlocale and type juggling
ID: 35215 User updated by: timo dot hummel at 4fb dot de Reported By: timo dot hummel at 4fb dot de Status: Bogus Bug Type: Strings related Operating System: any PHP Version: 5.0.5 New Comment: I know it is not a bug, it's rather a design issue. However, I suggest to implement something to get the technical value of a float variable. This design issue renders either floating-point values or locale settings useless. Something like http://www.php.net/strval which ignores the locale settings would be more useful: $float = 0.12; $sql = SELECT * FROM test WHERE value=.strval($float, IGNORE_LOCALE); It would be nice if something like that would be included in a later version of the zend engine or in PHP itself. Previous Comments: [2005-11-14 16:47:03] [EMAIL PROTECTED] Not a bug. I don't like that behaviour either, anyway there's number_format() and *printf(). [2005-11-14 15:51:28] timo dot hummel at 4fb dot de Description: Currently, the whole way PHP does type juggling is affected using setlocale. Right now, PHP respects the setlocale-Settings for LC_NUMERIC when doing type-juggling (e.g. converting a float to a string or when outputting data): $float = 0.12; setlocale(LC_ALL, de_DE); echo $float; The simple example above outputs 0,12. If you need to build up SQL queries, this behaviour is unwanted and causes errors: $float = 0.12; setlocale(LC_ALL, de_DE); $sql = SELECT * FROM test WHERE value=$float;; The query will be juggled to SELECT * FROM test WHERE value=0,12; - which is not the expected result. If setlocale is used, there's no way (at least not to my knowledge) to access the original, english (I also call it technical) representation of a floating point number. This is not really a bug, but rather a limitation by design, but it effectively prevents PHP developers from implementing multi-lingual applications. Reproduce code: --- ?php /* Nicer output for browsers */ echo pre; /* Predefine some variables to play around with */ $float = 0.12; $sql = SELECT * FROM test WHERE amount=; setlocale(LC_ALL, C); // Set standard locale echo strval($float). \n; // Outputs 0.12, which is OK echo $sql . $float.\n;// Outputs SELECT * FROM test WHERE amount=0.12, which can be used by a database. setlocale(LC_ALL, de_DE); // Set german locale echo strval($float). \n; // Outputs 0,12, which is OK for display purposes, but not for data processing echo $sql . $float.\n;// Outputs SELECT * FROM test WHERE amount=0,12, which cannot be used by a database with english locale. echo /pre; ? -- Edit this bug report at http://bugs.php.net/?id=35215edit=1
#33589 [NEW]: Subclassing DOMXML-Classes don't work
From: timo dot hummel at 4fb dot de
Operating system: any
PHP version: 4.3.11
PHP Bug Type: DOM XML related
Bug description: Subclassing DOMXML-Classes don't work
Description:
Subclassing the classes provided by the DOMXML-Extension doesn't work. The
usual approach building object-oriented applications is that the developer
can subclass classes to save work and increase reliabilty of their
applications.
DOMXML doesn't seem to support that, see the reproduce code below.
Of course, a developer could create a private property of the class
TestElement and assign DomElement to this, but this is not the idea behind
classes and objects and should be avoided (as this would also cause
problems with multiple specialisation of classes, e.g. if TestElement
would be specialized more);
Reproduce code:
---
Test case:
?php
class TestElement extends DomElement
{
function TestElement
{
/* This doesn't work */
DomElement::DomElement(test);
/* This also doesn't work */
parent::DomElement(test);
}
}
?
However, this works:
?php
$element = new DomElement(test);
?
Actual result:
--
Warning: domelement(): Underlying object missing in file
--
Edit bug report at http://bugs.php.net/?id=33589edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33589r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33589r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33589r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33589r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33589r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33589r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33589r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33589r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33589r=support
Expected behavior: http://bugs.php.net/fix.php?id=33589r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33589r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33589r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33589r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33589r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33589r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33589r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33589r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33589r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33589r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33589r=mysqlcfg
#32790 [NEW]: Overloading builtin functions
From: timo dot hummel at 4fb dot de
Operating system: n/a
PHP version: 5.0.4
PHP Bug Type: Feature/Change Request
Bug description: Overloading builtin functions
Description:
A very helpful and nice feature for PHP would be to overload builtin
functions. As PHP5 now features the functions echo and print are calling
the method __toString if it exists in a class, that feature is still
lacking in many other functions where they may be useful (like sprintf,
printf, just to name a few).
To prevent that PHP developers have to do alot of work and to provide a
general interface, something like the following pseudo code demonstrates
overloading builtin functions:
?php
function myOwnEcho ()
{
$ts = date(Y-m-d H:i:s);
print ($ts . );
$num_args = func_num_args();
for ($i=0; $i $num_args; $i++)
{
print (func_get_arg($i));
}
}
overload_function(echo, myOwnEcho);
echo foo;
?
Results in:
2004-04-21 15:09:01 foo
I know that echo is a language construct and not a function, it's just
been used because most PHP developers use echo for output.
--
Edit bug report at http://bugs.php.net/?id=32790edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32790r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32790r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32790r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32790r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32790r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32790r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32790r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32790r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32790r=support
Expected behavior: http://bugs.php.net/fix.php?id=32790r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32790r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32790r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32790r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32790r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32790r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32790r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32790r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32790r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32790r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32790r=mysqlcfg
#21965 [Com]: gettext uses entries out of different files at the same time
ID: 21965 Comment by: timo dot hummel at 4fb dot de Reported By: thorsten dot kussler at communardo dot de Status: No Feedback Bug Type: Gettext related Operating System: Solaris PHP Version: 4.2.3 New Comment: I can confirm this. This bug especially occurs when the following conditions are met: - Multiple domains - Switching forth and back between different languages I reproduced this on a RedHat 9 system, with the following results: After a certain period of time, the strings for any second textdomain are switching between the translated and untranslated string; seems like it's because the different HTTP server processes. After restarting the web server, the problems can't be reproduced, or when the path is being changed. Does the PHP gettext implementation cache the results after getting the gettext string from the gettext library? That would explain the troubles. Previous Comments: [2003-07-20 10:40:41] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2003-07-15 02:21:18] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip And if it still happens, provide a short test script. [2003-07-15 02:19:18] thorsten dot kussler at communardo dot de The configure line was: './configure' '--with-oci8=/home/oracle/product/8.1.7' '--with-apxs=/usr/local/apache/bin/apxs' '--with-gettext=/usr/local' '--with-ldap=/usr' and a second version directly compiled with Apache (--with-Apache) [2003-07-12 23:37:49] [EMAIL PROTECTED] I bet this happens with later PHP versions, like 4.3.2 too? What is the full configure line you have used to configure PHP ?? [2003-01-30 12:20:35] thorsten dot kussler at communardo dot de I thought that it might be a problem. PHP is compiled --width-apache and not as an CGI. BUT: I set explicitly the LC_MESAGES var infront of each call of gettext because of that. The behavior is the same if i'm the only user on the server. How is that behavior explicable with thread conflicts ??? I have no idea iliaa have you any other experiences with that phenomena or examples of problematic system configurations? 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/21965 -- Edit this bug report at http://bugs.php.net/?id=21965edit=1
#24604 [NEW]: SAFE_MODE design issues
From: timo dot hummel at 4fb dot de Operating system: SuSE Linux 8.2 Linux 2.4.19 PHP version: Irrelevant PHP Bug Type: *Directory/Filesystem functions Bug description: SAFE_MODE design issues Description: Hello bug processors, please read the following bug report carefully, as it makes file and directory operations completely useless. At the end of this report, you find recommendations about what we should do. Take a breath, it's quite a bunch of stuff to read and understand. Remember that the following is only an example, but which could be applied to almost every system running PHP with SAFE_MODE and where scripts need to perform file and directory operations. As you might all know, providers tend to host multiple domains on a single machine. In the example, Apache runs as the system user wwwrun, and we have a client user which has the system user client. We have the following script: ?php mkdir(test); ? in the htdocs directory of the webserver: -rw-r--r-- 1 client users 24 test.php given the fact that the directory where test.php resides is owned by client, test.php was called via the web and SAFE_MODE is on, the following happens: - the directory test will be created - the directory test has the owner wwwrun - any further operations with the directory test will fail since SAFE_MODE is on and don't allow any operations on files and/or directories not owned by the owner of the script This introduces another problem: move_uploaded_file will fail in the above scenario. The htdocs directory of client is writable and owned by client. If now a file is uploaded, it is stored in the PHP_TEMP_DIR specified in the php.ini with the user wwwrun, thus making move_uploaded_file fail if it should be moved to the htdocs-directory of client. The big problem with the SAFE_MODE of PHP is maybe a communications problem, but I try to propose a few solutions: 1.) Modify the SAFE_MODE concept to become consistent. I.e. if a directory is created with a script owned by client, the new directory should also belong to client instead of wwwrun, or SAFE_MODE shouldn't check the owner of the script, but rather the executor of the script. 2.) Modify the documentation of SAFE_MODE and all related file/directory functions that for the proper operation of file and directory functions, the owner and executor have to be the same user. 3.) Modify the documentation of SAFE_MODE and all related file/directory functions that for the proper operation of file and directory functions in a multi-user/single-executor scenario, safe_mode_gid should be set, including the correct group rights. The above problems are one reason why most PHP content management systems recommend to turn SAFE_MODE off in order to make file uploads working. The issue was tested with many PHP-Versions on many different systems (altough I haven't tried PHP 5.0 yet), but I'm looking forward to see the issue resolved in any way in the future. best regards, Timo -- Edit bug report at http://bugs.php.net/?id=24604edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24604r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24604r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24604r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24604r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24604r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24604r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24604r=support Expected behavior: http://bugs.php.net/fix.php?id=24604r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24604r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24604r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24604r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24604r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24604r=dst IIS Stability: http://bugs.php.net/fix.php?id=24604r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24604r=gnused
