Hi,
On Sat, January 11, 2014 04:34, Anatol Belski wrote:
> About zpp I've got a click - the compatibility with 5.x can be integrated
> into zpp itself in 6.x. I mean look here
> http://git.php.net/?p=php-src.git;a=blob;f=Zend/zend_API.c;hb=refs/heads/
> str_size_and_int64#l326 - 'l' and 'L' was replaced with 'i' and
> 'I', but
> nothing prevents to turn those formats as aliases in 6.x. That way 'l' and
> 'i' and another pairs
> will do the same thing, new implementations can use clean semantics, and
> the old formats can be removed after 5.x EOL. This solution however won't
> force the new semantic.
>
> Another way i could suggest for zpp is similarly to docrefs using a
> wrapper like zend_parse_parameters_comp(), which would replace new for old.
> Still not very nice but would guarantee semantically correct formats.
Here's the first worky header and replacement tool variant
http://git.php.net/?p=php-src.git;a=tree;f=compat;h=166ac434f01d38119eb12160f2513cfe99c39b42;hb=refs/heads/str_size_and_int64
. The PECL readme is in progress.
After trying some extensions I come to conclusion, that both of the
compatibility variants above are not good.
The first one with aliasing gives no good feeling, after trying in
practice - it might lead even to more confusion.
The second with the *_compat() - technically it's a bit rubbish, as the
specs are literals saved in the readonly TEXT segment, so replacing on the
fly costs some allocations on the heap. While still doable, the overhead
isn't worthy.
The variant I would suggest is using ternary operator, passing both old
and new style, like
COMPAT ? "lLps" : "iIPS"
While being simple, this makes the difference good visible, so is clear.
Comparing with the breakages we had in the past like literals between 5.3
and 5.4, syntactically no #ifdef needed as it's done in place.
For the printf formats I'd suggest using ZEND_INT_FMT macros concatenated
with the format literal. The quirk here is the same as it's in the TEXT
segment. But still, with this solution no #ifdef is needed.
The latter solution suggestions are much simpler and don't need to be done
much, what do you think?
The readme is still in progress, however if curious, the current
replacement tool and header already do the job, so one can try the porting
with minimal effort.
Regards
Anatol