Yes, unfortunately the end user needs to be aware enough of his
environment to either control the unicode.semantics flag or choose
the right server to run it on. Believe me, we've tried making
unicode.semantics controllable on a per-request basis, and after a
long and hard debate after partial implementation we realized it
would make both the code and the applications running on top of it
very fragile.
-Andrei
On Jun 29, 2007, at 11:11 AM, Tomas Kuliavas wrote:
It sounds like your libraries are definitely oriented towards working
with binary strings, rather than Unicode strings. So, I am not sure
why you have unicode.semantics turned on then. If you turn it off,
you will get backwards compatibility with PHP 5. And if you do that,
you can still create and work on Unicode strings, programmatically.
I've never asked to turn on unicode.semantics. I've asked to give
controls
of unicode.semantics to scripts (PHP_INI_ALL) or at least give me some
options to turn it off within a script. I don't control PHP version
used
by end user and there is a theoretical possibility that end user
will use
PHP6 with unicode.semantics=on. So I've tested scripts in
unicode.semantics=on setup. They broke. Lots of notices, broken
authentication functions, etc.
I want to make sure that I have enough controls to reduce side
effects of
unicode.semantics=on. Currently I can only ask end user to turn it off
with php_admin_flag or in php.ini.
--
Tomas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
