Hi all,
Is there any chance of getting the unicode.semantics issue sorted soon?
We put phar into php-src yesterday. I updated the extension in CVS HEAD just
to allow it to build, but it'd be good to have forward/sideward
compatibility from 5.3.0 in my view (and Greg's).
I wrote a macro to allow us to use the same code for the extension in both
branches, but it occurs to me that the zstr union definition might change or
even disappear when PHP 6 becomes Unicode-only. Is that likely? I don't
know. So keeping it all together is total guesswork at present.
Clues would be good at this stage. I.e. if zstr is definitely staying in its
present form it'd be good to know that today.
Thanks,
- Steph
Steph,
I wrote a macro to allow us to use the same code for the extension in both
branches, but it occurs to me that the zstr union definition might change or
even disappear when PHP 6 becomes Unicode-only. Is that likely? I don't
know. So keeping it all together is total guesswork at present.
In general: No. We still need both string types at most places, the
effect of the u.s setting is the default type for strings in the engine.
Most other functions still need to work with both kinds of string as
parameter and such. (strlen(b"äöü") vs. atrlen(u"äöü"))
johannes
Hi all,
I wrote a macro to allow us to use the same code for the extension in
both
branches, but it occurs to me that the zstr union definition might change
or
even disappear when PHP 6 becomes Unicode-only. Is that likely? I don't
know. So keeping it all together is total guesswork at present.In general: No. We still need both string types at most places, the
effect of the u.s setting is the default type for strings in the engine.
Most other functions still need to work with both kinds of string as
parameter and such. (strlen(b"äöü") vs. atrlen(u"äöü"))
Thanks for that Johannes, done. Next question: should we gear our tests to
unicode.semantics=off (thereby making us look good on current gcov) or
unicode.semantics=on (thereby saving extra work in the not-so-distant
future)?
I've found a couple of minor things that could prevent phars created under
5_3 from running under 6 with unicode on. They're easily fixable in 5_3, but
I have to say that optimizing for unicode=off wouldn't have uncovered these.
Another question - when the unicode.semantics switch goes (and please,
please make it soon someone), the PHP 5 test suite script works fine as-is
with PHP 6. The one currently in HEAD is probably a bit too clever, trying
to accommodate both scenarios and failing - unicode=on can't be tested at
present with that script. So can we revert to the run-tests.php from 5_3
branch please?
Thanks,
- Steph
johannes