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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com