Bug #18556 [Com]: Setting locale to 'tr_TR' lowercases class names
Edit report at https://bugs.php.net/bug.php?id=18556edit=1 ID: 18556 Comment by: sweiss at stylesight dot com Reported by:spud at nothingness dot org Summary:Setting locale to 'tr_TR' lowercases class names Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Linux (RedHat 7.2) PHP Version:5CVS, 4CVS (2005-10-04) Assigned To:dmitry Block user comment: N Private report: N New Comment: No, the problem results because lowercase i (in most languages) and uppercase I (in most languages) are not actually considered to be the upper/lower variant of the same letter in Turkish. In Turkish, the undotted ı is the lowercase of I, and the dotted İ is the uppercase of i. If you have a class named Image, it will break if the locale is changed to turkish because class_exists() function uses zend_str_tolower(), and changes the case on all classes, because they are supposed to be case insensitive. Someone else above explained it very well: class_exists() function uses zend_str_tolower(). zend_str_tolower() uses zend_tolower(). zend_tolower() uses _tolower_l() on Windows and tolower() on other oses. _tolower_l() is not locale aware. tolower() is LC_CTYPE aware. Please, oh please, can someone fix this already? It has been a very long time and it's extremely annoying and difficult to work around if you have a large multilingual website. Previous Comments: [2011-09-15 19:51:48] robin dot bussiek at googlemail dot com I am sorry to ask this for my understanding: Is it true, that the cause for this bug lies in a false inclusion of the I character in the Turkish character set - and therefore results in an unnecessary replacement? If so, my green knowledge leads me to the assumption, that a fix should be rather simple. **duck**, Robin [2011-08-08 12:02:30] tolga at profelis dot com dot tr php -v PHP 5.3.3-7+squeeze3 with Suhosin-Patch (cli) (built: Jun 28 2011 08:24:40) Problem continues! [2010-08-28 12:14:34] web-coder at list dot ru Thanks to Alexey dot Rybak at gmail dot com for a patch, that fix problem if you use only ASCII-symbols in functions/methods names: http://dev.badoo.com/custom_strtolower.diff [2010-08-27 19:17:55] web-coder at list dot ru Please tell me php version, where this problem is already solved. Thanks. [2010-08-09 07:55:30] stevemw at mac dot com +1. I get complaints about the side-effects of this on a weekly basis. Especially awful if you are asked to add turkish support after the fact, when you already have a large codebase. 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 https://bugs.php.net/bug.php?id=18556 -- Edit this bug report at https://bugs.php.net/bug.php?id=18556edit=1
Bug #35050 [Com]: Capital I letters in func/class method names do not work with turkish locale
Edit report at http://bugs.php.net/bug.php?id=35050edit=1
ID: 35050
Comment by: sweiss at stylesight dot com
Reported by: satanistlav at mail dot ru
Summary: Capital I letters in func/class method names do not
work with turkish locale
Status: Wont fix
Type: Bug
Package: Scripting Engine problem
Operating System: Linux
PHP Version: 5CVS-2005-11-01 (cvs)
New Comment:
Requesting a fix for this... this has been going on for almost 5 years,
yet the
proper fix for the problem also only takes that many lines of code,
according to
a different bug report, which was rejected on a technicality. The
workaround
suggested means that none of my turkish is capitalized correctly. This
is
really not going over well. Please, please, please, at least make the
fix
listed in Bug #35050 an option that we can set in the php.ini or ideally
with
ini_set or *something*, if it causes problems for other programmers, and
if it
doesn't, can it just be fixed already? It is not going to be pretty
when I have
to go tell them that the turkish translation they've made is going to be
permanently crippled until PHP 6 is released, and our code is updated to
support
it... and it looks like PHP 6 just went back to square one so this could
be
quite a long time.
Previous Comments:
[2007-09-06 11:22:42] j...@php.net
Patch by Tomas Kuliavas:
http://www.topolis.lt/php/#35050
[2005-11-15 13:39:07] der...@php.net
We discussed it and this will not be addressed in PHP 5, but only from
PHP 6 and higher. Please make sure your set the correct locale before
starting the script - or before including files that define elements
that contain upper case I's.
[2005-11-01 15:17:54] satanistlav at mail dot ru
I have uploaded your code to the server and I still have the same error!
http://www.yda.com.tr/test.php
[2005-11-01 15:14:14] satanistlav at mail dot ru
I have multilingual site. Locales are set to en_US.ISO-8859-1 in Enlgish
side of the site and tr_TR.ISO-8859-9 in Turkish for LC_ALL
[2005-11-01 15:12:29] der...@php.net
I can reproduce this with the following short script:
?php
class foo
{
function IsHere()
{
echo here\n;
}
}
echo setlocale(LC_ALL, 'tr_TR'), \n;
$f = new foo();
$f-IsHere();
?
(You need to have the tr_TR locale installed for this).
It does work properly with PHP 5.1 actually, and it has to to with the
zend_str_tolower() function which uses the tolower() libc call, which
uses the locale. As in Turkish the I does not lowercase to i you can get
weird things. This is why we should get rid of case insensitive function
names.
It also works with normal function names (instead of classes' methods)
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=35050
--
Edit this bug report at http://bugs.php.net/bug.php?id=35050edit=1
#49431 [NEW]: Cannot define class constant with constant value
From: sweiss at stylesight dot com
Operating system: Debian
PHP version: 5.3.0
PHP Bug Type: Class/Object related
Bug description: Cannot define class constant with constant value
Description:
In the PHP documentation it states:
It is possible to define constant values on a per-class basis
remaining the same and unchangeable. Constants differ from normal
variables in that you don't use the $ symbol to declare or use them.
The value must be a constant expression, not (for example) a
variable, a class member, result of a mathematical operation or a
function call.
This is however not entirely the case.
If you define a constant within a class based on another constant, it
will not work, despite the fact that it is a constant value.
In the given example, X_CONST . Y is a constant composed of two
other constants - no variables, class members, math expressions, or
function calls.
And, in fact, for normal, non-class constants, this is totally
possible:
define(Y_CONST, X_CONST . Y);
is totally valid.
At the very least the documentation should be updated to reflect
simply that a class constant may only be defined as a simple scalar
value, and not just any constant expression.
Reproduce code:
---
define(X_CONST, Const);
class TestClass {
const Y_CONST = X_CONST . Y;
function test() {
return self::Y_CONST;
}
}
$a = new TestClass();
var_dump($a-test());
Expected result:
(string) ConstY
Actual result:
--
Parse error: syntax error, unexpected '.', expecting ',' or ';' in line
5
--
Edit bug report at http://bugs.php.net/?id=49431edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49431r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49431r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49431r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49431r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49431r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49431r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49431r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49431r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49431r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49431r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49431r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49431r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49431r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49431r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49431r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49431r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49431r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49431r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49431r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49431r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49431r=mysqlcfg
#48871 [NEW]: strtoupper does not make all characters upper with proper locale set
From: sweiss at stylesight dot com Operating system: Debian Etch and RHEL 5 PHP version: 5.3.0 PHP Bug Type: I18N and L10N related Bug description: strtoupper does not make all characters upper with proper locale set Description: As reported and closed out in 22003 21771 35583 42063 strtoupper() does not actually convert accented characters to uppercase, even if you do set the locale. As PHP 5.3 was only released days ago it seems unlikely 6 will be out anytime soon. If this feature isn't actually going to be there for a long time, then it would be much more considerate to stop stating you have this feature already in your documentation. We used strtoupper everywhere on a 300-file localization project and had no reason to believe it wouldn't work through 3 different (CJK) languages until we got to Spanish and realized it was bogus. Reproduce code: --- var_dump(setlocale(LC_ALL, es_MX.utf8)); $str = á\n; echo(strtoupper($str)); Expected result: string(10) es_MX.utf8 Á Actual result: -- string(10) es_MX.utf8 á -- Edit bug report at http://bugs.php.net/?id=48871edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48871r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48871r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48871r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48871r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48871r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48871r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48871r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48871r=needscript Try newer version: http://bugs.php.net/fix.php?id=48871r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48871r=support Expected behavior: http://bugs.php.net/fix.php?id=48871r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48871r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48871r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48871r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48871r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48871r=dst IIS Stability: http://bugs.php.net/fix.php?id=48871r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48871r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48871r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48871r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48871r=mysqlcfg
#43053 [Com]: Scientific notation
ID: 43053
Comment by: sweiss at stylesight dot com
Reported By: owner at dragon-hearts dot net
Status: Verified
Bug Type: Scripting Engine problem
Operating System: Centos4
PHP Version: 5CVS-2007-10-25
New Comment:
You guys *have* to make changes like this more explicitly stated... It
took forever to even realize the problem we were having lay with PHP
and
not the Javascript it was printing it out to - I definitely read the
changelog and definitely did not pick up on the fact that all my
numbers
were going to suddenly come out in this totally useless format now.
*Seriously Frustrating* - Couldn't this have just been an ini option
for
the people that wanted it?
Previous Comments:
[2008-04-18 13:07:41] rbro at hotmail dot com
Thanks for your help - that definitely seems to fix the problem. I
manually applied your changes since I wanted to test it against the PHP
5.2.5 source, but I'm getting consistent output now when working with
floats.
[2008-04-18 01:34:28] int-e at gmx dot de
Here's a patch that fixes the problem.
http://int-e.home.tlink.de/php/php-printf.patch
There are three changes here:
1) get rid of a hack in zend_dtoa() that sometimes kept trailing zeros
(which caused the inconsistent behaviour between printing 120 and
130)
2) change php_gcvt() to switch to E format for large numbers if the
number wouldn't fit into precision digits.
3) update a few tests to reflect the change to the precision semantics.
I believe that in each of these cases, the test was flawed. Note that a
precision of 14 (the default) means that 15 digit numbers should be
printed in E notation, at least that's how I read the sprintf
documentation.
[2008-04-15 22:37:33] rbro at hotmail dot com
Your examples work correctly for me in PHP 5.2.1, so I'm not sure if
the issue was caused by change you mentioned or something else, but it
definitely happens for me in PHP 5.2.2 and later.
[2008-04-15 20:43:16] marek dot chodor at gmail dot com
on
PHP Version 5.2.6RC1-pl1-gentoo
and PHP 5.2.4 Fedora7
the same problem
$ php -r echo 12000;
12000
$ php -r echo (double)12000;
1.2E+8
$ php -r echo (int)(double)12000;
12000
It could be related to this change in PHP 5.2.1:
# Changed double-to-string utilities to use BSD implementation.
(Dmitry, Tony)
[2008-04-15 09:08:48] ali at adcworks dot com
I am receiving longs via SOAP responses which represent IDs of
accounts. Due to some issue with PHP and long values when we retrieve
accounts using the same IDs we receive, we get other peoples' accounts
back - not good!
I have found the core problem and the snippet of code below shows that
the correct ID of 2853622757 is transformed into the incorrect
ID of 2853622752 (last number goes down 5).
?php
$long = 2853622757;
function f0($long) { return $long; }
function f1($long) { return sprintf ( %.0f, $long ); }
function f2($long) { return number_format($long, 0, '.', ''); }
?
h1F0 (no formatting) /h1
?= f0($long) ?
h1F1 (sprintf) /h1
?= f1($long) ?
h1F2 (number_format) /h1
?= f2($long) ?
OUTPUT
==
F0 (no formatting)
2.854E+17
F1 (sprintf)
2853622752
F2 (number_format)
2853622752
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/43053
--
Edit this bug report at http://bugs.php.net/?id=43053edit=1
