# Annotated PHP 5->7 extension diff

- Thread: https://externals.io/message/81967
- Original archive: https://news-web.php.net/php.internals/81967
- Started by Rasmus Lerdorf on 2015-02-05T22:28:37+00:00
- Messages: 37
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/81967.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #81967 — Rasmus Lerdorf — 2015-02-05T22:28:37+00:00

URL: https://externals.io/message/81967#81967

We have had quite a number of changes to the extension API and it
worries me a little bit how long it will take everyone to get their
extensions ported. We have UPGRADING.INTERNALS which still needs some
love, but even if that covered everything it is sometimes hard to match
a bullet point in a long list of changes to actual code.

Having just finished porting php-memcached (with help from Xinchen) to
PHP7 I was wondering if it wouldn't be worthwhile to annotate the diff
and explain why each change was made. The extension is complicated
enough to cover most of the changes the bulk of extension authors need
to worry about.

The diff is easy enough to grab:

  git clone https://github.com/php-memcached-dev/php-memcached.git
  cd php-memcached
  git checkout php7
  git diff master php7

It looks like this:

  https://gist.github.com/anonymous/15cbc9947edb4f0a71fd

Any suggestions for how to handle annotating it? We could turn it into a
fake PR and mark it up using github's PR comments. But is there
something more suited for this out there?

-Rasmus

---

## #81969 — guilhermeblanco@gmail.com — 2015-02-05T22:41:09+00:00

URL: https://externals.io/message/81967#81969 · In reply to: #81967

Hi Rasmus,

Thanks for the highlight.
My biggest concern about all this breakage done for NG could somehow be
minimized by providing possible alternate implementations that could work
both backwards compatible and forwards compatible?
I just don't want to work on extensions I support that would never be
usable in earlier versions once finished the update.

Maybe it would be interesting to have samples of before/after (like you
did) and also samples of of compatibility pieces for PHP 7- and PHP 7+.


Regards,



> We have had quite a number of changes to the extension API and it
> worries me a little bit how long it will take everyone to get their
> extensions ported. We have UPGRADING.INTERNALS which still needs some
> love, but even if that covered everything it is sometimes hard to match
> a bullet point in a long list of changes to actual code.
>
> Having just finished porting php-memcached (with help from Xinchen) to
> PHP7 I was wondering if it wouldn't be worthwhile to annotate the diff
> and explain why each change was made. The extension is complicated
> enough to cover most of the changes the bulk of extension authors need
> to worry about.
>
> The diff is easy enough to grab:
>
>   git clone https://github.com/php-memcached-dev/php-memcached.git
>   cd php-memcached
>   git checkout php7
>   git diff master php7
>
> It looks like this:
>
>   https://gist.github.com/anonymous/15cbc9947edb4f0a71fd
>
> Any suggestions for how to handle annotating it? We could turn it into a
> fake PR and mark it up using github's PR comments. But is there
> something more suited for this out there?
>
> -Rasmus
>
>


-- 
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

---

## #81974 — Lester Caine — 2015-02-05T23:21:00+00:00

URL: https://externals.io/message/81967#81974 · In reply to: #81967

>   https://gist.github.com/anonymous/15cbc9947edb4f0a71fd
> 
> Any suggestions for how to handle annotating it? We could turn it into a
> fake PR and mark it up using github's PR comments. But is there
> something more suited for this out there?

A few extra notes on the commit would have helped. And breaking down
some of the bigger changes to individual 'reasons'.

But http://hg.lsces.org.uk/hg/php-memcached/rev/c3c53d0ef330 is just a
little easier to read and I can scroll through the changes. It DOES need
a good set of examples to work from, and the assortment of changes to
imagick are more difficult to understand.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

## #81978 — Rasmus Lerdorf — 2015-02-05T23:44:58+00:00

URL: https://externals.io/message/81967#81978 · In reply to: #81969

> 
> Hi Rasmus,
> 
> Thanks for the highlight.
> My biggest concern about all this breakage done for NG could somehow be minimized by providing possible alternate implementations that could work both backwards compatible and forwards compatible?
> I just don't want to work on extensions I support that would never be usable in earlier versions once finished the update.
> 
> Maybe it would be interesting to have samples of before/after (like you did) and also samples of of compatibility pieces for PHP 7- and PHP 7+.

That is one of the reasons an annotated diff would be good. All the changes in the diff aren't strictly needed. I didn't need to change from "s" to "S" in ZPP and the accompanying change to zend_string for example, but I find the new API cleaner and less error-prone. 

-Rasmus

---

## #81997 — Yasuo Ohgaki — 2015-02-06T01:38:50+00:00

URL: https://externals.io/message/81967#81997 · In reply to: #81967

Hi Rasmus,



> Having just finished porting php-memcached (with help from Xinchen) to
> PHP7 I was wondering if it wouldn't be worthwhile to annotate the diff
> and explain why each change was made. The extension is complicated
> enough to cover most of the changes the bulk of extension authors need
> to worry about.
>
> The diff is easy enough to grab:
>
>   git clone https://github.com/php-memcached-dev/php-memcached.git
>   cd php-memcached
>   git checkout php7
>   git diff master php7
>
> It looks like this:
>
>   https://gist.github.com/anonymous/15cbc9947edb4f0a71fd
>

It uses session save handler uses PS_MOD() which is legacy.
I may help to adopt PS_MOD_TIMESTAMP().
It eliminates writes and boost session performance a lot if apps
do not update session data always.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #82000 — Xinchen Hui — 2015-02-06T03:00:58+00:00

URL: https://externals.io/message/81967#82000 · In reply to: #81997

Sent from my iPhone

> 
> 
> Hi Rasmus,
> 
> > […]
> 
> It uses session save handler uses PS_MOD() which is legacy.
> I may help to adopt PS_MOD_TIMESTAMP().
> It eliminates writes and boost session performance a lot if apps
> do not update session data always.
> 
nice，thanks
btw did you bench your optimization on file handler against Wordpress?

Thanks
> Regards,
> 
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net

---

## #82022 — Florian Margaine — 2015-02-06T07:51:34+00:00

URL: https://externals.io/message/81967#82022 · In reply to: #81967

Hi Rasmus,

Rasmus Lerdorf <rasmus@lerdorf.com> writes:

> It looks like this:
>
>   https://gist.github.com/anonymous/15cbc9947edb4f0a71fd
>
> Any suggestions for how to handle annotating it? We could turn it into a
> fake PR and mark it up using github's PR comments. But is there
> something more suited for this out there?

Maybe something like this would help? http://underscorejs.org/docs/underscore.html

>
> -Rasmus

Cheers,

-- 
Florian Margaine

---

## #82039 — Yasuo Ohgaki — 2015-02-06T11:06:39+00:00

URL: https://externals.io/message/81967#82039 · In reply to: #82000

Hi Xinchen,



> > […]
> wrote:
> > […]
> nice，thanks
> btw did you bench your optimization on file handler against Wordpress?


No I don't, but I have some numbers.

https://github.com/php/php-src/pull/1016

-----------------------------------------------
I've tried to get some benchmarks. It seems current system is too fast to
get obvious performance difference.

Test command: ab -c 7 -n 500000 http://localhost:8888/session.php
Test script:

<?php
ini_set('session.save_path', '/home/tmp');
ini_set('session.lazy_write', 1); // Change mode here
ini_set('session.use_strict_mode', 0);

session_id('testid');
session_start(['read_and_close'=>0]); // Change mode here
//$_SESSION['test'] = ++$_SESSION['test'];
$_SESSION['a'] = str_repeat('a', 102400);
echo '<pre>';
var_dump(session_id(), $_SESSION['test']);


Old behavior was around 15000 reqs/sec.
"read_and_close" improved it to about 20000 reqs/sec. i.e 33% faster.
"lazy_write" did not improve # of reqs, but per process httpd disk writes
was reduced from 100 MB/s to 5 MB/s. i.e. There were 12 httpd processes,
1200 MB/s writes was reduced to 60 MB/s writes.

I think this would be good enough benchmark for merging.
-----------------------------------------------

As you can see, lazy_write didn't improve files much. The reason is my
current Linux
kernel already does lazy_write for files aren't changed. I'm using Fedora
21 x86_64.

However, per process writes are reduced from 1200MB/s to 60MB/s writes.
60MB/s
writes includes writes to log. This means network traffic will be reduced.
It should
help many apps use memcached save handler.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #82045 — Xinchen Hui — 2015-02-06T14:38:41+00:00

URL: https://externals.io/message/81967#82045 · In reply to: #82039

Hey:



> Hi Xinchen,
>
> 
> > […]
>
>
> No I don't, but I have some numbers.
>
> https://github.com/php/php-src/pull/1016
>
> -----------------------------------------------
> I've tried to get some benchmarks. It seems current system is too fast to
> get obvious performance difference.
>
> Test command: ab -c 7 -n 500000 http://localhost:8888/session.php
> Test script:
>
> <?php
> ini_set('session.save_path', '/home/tmp');
> ini_set('session.lazy_write', 1); // Change mode here
> ini_set('session.use_strict_mode', 0);
>
> session_id('testid');
> session_start(['read_and_close'=>0]); // Change mode here
> //$_SESSION['test'] = ++$_SESSION['test'];
> $_SESSION['a'] = str_repeat('a', 102400);
> echo '<pre>';
> var_dump(session_id(), $_SESSION['test']);
>
>
> Old behavior was around 15000 reqs/sec.
> "read_and_close" improved it to about 20000 reqs/sec. i.e 33% faster.
> "lazy_write" did not improve # of reqs, but per process httpd disk writes
> was reduced from 100 MB/s to 5 MB/s. i.e. There were 12 httpd processes,
> 1200 MB/s writes was reduced to 60 MB/s writes.
>
> I think this would be good enough benchmark for merging.
> -----------------------------------------------
>
> As you can see, lazy_write didn't improve files much. The reason is my
> current Linux
> kernel already does lazy_write for files aren't changed. I'm using Fedora 21
> x86_64.
>
> However, per process writes are reduced from 1200MB/s to 60MB/s writes.
> 60MB/s
> writes includes writes to log. This means network traffic will be reduced.
> It should
> help many apps use memcached save handler.
>
I've benched wordpress, didn't see any obviously speedup.

thanks
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

---

## #82053 — Dan Ackroyd — 2015-02-06T16:16:09+00:00

URL: https://externals.io/message/81967#82053 · In reply to: #81967

> Any suggestions for how to handle annotating it? We could turn it into a
> fake PR and mark it up using github's PR comments.

I think that's a good idea. It is very easy for people to ask
questions about any change that they don't understand on the exact
lines that are confusing them.

Also, I found it useful when converting Imagick to have a checklist of
everything that needed to be done, in a simple format, rather than the
full explanation of the changes at
https://wiki.php.net/phpng-upgrading. That allowed me to search for
the things that needed fixing.

You could then put links to the PR from checklist for an example of
the change in place.

cheers
Dan


An incomplete checklist for migrating an extension to PHP7
------------------------------------------------------------------------------

1) Parse parameters changed from zval ** to just zval*

- zval **pzv;
- if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "Z", &pzv) == FAILURE) {
+ zval *zv;
+ if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "z", &zv) == FAILURE) {


2) Geting value from a reference has changed:

- if (Z_ISREF_P(zv) && Z_TYPE_P(zv) == IS_ARRAY) {
+ if (Z_ISREF_P(zv) && Z_TYPE_P(Z_REFVAL_P(zv)) == IS_ARRAY) {


3) remove IS_BOOL, replace with IS_TRUE or IS_FALSE

- if ((Z_TYPE_PP(item) == IS_BOOL || Z_TYPE_PP(item) == IS_LONG) &&
Z_LVAL_PP(item)) {
+ if (Z_TYPE_P(item) == IS_TRUE || (Z_TYPE_P(item) == IS_LONG &&
Z_LVAL_P(item))) {


4) change Z_ADDREF_P

- Z_ADDREF_P(zv)
+ if (Z_REFCOUNTED_P(zv)) {Z_ADDREF_P(zv);}
# or equivalently
+ Z_TRY_ADDREF_P(zv);

5) zval values should be copied using ZVAL_COPY_VALUE() macro

6) Nulling things
If you converted a zval* into a zval and previously used `NULL` to
indicate an undefined value,
you can now use the IS_UNDEF type instead. It can be set using
ZVAL_UNDEF(&zv) and
checked using if (Z_ISUNDEF(zv)).

7) Copying zvals to avoid modification not needed as much. You can get
the value directly.

- zval tmp;
- ZVAL_COPY_VALUE(&tmp, zv);
- zval_copy_ctor(&tmp);
- convert_to_string(&tmp);
- // ...
- zval_dtor(&tmp);
+ zend_string *str = zval_get_string(zv);
+ // ...
+ STR_RELEASE(str);


8) Change string access from Z_STRVAL_P for intern checking
- if (IS_INTERNED(Z_STRVAL_P(zv))) {
+ if (IS_INTERNED(Z_STR_P(zv))) {


9) Creation of zval_string, remove redundant param

- ZVAL_STRINGL(zv, str, len, 1);
+ ZVAL_STRINGL(zv, str, len);

- ZVAL_STRING(zv, str, 0);
+ ZVAL_STRING(zv, str);
+ efree(str);


10) Zend_hash_find has changed
- if (zend_hash_find(ht, Z_STRVAL_P(key), Z_STRLEN_P(key)+1,
(void**)&zv_ptr) == SUCCESS) {
+ if ((zv = zend_hash_find(ht, Z_STR_P(key))) != NULL) {


11) Change zend_string is used instead of char * and len for parameters
- char *str;
- int len;
- if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s", &str,
&len) == FAILURE) {
+ zend_string *str;
+ if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "S", &str) == FAILURE) {


12) References access has changed.

- zval **ret;
- if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "Z", &ret) == FAILURE) {
+ zval *ret;
+ if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "z/", &ret) == FAILURE) {
    return;
  }
- ZVAL_LONG(*ret, 0);
+ ZVAL_LONG(ret, 0);


13) Arrays are initialised with

- MAKE_STD_ZVAL(tmp);
- array_init(tmp);
+ ZVAL_NEW_ARR(&tmp);
+ array_init(&tmp);


14) Iterating over a hash has a macro, and the key has been changd to zend_ulong

- ulong num_key;
+ zend_ulong num_key;

- for (zend_hash_internal_pointer_reset(Z_ARRVAL_P(param_array));
- zend_hash_get_current_data(Z_ARRVAL_P(param_array), (void **)
&ppzval) == SUCCESS;
- zend_hash_move_forward(Z_ARRVAL_P(param_array)), i++)
- {
+ ZEND_HASH_FOREACH_KEY_VAL(Z_ARRVAL_P(param_array), num_key, key, pzvalue) {
+ zval tmp_zval, *tmp_pzval;
+ long value = 0;

+ } ZEND_HASH_FOREACH_END();


15) Remove all MAKE_STD_ZVAL and turn those variables from  "zval
*zv;" to "zval zv;"

16) TSRM macros now do nothing. They can either be left in place or
removed if you do not need to support 5.x

---

## #82054 — Lester Caine — 2015-02-06T16:25:26+00:00

URL: https://externals.io/message/81967#82054 · In reply to: #82053

> Also, I found it useful when converting Imagick to have a checklist of
> everything that needed to be done, in a simple format, rather than the
> full explanation of the changes at

Is that in a publishable format Dan?
I'm looking to pull magickwand up as well but still a little lost on
what needs doing ...

Also I still have not fathomed out why I don't get a list of extensions
for imagick ...

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

## #82064 — Anatol Belski — 2015-02-06T19:43:11+00:00

URL: https://externals.io/message/81967#82064 · In reply to: #82053

Hi Dan,


> 
>
> > […]
>
> I think that's a good idea. It is very easy for people to ask
> questions about any change that they don't understand on the exact lines
> that are confusing them.
>
> Also, I found it useful when converting Imagick to have a checklist of
> everything that needed to be done, in a simple format, rather than the full
> explanation of the changes at https://wiki.php.net/phpng-upgrading. That
> allowed me to search for the things that needed fixing.
>
> You could then put links to the PR from checklist for an example of
> the change in place.
>
regarding your ext/imagick port, please check the make logs here
http://windows.php.net/downloads/pecl/snaps/imagick/3.2.0rc1/logs/ . How
it looks, you also might find this tool useful
https://github.com/johannes/clang-php-checker/ .

Thanks.

Anatol

---

## #82075 — Pierre Joye — 2015-02-07T02:28:20+00:00

URL: https://externals.io/message/81967#82075 · In reply to: #81978

>
> On Feb 5, 2015, at 17:41, "guilhermeblanco@gmail.com" <
guilhermeblanco@gmail.com> wrote:
> > […]
minimized by providing possible alternate implementations that could work
both backwards compatible and forwards compatible?
> > […]
usable in earlier versions once finished the update.
> > […]
did) and also samples of of compatibility pieces for PHP 7- and PHP 7+.
>
> That is one of the reasons an annotated diff would be good. All the
changes in the diff aren't strictly needed. I didn't need to change from
"s" to "S" in ZPP and the accompanying change to zend_string for example,
but I find the new API cleaner and less error-prone.

What do you think about the creation of an example extension covering
almost everything one would do in an extension?

The class, methods or functions do not have to be useful but to have simple
clear examples to display the differences with extensive comments.

Doing so has the big advantage of being self contained and anyone can
contribute easily. It is also easier for someone to actually play with it
than with a diff.

I was thinking about that for a workshop I have to give in April.

Cheers
Pierre

---

## #82077 — francois@tekwire.net — 2015-02-07T02:57:57+00:00

URL: https://externals.io/message/81967#82077 · In reply to: #82075

> De : Pierre Joye [mailto:pierre.php@gmail.com]
> What do you think about the creation of an example extension covering
> almost everything one would do in an extension?
> 
> The class, methods or functions do not have to be useful but to have simple
> clear examples to display the differences with extensive comments.
> 
> Doing so has the big advantage of being self contained and anyone can
> contribute easily. It is also easier for someone to actually play with it
> than with a diff.

Maybe php-ext-gen can be useful here. It is a PHP extension generator I just wrote, with the objective to avoid splitting extension source trees to two independent branches, as differences between PHP 5 & 7 are beyond what macros can do. The other objective is to make it easier to write a typical 'bridge' extension without knowing much to the PHP API (without manipulating any zval). It could be an ideal environment for an example extension.

The current version already abstracts and generates code for argument parsing, return types, ini settings, resources, functions, constants. The source for this is a Yaml or Json synthetic description and C code reduced to the bare minimum.

It is based on pluggable generators, the primary scope being PHP5, PHP7, and HHVM. Currently, the only implemented generator is PHP 5, but PHP 7 will be easy to implement (it is based on twig templates).

The project is at https://github.com/flaupretre/php-ext-gen. Look in the examples subdir, the wiki, and tell me what you think.

Cheers

François

---

## #82078 — Pierre Joye — 2015-02-07T03:15:11+00:00

URL: https://externals.io/message/81967#82078 · In reply to: #82077

> > […]
>
> Maybe php-ext-gen can be useful here. It is a PHP extension generator I just wrote, with the objective to avoid splitting extension source trees to two independent branches, as differences between PHP 5 & 7 are beyond what macros can do. The other objective is to make it easier to write a typical 'bridge' extension without knowing much to the PHP API (without manipulating any zval). It could be an ideal environment for an example extension.
>
> The current version already abstracts and generates code for argument parsing, return types, ini settings, resources, functions, constants. The source for this is a Yaml or Json synthetic description and C code reduced to the bare minimum.
>
> It is based on pluggable generators, the primary scope being PHP5, PHP7, and HHVM. Currently, the only implemented generator is PHP 5, but PHP 7 will be easy to implement (it is based on twig templates).
>
> The project is at https://github.com/flaupretre/php-ext-gen. Look in the examples subdir, the wiki, and tell me what you think.

Not sure it will help. It is really about showing cases for deref,
duplicate, convert, iterate, etc. The zpp, return values or
functions/class/methods declaration are really the easy part here.

-- 
Pierre

@pierrejoye | http://www.libgd.org

---

## #82089 — francois@tekwire.net — 2015-02-07T10:57:42+00:00

URL: https://externals.io/message/81967#82089 · In reply to: #82078

> De : Pierre Joye [mailto:pierre.php@gmail.com]
> Not sure it will help. It is really about showing cases for deref,
> duplicate, convert, iterate, etc. The zpp, return values or
> functions/class/methods declaration are really the easy part here.

I understand. I thought it would be a nice way to enhance the abstraction layer php-ext-gen provides, as I am missing use cases. Generating glue code is just one of the project objectives. The second one is to provide an abstraction layer allowing to duplicate as few code as possible when migrating an extension to PHP 7 (HHVM is also in scope).

I already fully abstract resources, so that user code doesn't have to deal, for instance, with zend_resource structs. I also provide an API for persistent resources, which Zend does not provide. That's just an example. It can be done for many other areas.

But, if you don't want to participate, I'll integrate that myself using your examples.

Just a question : for your demo extension, would you write two branches or a single one with #ifdef directives ?

Cheers

François

---

## #82090 — Pierre Joye — 2015-02-07T11:05:49+00:00

URL: https://externals.io/message/81967#82090 · In reply to: #82089

>
> > […]
>
> I understand. I thought it would be a nice way to enhance the abstraction
layer php-ext-gen provides, as I am missing use cases. Generating glue code
is just one of the project objectives. The second one is to provide an
abstraction layer allowing to duplicate as few code as possible when
migrating an extension to PHP 7 (HHVM is also in scope).
>
> I already fully abstract resources, so that user code doesn't have to
deal, for instance, with zend_resource structs. I also provide an API for
persistent resources, which Zend does not provide. That's just an example.
It can be done for many other areas.
>
> But, if you don't want to participate, I'll integrate that myself using
your examples.

It is more a time issue and a non believer in too much generation of codes.

> Just a question : for your demo extension, would you write two branches
or a single one with #ifdef directives ?

I ported one (not oss sadly) and I end up with separate files. One for 5.x,
7.x and common helpers.

> Cheers
>
> François

---

## #82157 — Jakub Zelenka — 2015-02-08T18:14:40+00:00

URL: https://externals.io/message/81967#82157 · In reply to: #81969

On Thu, Feb 5, 2015 at 10:41 PM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:
>
> My biggest concern about all this breakage done for NG could somehow be
> minimized by providing possible alternate implementations that could work
> both backwards compatible and forwards compatible?
> I just don't want to work on extensions I support that would never be
> usable in earlier versions once finished the update.
>
>

Hi,

I have create a header that does it ( see
https://github.com/bukka/phpc/blob/master/phpc.h ). There are still quite a
few bits that need to be added  and tidied up but it already suppors most
cases that I will need in my extension.

The header probably doesn't show much (and might look a bit scary ... :) )
so I have created a testing ext that uses it. You can see the result here:
https://github.com/bukka/php-extest/blob/master/extest_compat.c

As you can see there isn't a single ifdef and it compiles and works (test
passes) for PHP 7 and 5 (tested on 5.6 but should be fine for 5.2+). It
means that it won't require any changes in PECL.

There isn't much documentation as yet because I'm still working on it. But
I plan to add it later.

Any comments or patches are welcome!

Cheers

Jakub

---

## #82173 — Jan Ehrhardt — 2015-02-08T21:06:39+00:00

URL: https://externals.io/message/81967#82173 · In reply to: #81967

Rasmus Lerdorf in php.internals (Thu, 05 Feb 2015 17:28:37 -0500):
>We have had quite a number of changes to the extension API and it
>worries me a little bit how long it will take everyone to get their
>extensions ported. We have UPGRADING.INTERNALS which still needs some
>love, but even if that covered everything it is sometimes hard to match
>a bullet point in a long list of changes to actual code.

UPGRADING.INTERNALS is far from complete. Take for instance the
substantial changes in zend_hash_index_find(_ptr). Look at
PHP_FUNCTION(dba_list) in dba.c. In PHP 5.6 that is

if (zend_hash_index_find(&EG(regular_list), i, (void **) &le)==FAILURE)
{
	continue;
}

PHP7:
if ((le = zend_hash_index_find_ptr(&EG(regular_list), i)) == NULL) {
	continue;
}

You'll have to use another macro, with a different number of arguments
and a different false test. There is nothing in UPGRADING.INTERNALS on
this. The info on this change can be found in the Wiki:
https://wiki.php.net/phpng-upgrading

But the wiki on its turn is not complete either. For instance it still
mentions

ZEND_FETCH_RESOURCE2(ib_link, ibase_db_link *, link_arg, link_id,
LE_LINK, le_link, le_plink);

Since the API cleanup interbase does not compile anymore. The reason is
that the API cleanup brought substantial changes in
ZEND_FETCH_RESOURCE2. I guess this command now must be something like

ib_link = (ibase_db_link *)zend_fetch_resource2(Z_RES_P(link_arg),
link_id, LE_LINK, le_link, le_plink);

But this is only an educated guess based on looking at changes in other
extensions. At the moment I am struggling with the PHP7 translation of
this block:

#define GET_MOVIE_RESOURCE(ff_movie_ctx) {\
  zval **_tmp_zval;\
  if (zend_hash_find(Z_OBJPROP_P(getThis()), "ffmpeg_movie",\
    sizeof("ffmpeg_movie"), (void **)&_tmp_zval) == FAILURE) {\
    zend_error(E_WARNING, "Invalid ffmpeg_movie object");\
    RETURN_FALSE;\
  }\
\
  ZEND_FETCH_RESOURCE2(ff_movie_ctx, ff_movie_context*, _tmp_zval, -1,\
    "ffmpeg_movie", le_ffmpeg_movie, le_ffmpeg_pmovie);\
}\

I have tried a lot of things, but nothing works so far...

An annotated diff would be very welcome! But more or less complete
documentation as well.

Jan

---

## #82222 — Maciej Sobaczewski — 2015-02-09T04:48:21+00:00

URL: https://externals.io/message/81967#82222 · In reply to: #82173

Hello Jan,

> An annotated diff would be very welcome! But more or less complete
> documentation as well.
>
> Jan
>

What about placing such informations in the section of PHP manual like 
http://php.net/manual/en/internals2.php (for ZE3, of course). I suspect 
that writing regular text files in repo or updating page on the wiki is 
faster, but, well, I also think that's what we have documentation for. 
It would also allow us to remove some documentation files from php-src, 
like:

- README.EXT_SKEL
- README.NEW_OUTPUT_API
- README.PARAMETERS_PARSING_API
- README.STREAMS
- README.TESTING
- README.TESTING2
- README.UNIX-BUILD-SYSTEM
- README.WIN32-BUILD-SYSTEM
- README.input_filter
- README.namespaces

or even guidelines for developers such as coding standards, release 
process etc.

We have many informations, which can live in more suitable place, IMO.

I'm totally aware that those files are tend to be more up-to-date thanks 
to placing them directly where core developers work. However, we have 
wiki pages for internals stuff, so why not move it to the manual and 
provide better "Zend Hacker's Guide"? There were some complaints about 
its incompleteness and creation of Zend Engine 3 is a great opportunity 
to fix it.

I know that you don't have much time - core development is much more 
important and it's understandable, but please consider this proposal. I 
can help with directly porting files mentioned above and changes for ZE3 
from wiki and UPGRADING.INTERNALS if it will help somehow. If so, be 
aware that I don't have skills to check its meritorical correctness, though.

Regards,
Maciej.

---

## #82228 — Xinchen Hui — 2015-02-09T06:49:43+00:00

URL: https://externals.io/message/81967#82228 · In reply to: #82173

Hey:


> Rasmus Lerdorf in php.internals (Thu, 05 Feb 2015 17:28:37 -0500):
> > […]
>
> UPGRADING.INTERNALS is far from complete. Take for instance the
> substantial changes in zend_hash_index_find(_ptr). Look at
> PHP_FUNCTION(dba_list) in dba.c. In PHP 5.6 that is
>
> if (zend_hash_index_find(&EG(regular_list), i, (void **) &le)==FAILURE)
> {
>         continue;
> }
>
> PHP7:
> if ((le = zend_hash_index_find_ptr(&EG(regular_list), i)) == NULL) {
>         continue;
> }
>
> You'll have to use another macro, with a different number of arguments
> and a different false test. There is nothing in UPGRADING.INTERNALS on
> this. The info on this change can be found in the Wiki:
> https://wiki.php.net/phpng-upgrading
>
> But the wiki on its turn is not complete either. For instance it still
> mentions
>
> ZEND_FETCH_RESOURCE2(ib_link, ibase_db_link *, link_arg, link_id,
> LE_LINK, le_link, le_plink);
>
> Since the API cleanup interbase does not compile anymore. The reason is
> that the API cleanup brought substantial changes in
> ZEND_FETCH_RESOURCE2. I guess this command now must be something like
>
> ib_link = (ibase_db_link *)zend_fetch_resource2(Z_RES_P(link_arg),
> link_id, LE_LINK, le_link, le_plink);
>
> But this is only an educated guess based on looking at changes in other
> extensions. At the moment I am struggling with the PHP7 translation of
> this block:
these are changes are made recently,  I've updated the relates section
in that wiki.

thanks
>
> #define GET_MOVIE_RESOURCE(ff_movie_ctx) {\
>   zval **_tmp_zval;\
>   if (zend_hash_find(Z_OBJPROP_P(getThis()), "ffmpeg_movie",\
>     sizeof("ffmpeg_movie"), (void **)&_tmp_zval) == FAILURE) {\
>     zend_error(E_WARNING, "Invalid ffmpeg_movie object");\
>     RETURN_FALSE;\
>   }\
> \
>   ZEND_FETCH_RESOURCE2(ff_movie_ctx, ff_movie_context*, _tmp_zval, -1,\
>     "ffmpeg_movie", le_ffmpeg_movie, le_ffmpeg_pmovie);\
> }\
>
> I have tried a lot of things, but nothing works so far...
>
> An annotated diff would be very welcome! But more or less complete
> documentation as well.
>
> Jan
>
> --
> 
> 
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

---

## #82230 — Yasuo Ohgaki — 2015-02-09T07:10:29+00:00

URL: https://externals.io/message/81967#82230 · In reply to: #82222

Hi Maciej,



> I'm totally aware that those files are tend to be more up-to-date thanks
> to placing them directly where core developers work. However, we have wiki
> pages for internals stuff, so why not move it to the manual and provide
> better "Zend Hacker's Guide"? There were some complaints about its
> incompleteness and creation of Zend Engine 3 is a great opportunity to fix
> it.


Manual build system is awesome, but writing manual is pain indeed
because it's sgml. For new release, updating the manual to current
state would be difficult. We have missing items even in text files in
source. I agree with you in general, but it's just not feasible it seems.
I also have number of doc bugs that are not fixed yet...

I had to spent few hours to know/get used to ZE3 API. However, thanks
to folks who ported most of modules, I didn't had much problem. ZE3
API is more developer friendly than ZE2 as well.

Basic stuff should be in source. IMO.
Perhaps, we should use only the Wiki for additional internal stuff from now
on.
Keeping in sync wiki and manual seems to hard, but nobody will prevent make
this effort if you would like to. ZE3 manual section is nice to have, but
it may
be better to use only wiki until we release PHP7.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #82273 — francois@tekwire.net — 2015-02-09T11:34:41+00:00

URL: https://externals.io/message/81967#82273 · In reply to: #82230

> De : yohgaki@gmail.com [mailto:yohgaki@gmail.com] De la part de Yasuo
> Ohgaki
>
> Basic stuff should be in source. IMO.
> Perhaps, we should use only the Wiki for additional internal stuff from now
> on.

+1. Documenting Zend API in docbook format is unrealistic. The whole ' PHP at the Core' chapter should go to the wiki and be replaced with a link.

Another reason is that the manual is supposed to be translated, but this part is not, and does not have to be.

Regards

François

---

## #82286 — Jan Ehrhardt — 2015-02-09T15:03:04+00:00

URL: https://externals.io/message/81967#82286 · In reply to: #82053

Dan Ackroyd in php.internals (Fri, 6 Feb 2015 16:16:09 +0000):
>
> > […]
(...)
>An incomplete checklist for migrating an extension to PHP7
>------------------------------------------------------------------------------
[snip]

Despite the extensive list of changes, imagick does not compile anymore
with the current PHP7 git head (Win32 VC11).

Jan

---

## #82297 — Lester Caine — 2015-02-09T17:57:58+00:00

URL: https://externals.io/message/81967#82297 · In reply to: #82286

> Despite the extensive list of changes, imagick does not compile anymore
> with the current PHP7 git head (Win32 VC11).

OK another day wasted but I am getting the development platform stable.

http://lsces.org.uk/phpinfo.php is my production copy, but has a broken
imagick and an out of date smarty library.

http://php7.lsces.org.uk/phpinfo.php has everything it needs and is
currently only giving nginx errors in the log

http://php56.lsces.org.uk/phpinfo.php has the latest 5.6 from git but
mbstring will not compile

http://php6.lsces.org.uk/phpinfo.php is the distributed PHP5.6.5 dump
and everything seems to be working same as php7 build, except imagick
crashes `phpinfo()` as does the php56 build.

Just need to restore the production copy to fully functional before I
get back to debugging the new stuff.

( Have some facilities set up in Eclipse but would still appreciate some
input on that for compiling source rather than managing php projects )

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

Next page: https://externals.io/message/81967.md?page=2