You mean this will break:
<?php
$mask = 0xf0;
$value = $_POST['foo'] & $mask;
?>
because of Unicode?
I'd say it won't do what it did before. Though I'm not sure bit
operations on unicode make any sense at all... The problem here is the
requirement conflict - how PHP can possibly know if $_POST['foo'] is a
bit field or unicode string?
But if I haven't done something new-fangled to make a string be some
new-fangled Unicode thingie, then it's just plain old ASCII, no?
Or PHP can just assume that anyway...
It can't if we want to keep UTF-16. UTF-16 unlike UTF-8 is not
compatible with ascii. We could have some "smart downgrade" attempt -
Python 2 currently does something like this - but it won't work in all
situations.
But an old script ought to just work...
Sometimes it's not possible - if you use the same variable as string and
bitfield, and bit representation of the string changes, it can't just
work anymore, something needs to be done to bring them together.
Unicode code points can be defined with \u, but PHP6 breaks existing
octal
and hex escape sequences.
I don't understand what this means...
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
