Even if the class name is in Unicode, we can try to convert it to ASCII
and fail only in the case when we can't find its class entry in the list.
So, I don't see any need in markers and other fairly major changes.
On 13.09.2005 04:54, Andi Gutmans wrote:
Not coming with a solution, but I believe this would be a bad idea. I
do think some people will be using IS_UNICODE strings when
unicode_semantics=off, mainly for existing applications. They may
want to serialize Unicode strings even though their classes are
IS_STRING. It might make sense to raise an error though if a "class"
is used, but if it's just a value or a hash key, then those are valid
in unicode_semantics=off.
Andi
At 06:44 AM 9/9/2005, Andrei Zmievski wrote:
Yes, serialization is a problem. I would actually advocate putting a
marker in the serialized file that indicates what the value of
unicode_semantics switch was during the serialization, and if the
value is different during deserialization, refuse to load it or start
a new session. One really should not be changing that switch on a
whim in-between sessions.
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
