FAQ

[PHP-INTERNALS] [RFC] 64 bit platform improvements for string length and integer

Anatol Belski
Jan 10, 2014 at 2:58 pm
Hi,

https://wiki.php.net/rfc/size_t_and_int64

The discussion time has come. The work on the feature branch continues.
The current patch is stable enough to be discussed.

Regards

Anatol
reply

Search Discussions

211 responses

  • Kalle Sommer Nielsen at Jan 10, 2014 at 6:29 pm
    Hi Anatol

    2014/1/10 Anatol Belski <a...@...net>:
    I absolutely love the work, time and effort you have put in to this
    branch, I've been following it closely on the sideline. There is one
    thing I'm wondering about, maybe I skipped through some of the
    sections too fast in the RFC, but what about API BC? I know you
    propose it for PHP6, but are there gonna be any macros or other
    helpers for extension developers to ease the use of #ifdefs, I realize
    things like the parameter parsing one is gonna be tough, but just as a
    general thought, I think Derick was asking something like this not too
    long ago?



    --
    regards,

    Kalle Sommer Nielsen
    kal...@...net
  • Anatol Belski at Jan 10, 2014 at 7:33 pm
    Hi Kalle,
    On Fri, January 10, 2014 19:29, Kalle Sommer Nielsen wrote:
    Hi Anatol


    2014/1/10 Anatol Belski <a...@...net>:
    I absolutely love the work, time and effort you have put in to this
    branch, I've been following it closely on the sideline. There is one thing
    I'm wondering about, maybe I skipped through some of the
    sections too fast in the RFC, but what about API BC? I know you propose it
    for PHP6, but are there gonna be any macros or other helpers for extension
    developers to ease the use of #ifdefs, I realize things like the parameter
    parsing one is gonna be tough, but just as a general thought, I think
    Derick was asking something like this not too
    long ago?
    thanks for the good words :)

    The short answer is: yes. I gonna start with that probably right as next.
    In plan is the tool for any possible automatic replacements and the
    header(s) for backward compatibility. That will be a big ease for the
    first step, though it can of course not replace the manual porting.
    Parameter parsing is one of the cracky points, but more it will be about
    the extension code adoption. Especially size_t usage, while being trivial,
    might get one in a muddle. I personally needed 1-2 hours to habituate
    size_t, so it works.

    Cheers

    anatol
  • Anatol Belski at Jan 10, 2014 at 7:40 pm

    On Fri, January 10, 2014 20:32, Anatol Belski wrote:
    Hi Kalle,

    On Fri, January 10, 2014 19:29, Kalle Sommer Nielsen wrote:

    Hi Anatol



    2014/1/10 Anatol Belski <a...@...net>:

    I absolutely love the work, time and effort you have put in to this
    branch, I've been following it closely on the sideline. There is one
    thing I'm wondering about, maybe I skipped through some of the
    sections too fast in the RFC, but what about API BC? I know you propose
    it for PHP6, but are there gonna be any macros or other helpers for
    extension developers to ease the use of #ifdefs, I realize things like
    the parameter parsing one is gonna be tough, but just as a general
    thought, I think Derick was asking something like this not too
    long ago?
    thanks for the good words :)

    The short answer is: yes. I gonna start with that probably right as next.
    In plan is the tool for any possible automatic replacements and the
    header(s) for backward compatibility. That will be a big ease for the first
    step, though it can of course not replace the manual porting. Parameter
    parsing is one of the cracky points, but more it will be about the
    extension code adoption. Especially size_t usage, while being trivial,
    might get one in a muddle. I personally needed 1-2 hours to habituate
    size_t, so it works.
    Ah, btw it is on the RFC, a couple of sentences under "Migration path for
    PECL extensions".

    Anatol
  • Jan Ehrhardt at Jan 10, 2014 at 8:31 pm
    "Anatol Belski" in php.internals (Fri, 10 Jan 2014 15:58:23 +0100):
    https://wiki.php.net/rfc/size_t_and_int64

    The discussion time has come. The work on the feature branch continues.
    The current patch is stable enough to be discussed.
    I do not have voting karma, but I can confirm that the current
    experimental branch is quite stable. I have been testing the
    experimental builds for Windows (and compiling them myself). In Drupal6,
    Drupal7, Wordpress and own own code I am getting very few different
    results compared to the 5.5 releases.

    I ran into a segfault with one Drupal7 site (but not with other Drupal7
    sites) with opcache enabled. But upon investigating that glitch, I
    discovered that PHP 5.5 NTS stumbled over the same Drupal7 site with
    opcache enabled. See the php-windows list for details.

    Keep on the good work, Anatol!

    Jan
  • Nikita Popov at Jan 10, 2014 at 9:50 pm

    On Fri, Jan 10, 2014 at 3:58 PM, Anatol Belski wrote:

    Hi,

    https://wiki.php.net/rfc/size_t_and_int64

    The discussion time has come. The work on the feature branch continues.
    The current patch is stable enough to be discussed.
    What is the reason behind the renames of IS_LONG to IS_INT (and Z_LVAL to
    Z_IVAL etc), as well as the renames in zpp (s -> S, etc)? Why can't we keep
    the old names here? That should reduce the amount of ifndefs involved a
    lot, as you'd only have to do it for the type declarations themselves, not
    for every single usage. Or is the point here to intentionally provide a
    maximum amount of BC breakage, so code doesn't "accidentally" continue to
    run (e.g. I think that without the renames extensions could continue to run
    mostly without issue on 32bit.)

    Nikita
  • Anatol Belski at Jan 10, 2014 at 11:11 pm
    Hi Nikita,
    On Fri, January 10, 2014 22:42, Nikita Popov wrote:
    On Fri, Jan 10, 2014 at 3:58 PM, Anatol Belski wrote:

    Hi,


    https://wiki.php.net/rfc/size_t_and_int64


    The discussion time has come. The work on the feature branch continues.
    The current patch is stable enough to be discussed.
    What is the reason behind the renames of IS_LONG to IS_INT (and Z_LVAL to
    Z_IVAL etc), as well as the renames in zpp (s -> S, etc)? Why can't we
    keep the old names here? That should reduce the amount of ifndefs involved
    a lot, as you'd only have to do it for the type declarations themselves,
    not for every single usage. Or is the point here to intentionally provide
    a maximum amount of BC breakage, so code doesn't "accidentally" continue
    to run (e.g. I think that without the renames extensions could continue to
    run mostly without issue on 32bit.)

    Nikita
    the renames you mention like IS_LONG -> IS_INT are thought more for
    correct semantic, as there is no firm 'long' anymore. The same for
    Z_STRLEN -> Z_STRSIZE and others. That kind of thing should be done the
    most obvious way. Well, the max BC reason you gave I like too :)

    For the same reason zend_parse_parameters() formats was changed, as it'll
    issue an error on runtime. However here I still scratch my head as that's
    a runtime issue, but it should break the compilation as well.

    Without semantic replacements many extensions would just continue to
    compile/run on 32 bit, indeed. Though because of the size_t one could
    still have some unpleasant surprise in some situation. Besides that, I'd
    really see that more like a side effect with not very clear use.

    With the #ifdef's - there shouldn't be any or should be very few. The
    compatibility header I've mentioned in one of the previous responses
    should do it one for all. It can look like

    #if PHP_MAJOR_VERSION < 6
    # define IS_INT IS_LONG
    # define php_size_t int
    .......
    #endif

    Once included and given an extension is compiled with an older PHP
    version, that defines should cover the compatibility with older semantics.
    Some more complicated solution will probably be needed for zpp to replace
    "i" with "l" and co. for the older PHP. But generally, such a header
    should make the same ext source in 6.x style compatible with 5.x branch.
    Of course some exceptions will have to take place, but i think those will
    be not more than the current mainstream already contains to separate the
    code for minor versions in 5.x branch.

    The migration path is the very next thing I have to do.

    Regards

    Anatol
  • Hannes Magnusson at Jan 11, 2014 at 1:33 am

    On Fri, Jan 10, 2014 at 3:11 PM, Anatol Belski wrote:
    Hi Nikita,
    On Fri, January 10, 2014 22:42, Nikita Popov wrote:
    On Fri, Jan 10, 2014 at 3:58 PM, Anatol Belski wrote:

    Hi,


    https://wiki.php.net/rfc/size_t_and_int64


    The discussion time has come. The work on the feature branch continues.
    The current patch is stable enough to be discussed.
    What is the reason behind the renames of IS_LONG to IS_INT (and Z_LVAL to
    Z_IVAL etc), as well as the renames in zpp (s -> S, etc)? Why can't we
    keep the old names here? That should reduce the amount of ifndefs involved
    a lot, as you'd only have to do it for the type declarations themselves,
    not for every single usage. Or is the point here to intentionally provide
    a maximum amount of BC breakage, so code doesn't "accidentally" continue
    to run (e.g. I think that without the renames extensions could continue to
    run mostly without issue on 32bit.)

    Nikita
    the renames you mention like IS_LONG -> IS_INT are thought more for
    correct semantic, as there is no firm 'long' anymore. The same for
    Z_STRLEN -> Z_STRSIZE and others. That kind of thing should be done the
    most obvious way. Well, the max BC reason you gave I like too :)

    For the same reason zend_parse_parameters() formats was changed, as it'll
    issue an error on runtime. However here I still scratch my head as that's
    a runtime issue, but it should break the compilation as well.

    Without semantic replacements many extensions would just continue to
    compile/run on 32 bit, indeed. Though because of the size_t one could
    still have some unpleasant surprise in some situation. Besides that, I'd
    really see that more like a side effect with not very clear use.

    With the #ifdef's - there shouldn't be any or should be very few. The
    compatibility header I've mentioned in one of the previous responses
    should do it one for all. It can look like

    #if PHP_MAJOR_VERSION < 6
    # define IS_INT IS_LONG
    # define php_size_t int
    .......
    #endif

    Once included and given an extension is compiled with an older PHP
    version, that defines should cover the compatibility with older semantics.
    Some more complicated solution will probably be needed for zpp to replace
    "i" with "l" and co. for the older PHP. But generally, such a header
    should make the same ext source in 6.x style compatible with 5.x branch.
    Of course some exceptions will have to take place, but i think those will
    be not more than the current mainstream already contains to separate the
    code for minor versions in 5.x branch.

    The migration path is the very next thing I have to do.

    I am really confused on that. How is the compatibility header useful
    if I still need a ifdef else for zpp and things that boil down to
    printfs, like error reporting, with 2 different arguments?

    Wouldn't it be better to not change them, but maybe force extensions
    to define a _I_SUPPORT_PHP6, if not defined refuse to build the ext
    against PHP6?

    Then all I have to do in extension is to include the compat header,
    change some of my types passed to zpp/printfs and define that macro..
    and I could support PHP5 and PHP6.

    And if I try to build against PHP6 it would result in compiler failure...
    We'd maybe need to tweak the build system a tiny bit, and phpize, for
    that to happen - but that seem to be much easier then supporting PHP5
    and 6 for extensions in the same codebase with renamed zpp values?

    -Hannes
  • Anatol Belski at Jan 11, 2014 at 3:34 am
    Hi Hannes,
    On Sat, January 11, 2014 02:33, Hannes Magnusson wrote:
    On Fri, Jan 10, 2014 at 3:11 PM, Anatol Belski wrote:

    Hi Nikita,

    On Fri, January 10, 2014 22:42, Nikita Popov wrote:

    On Fri, Jan 10, 2014 at 3:58 PM, Anatol Belski wrote:


    Hi,



    https://wiki.php.net/rfc/size_t_and_int64



    The discussion time has come. The work on the feature branch
    continues. The current patch is stable enough to be discussed.

    What is the reason behind the renames of IS_LONG to IS_INT (and
    Z_LVAL to
    Z_IVAL etc), as well as the renames in zpp (s -> S, etc)? Why can't we
    keep the old names here? That should reduce the amount of ifndefs
    involved a lot, as you'd only have to do it for the type declarations
    themselves, not for every single usage. Or is the point here to
    intentionally provide a maximum amount of BC breakage, so code doesn't
    "accidentally" continue
    to run (e.g. I think that without the renames extensions could
    continue to run mostly without issue on 32bit.)

    Nikita
    the renames you mention like IS_LONG -> IS_INT are thought more for
    correct semantic, as there is no firm 'long' anymore. The same for
    Z_STRLEN -> Z_STRSIZE and others. That kind of thing should be done the
    most obvious way. Well, the max BC reason you gave I like too :)

    For the same reason zend_parse_parameters() formats was changed, as
    it'll issue an error on runtime. However here I still scratch my head as
    that's a runtime issue, but it should break the compilation as well.

    Without semantic replacements many extensions would just continue to
    compile/run on 32 bit, indeed. Though because of the size_t one could
    still have some unpleasant surprise in some situation. Besides that,
    I'd
    really see that more like a side effect with not very clear use.

    With the #ifdef's - there shouldn't be any or should be very few. The
    compatibility header I've mentioned in one of the previous responses
    should do it one for all. It can look like

    #if PHP_MAJOR_VERSION < 6
    # define IS_INT IS_LONG
    # define php_size_t int
    .......
    #endif


    Once included and given an extension is compiled with an older PHP
    version, that defines should cover the compatibility with older
    semantics. Some more complicated solution will probably be needed for
    zpp to replace "i" with "l" and co. for the older PHP. But generally,
    such a header should make the same ext source in 6.x style compatible
    with 5.x branch. Of course some exceptions will have to take place, but
    i think those will be not more than the current mainstream already
    contains to separate the code for minor versions in 5.x branch.

    The migration path is the very next thing I have to do.

    I am really confused on that. How is the compatibility header useful
    if I still need a ifdef else for zpp and things that boil down to printfs,
    like error reporting, with 2 different arguments?
    with the php_error_docref() - very good point, the header can't help much.
    Except to define something like php_error_docref_comp() as a wrapper
    function in the compat header, so %pd and alike can be replaced on
    runtime. The code might miss some #ifdefs then, so be cleaner.
    Wouldn't it be better to not change them, but maybe force extensions
    to define a _I_SUPPORT_PHP6, if not defined refuse to build the ext against
    PHP6?
    Yeah, I'd say an explicit define to indicate PHP6 readiness is good point
    as well.

    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.

    Then all I have to do in extension is to include the compat header,
    change some of my types passed to zpp/printfs and define that macro.. and I
    could support PHP5 and PHP6.

    And if I try to build against PHP6 it would result in compiler failure...
    We'd maybe need to tweak the build system a tiny bit, and phpize, for
    that to happen - but that seem to be much easier then supporting PHP5 and 6
    for extensions in the same codebase with renamed zpp values?
    Sounds plausible to me. Parameters parsing and spprintf are the only
    cracky places I can think of now, the other macros/function renames should
    be easy covered with the compat header, so can me machinable replaced with
    some tool, even sed script.

    The _I_SUPPORT_PHP6 def (should be defined before includes) can be checked
    directly in php.h, where an #error can be thrown. That sounds like a sane
    migration workflow. Like if I'm not aware of 6.x and try to compile just
    right on, it'll reject. If I explicitly say, that i'm ready for 6.x, means
    i've done the porting work before.

    So for the migration it'd be like

    - run the replacement tool on the sources for simple semantic fixes
    - include compat header
    - #define PHP6_SUPPORTED
    - replace appropriate things with *_compat() wrappers or do some #ifdefs
    - fix datatypes for function args
    - fix the extension code where appropriate (that might be big or not, as
    Jan meant some exts he's tried was easy)
    - check if it plays good with some lib i link against, do some range
    checks eventually

    Sounds like a plan.

    Thanks for the ideas!

    Anatol
  • Jakub Zelenka at Jan 11, 2014 at 1:18 pm
    Hi Anatol,


    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.
    I agree with keeping old flags ('l', 'p', 's'...). I think that would be
    good to add range checks to zend_parse_arg_impl for these flags. If the
    casted value is bigger (LONG_MAX, INT_MAX...), then warning. It would be
    really helpful and simplify the migration for library wrappers where these
    checks needs to be usually done...

    Thanks

    Jakub
  • Anatol Belski at Jan 11, 2014 at 2:48 pm
    Hi Jakub,
    On Sat, January 11, 2014 14:18, Jakub Zelenka wrote:
    Hi Anatol,



    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/head
    s/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.
    I agree with keeping old flags ('l', 'p', 's'...). I think that would be
    good to add range checks to zend_parse_arg_impl for these flags. If the
    casted value is bigger (LONG_MAX, INT_MAX...), then warning. It would be
    really helpful and simplify the migration for library wrappers where
    these checks needs to be usually done...
    the range checks is what 'L' vs 'I' would stand for, the 'L' would be
    available as alias for 'I', so one don't has to change zpp. A good thing
    were to add type checks,

    with gcc http://gcc.gnu.org/onlinedocs/gcc/Typeof.html , however not sure
    it's available with Visual Studio.

    Regards

    Anatol
  • Jakub Zelenka at Jan 11, 2014 at 3:05 pm

    On Sat, Jan 11, 2014 at 2:48 PM, Anatol Belski wrote:

    the range checks is what 'L' vs 'I' would stand for, the 'L' would be
    available as alias for 'I', so one don't has to change zpp. A good thing
    were to add type checks,
    Oh I see. The only small objection is that these lines could lead to the
    unexpected result from the user point of view:

    if (d > ZEND_INT_MAX) {
         *p = ZEND_INT_MAX;
         break;
    } else if (d < ZEND_INT_MIN) {
         *p = ZEND_INT_MIN;
         break;
    }

    I think that would make sense to add warning here

    Also similar checks for "s" and "p" length part (size_t -> int) would be
    great too! ;)

    Thanks

    Regards

    Jakub
  • Anatol Belski at Jan 11, 2014 at 3:29 pm

    On Sat, January 11, 2014 16:05, Jakub Zelenka wrote:
    On Sat, Jan 11, 2014 at 2:48 PM, Anatol Belski wrote:

    the range checks is what 'L' vs 'I' would stand for, the 'L' would be
    available as alias for 'I', so one don't has to change zpp. A good
    thing were to add type checks,
    Oh I see. The only small objection is that these lines could lead to the
    unexpected result from the user point of view:

    if (d > ZEND_INT_MAX) { *p = ZEND_INT_MAX;
    break; } else if (d < ZEND_INT_MIN) {
    *p = ZEND_INT_MIN;
    break; }


    I think that would make sense to add warning here


    Also similar checks for "s" and "p" length part (size_t -> int) would be
    great too! ;)
    yep, that's exactly how it performs till now in the mainstream, just
    replace ZEND_INT_MAX with LONG_MAX. Adding a warning to every such case
    would cause a warning flood in many PHP apps, guaranteed :) Whereby it
    might be ok for debug mode maybe, I wouldn't do it as I can't remember any
    WTFs about the behavior.

    Cheers

    Anatol
  • Jakub Zelenka at Jan 11, 2014 at 4:08 pm

    On Sat, Jan 11, 2014 at 3:29 PM, Anatol Belski wrote:
    yep, that's exactly how it performs till now in the mainstream, just
    replace ZEND_INT_MAX with LONG_MAX. Adding a warning to every such case
    would cause a warning flood in many PHP apps, guaranteed :) Whereby it
    might be ok for debug mode maybe, I wouldn't do it as I can't remember any
    WTFs about the behavior.
    I meant adding warning only for overflow cases. Values in existing apps
    can't be bigger than LONG_MAX so I don't see how it could cause warning
    flood in the current PHP apps. I don't even think that users will be often
    using such a big values after the 64bit changes.

    The thing is that if I use value bigger than LONG_MAX after 64bit changes
    and I pass it to the function defined in extension that does not support it
    (use "l" in zpp), then I rather see warning than unexpected rounding to
    LONG_MAX... There is no way how to find out (except looking to the ext
    sources) that the big values are not supported. If I get warning, I can fix
    it in the code straight away...

    The another thing is that this checking needs to be done by other libraries
    wrappers after getting parameters because the most libraries using smaller
    types. That was exactly what I did when I worked on openssl ext for 64bit
    and I will need to do it in my fann and crypto extension. There are bunch
    of other extensions that will need to do it too (for example imagick). The
    difference with openssl changes is that the BC will need to be kept. I am
    sure that if warnings were already in zend_parse_arg_impl, then the work
    for supporting 64bit branch would much easier for me and other PECL
    extension maintainers...

    Cheers

    Jakub
  • Anatol Belski at Jan 11, 2014 at 4:53 pm
    Hi Jakub,
    On Sat, January 11, 2014 17:08, Jakub Zelenka wrote:
    On Sat, Jan 11, 2014 at 3:29 PM, Anatol Belski wrote:

    yep, that's exactly how it performs till now in the mainstream, just
    replace ZEND_INT_MAX with LONG_MAX. Adding a warning to every such case
    would cause a warning flood in many PHP apps, guaranteed :) Whereby it
    might be ok for debug mode maybe, I wouldn't do it as I can't remember
    any WTFs about the behavior.

    I meant adding warning only for overflow cases. Values in existing apps
    can't be bigger than LONG_MAX so I don't see how it could cause warning
    flood in the current PHP apps. I don't even think that users will be
    often using such a big values after the 64bit changes.

    The thing is that if I use value bigger than LONG_MAX after 64bit changes
    and I pass it to the function defined in extension that does not support
    it (use "l" in zpp), then I rather see warning than unexpected rounding to
    LONG_MAX... There is no way how to find out (except looking to the ext
    sources) that the big values are not supported. If I get warning, I can
    fix it in the code straight away...
    But isn't it the exact situation now on ILP32 vs LP64 systems? Like 32 vs
    64 bit Linux? I haven't suggested 'l' to handle the param the old way,
    just it to be an alias for 'i'. In the new code that would be as dynamic
    as php_int_t is, however 'l' as alias would retain zpp compatibility to
    the older PHP.

    For instance how much sense had such a centralized warding for the snippet
    is_int(PHP_INT_MAX+1) ? There is a lot of functions accepting an arbitrary
    numeric value and not depending on any library, why they should throw a
    warning by default? Why should we throw a warning about 32 bit in the 64
    bit build? Furtehrmore, LONG_MAX is 64 bit on LP64 systems, that would be
    the same as PHP_INT_MAX.
    The another thing is that this checking needs to be done by other
    libraries wrappers after getting parameters because the most libraries
    using smaller types. That was exactly what I did when I worked on openssl
    ext for 64bit and I will need to do it in my fann and crypto extension.
    There are bunch
    of other extensions that will need to do it too (for example imagick). The
    difference with openssl changes is that the BC will need to be kept. I
    am sure that if warnings were already in zend_parse_arg_impl, then the
    work for supporting 64bit branch would much easier for me and other PECL
    extension maintainers...
    Yes, that's the case - the range checks have to be done locally according
    to what the wrapped library needs. If you haven't done them till now, you
    might have an issue on 64 bit linux anyway. Like say the lib uses int, but
    64 bit long is passed. If that checks are already in place in your ext,
    then it's fine.

    The range checks you've done for openssl are the obligatory part, that's
    what I was doing as well for all the other extensions. Some are still
    pending as on the progress wiki page. And of course this is to mention in
    the porting guide. The libraries are different, for instance iconv uses
    size_t for string length, libxml uses int for string length. zpp cannot
    know, which library an extension uses. On the other hand - an extension
    without any library deps but with some math functions should be kept in
    mind, too.

    Regards

    anatol
  • Jakub Zelenka at Jan 11, 2014 at 6:31 pm

    On Sat, Jan 11, 2014 at 4:53 PM, Anatol Belski wrote:

    Hi Jakub,
    On Sat, January 11, 2014 17:08, Jakub Zelenka wrote:
    On Sat, Jan 11, 2014 at 3:29 PM, Anatol Belski wrote:

    yep, that's exactly how it performs till now in the mainstream, just
    replace ZEND_INT_MAX with LONG_MAX. Adding a warning to every such case
    would cause a warning flood in many PHP apps, guaranteed :) Whereby it
    might be ok for debug mode maybe, I wouldn't do it as I can't remember
    any WTFs about the behavior.

    I meant adding warning only for overflow cases. Values in existing apps
    can't be bigger than LONG_MAX so I don't see how it could cause warning
    flood in the current PHP apps. I don't even think that users will be
    often using such a big values after the 64bit changes.

    The thing is that if I use value bigger than LONG_MAX after 64bit changes
    and I pass it to the function defined in extension that does not support
    it (use "l" in zpp), then I rather see warning than unexpected rounding to
    LONG_MAX... There is no way how to find out (except looking to the ext
    sources) that the big values are not supported. If I get warning, I can
    fix it in the code straight away...
    But isn't it the exact situation now on ILP32 vs LP64 systems? Like 32 vs
    64 bit Linux? I haven't suggested 'l' to handle the param the old way,
    just it to be an alias for 'i'. In the new code that would be as dynamic
    as php_int_t is, however 'l' as alias would retain zpp compatibility to
    the older PHP.

    For instance how much sense had such a centralized warding for the snippet
    is_int(PHP_INT_MAX+1) ? There is a lot of functions accepting an arbitrary
    numeric value and not depending on any library, why they should throw a
    warning by default? Why should we throw a warning about 32 bit in the 64
    bit build? Furtehrmore, LONG_MAX is 64 bit on LP64 systems, that would be
    the same as PHP_INT_MAX.
    This is of course just about LLP64 when the situation has changed. I think
    that we are talking about slightly different things. Sorry my first example
    was a bit incorrect (ZEND_INT_MAX = _I64_MAX which is bigger than LONG_MAX
    on LLP64)

    What I was suggesting is keeping BC for code like this:
    ...
    long n;
    if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "l", &n) == FAILURE) {
    return; }
    ...
      The warning would be thrown if it's bigger than LONG_MAX or smaller than
    LONG_MIN.

    If I understood correctly you are suggesting using php_int_t for n (defined
    in compat header as long if not defined in php.h)? The problem is that the
    type would be dependent on PHP versions and when you need to be sure that
    it's a long (which might be the case when you pass it to the another lib
    function), then you need to check PHP_API_VERSION and in case it's not
    long, you have to do range check.

    In general, I think that would be better to keep BC for "l" and use it just
    for long values (the "l" actually stands for long... :) ). That could be
    achieved adding range checks with warning if the value is bigger than
    LONG_MAX or smaller than LONG_MIN in zend_parse_arg_impl (it would probably
    require small changes in zend_parse_arg [expected_value...]).

    Btw. I see your point about the arbitary number. But I also feel that it
    would be better to keep it as long as it would keep the same behavior when
    passed to external libs.

    Cheers

    Jakub
  • Anatol Belski at Jan 11, 2014 at 7:35 pm
    Hi Jakub,
    On Sat, January 11, 2014 19:31, Jakub Zelenka wrote:
    On Sat, Jan 11, 2014 at 4:53 PM, Anatol Belski wrote:

    Hi Jakub,

    On Sat, January 11, 2014 17:08, Jakub Zelenka wrote:

    On Sat, Jan 11, 2014 at 3:29 PM, Anatol Belski wrote:


    yep, that's exactly how it performs till now in the mainstream,
    just replace ZEND_INT_MAX with LONG_MAX. Adding a warning to every
    such case would cause a warning flood in many PHP apps, guaranteed
    :) Whereby it
    might be ok for debug mode maybe, I wouldn't do it as I can't
    remember any WTFs about the behavior.

    I meant adding warning only for overflow cases. Values in existing
    apps can't be bigger than LONG_MAX so I don't see how it could cause
    warning flood in the current PHP apps. I don't even think that users
    will be often using such a big values after the 64bit changes.

    The thing is that if I use value bigger than LONG_MAX after 64bit
    changes and I pass it to the function defined in extension that does
    not support it (use "l" in zpp), then I rather see warning than
    unexpected rounding to
    LONG_MAX... There is no way how to find out (except looking to the
    ext sources) that the big values are not supported. If I get warning,
    I can
    fix it in the code straight away...
    But isn't it the exact situation now on ILP32 vs LP64 systems? Like 32
    vs 64 bit Linux? I haven't suggested 'l' to handle the param the old
    way, just it to be an alias for 'i'. In the new code that would be as
    dynamic as php_int_t is, however 'l' as alias would retain zpp
    compatibility to the older PHP.

    For instance how much sense had such a centralized warding for the
    snippet is_int(PHP_INT_MAX+1) ? There is a lot of functions accepting an
    arbitrary numeric value and not depending on any library, why they
    should throw a warning by default? Why should we throw a warning about
    32 bit in the 64
    bit build? Furtehrmore, LONG_MAX is 64 bit on LP64 systems, that would
    be the same as PHP_INT_MAX.
    This is of course just about LLP64 when the situation has changed. I
    think that we are talking about slightly different things. Sorry my first
    example was a bit incorrect (ZEND_INT_MAX = _I64_MAX which is bigger than
    LONG_MAX
    on LLP64)
    well, there's no another chance to understand each other than using some
    verbal devices :)
    What I was suggesting is keeping BC for code like this:
    ...
    long n; if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "l", &n) ==
    FAILURE) {
    return; } ...
    The warning would be thrown if it's bigger than LONG_MAX or smaller than
    LONG_MIN.

    If I understood correctly you are suggesting using php_int_t for n
    (defined
    in compat header as long if not defined in php.h)? The problem is that the
    type would be dependent on PHP versions and when you need to be sure
    that it's a long (which might be the case when you pass it to the another
    lib function), then you need to check PHP_API_VERSION and in case it's not
    long, you have to do range check.
    If a library expects long, in the new code that's the issue on 32 bit
    windows only. So yes, probably the way you describe is plausible, check
    PHP_WIN32 and PHP_API_VERSION. Honestly, right at the place where I sit, I
    can't remember any library working with long (well, timeval struct and so
    on, not really libs). There are int, size_t, int64_t, ... so while the
    case you describe is of course possible, it's rather an exception. Usually
    a simple runtime range check will be good enough, if needed at all.
    In general, I think that would be better to keep BC for "l" and use it
    just for long values (the "l" actually stands for long... :) ). That could
    be achieved adding range checks with warning if the value is bigger than
    LONG_MAX or smaller than LONG_MIN in zend_parse_arg_impl (it would
    probably require small changes in zend_parse_arg [expected_value...]).
    Just to remind, your very first reply was to the mail about the zpp
    compatibility, namely so then one wouldn't have to touch zpp calls for
    migration, only the variables. That's why i've suggested to alias the new
    formats with old. If we let 'l' to do the old thing, then zpp will have to
    be touched at many places to be replaced with 'i' with all the
    corresponding consequences. So retaining the functional compatibliity with
    'l', an easier migration way is not possible. Also I'm asking myself, how
    essential it really is, in the light of how many libs will profit from one
    or another way.

    Regards

    anatol
  • Anatol Belski at Jan 11, 2014 at 8:17 pm

    On Sat, January 11, 2014 20:34, Anatol Belski wrote:


    If I understood correctly you are suggesting using php_int_t for n
    (defined
    in compat header as long if not defined in php.h)? The problem is that
    the type would be dependent on PHP versions and when you need to be sure
    that it's a long (which might be the case when you pass it to the
    another lib function), then you need to check PHP_API_VERSION and in
    case it's not long, you have to do range check.
    If a library expects long, in the new code that's the issue on 32 bit
    windows only. So yes, probably the way you describe is plausible, check
    PHP_WIN32 and PHP_API_VERSION.
    Err, it's issue only on windows 64 bit, as php_int_t is __int64 there. So
    the macros needs check _WIN64 only, not PHP_WIN32.

    Regards

    Anatol
  • Jakub Zelenka at Jan 12, 2014 at 9:18 pm
    Hi Anatol,
    On Sat, Jan 11, 2014 at 7:34 PM, Anatol Belski wrote:

    If a library expects long, in the new code that's the issue on 32 bit
    windows only. So yes, probably the way you describe is plausible, check
    PHP_WIN32 and PHP_API_VERSION. Honestly, right at the place where I sit, I
    can't remember any library working with long (well, timeval struct and so
    on, not really libs). There are int, size_t, int64_t, ... so while the
    case you describe is of course possible, it's rather an exception. Usually
    a simple runtime range check will be good enough, if needed at all.
    Actually there is one big library where you can find it. It's OpenSSL which
    is why I was asking about it.. :) There are quite a few places where it's
    used. The main ones are following:

    - ASN.1 API functions (I plan to completely wrap it :) ) where it's used
    for data length.
    - BIO_ctrl for length parameter (BIO_ctrl is a definition result for many
    macros like BIO_set_mem_buf, BIO_set_buffer_size, BIO_set_write_buf_size...)
    - Big numbers - there is a situation a bit more complicated but unsigned
    long is used (there will be necessary some other checks anyway so it's not
    an issue)

    I think that would be good to have a look to the other exts and double
    check if used libs have long parameters for data lengths. If not, then I
    agree with you that there is no point to do casting to long with warnings
    just because of OpenSSL.

    However it would be good to define in compat header a macro for checking
    that long != php_int_t . I know that it's currently only _WIN64 but if you
    implement enabling 64bit on 32bit platform (future scope in the RFC :) ),
    then there will be an extra definition.

    Cheers

    Jakub
  • Jakub Zelenka at Jan 12, 2014 at 11:23 pm

    On Sun, Jan 12, 2014 at 9:18 PM, Jakub Zelenka wrote:

    Hi Anatol,

    Jakub
    On Sat, Jan 11, 2014 at 7:34 PM, Anatol Belski wrote:

    If a library expects long, in the new code that's the issue on 32 bit
    windows only. So yes, probably the way you describe is plausible, check
    PHP_WIN32 and PHP_API_VERSION. Honestly, right at the place where I sit, I
    can't remember any library working with long (well, timeval struct and so
    on, not really libs). There are int, size_t, int64_t, ... so while the
    case you describe is of course possible, it's rather an exception. Usually
    a simple runtime range check will be good enough, if needed at all.
    Actually there is one big library where you can find it. It's OpenSSL
    which is why I was asking about it.. :) There are quite a few places where
    it's used. The main ones are following:

    - ASN.1 API functions (I plan to completely wrap it :) ) where it's used
    for data length.
    - BIO_ctrl for length parameter (BIO_ctrl is a definition result for many
    macros like BIO_set_mem_buf, BIO_set_buffer_size, BIO_set_write_buf_size...)
    - Big numbers - there is a situation a bit more complicated but unsigned
    long is used (there will be necessary some other checks anyway so it's not
    an issue)

    I think that would be good to have a look to the other exts and double
    check if used libs have long parameters for data lengths. If not, then I
    agree with you that there is no point to do casting to long with warnings
    just because of OpenSSL.

    However it would be good to define in compat header a macro for checking
    that long != php_int_t . I know that it's currently only _WIN64 but if you
    implement enabling 64bit on 32bit platform (future scope in the RFC :) ),
    then there will be an extra definition.
    I was thinking a bit more what will be the consequences of asn1 and bio in
    my ext for "l" flag and it won't be such a big issue regarding to zpp.
    There are just few cases in asn1 (ASN1_INTEGER_set for example) and BIO
    stuff will probably require mainly string conversions which is a bit
    different issue...

    What's the actually plan for keeping BC for "s" and "p"? Is it gonna be
    zend_str_size from compat header and "s" and "p" aliases of "S" and "P"?

    Something like...
    ...
    char *s;
    zend_str_size len;
    if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s", &s, &len) ==
    FAILURE) { return; }
    ...

    If so, I think that that would be a slightly bigger issue (size_t vs
    int)...

    There are only two solutions of zpp "s" that I think of:
    1. check range (INT_MAX) and cast it to int (possibly throw warning if it's
    out of range) -> that could result too many warning but it's safe
    2. PHP version variable zend_str_size (see above) -> the same as discussed
    for long but considerably more places where we will need to find out what
    the zend_str_size really is.

    What do you think?

    Cheers

    Jakub
  • Anatol Belski at Jan 13, 2014 at 3:37 am
    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
  • Anatol Belski at Jan 13, 2014 at 8:32 pm
    Hi,

    the usable porting doc is now available

    http://git.php.net/?p=php-src.git;a=blob;f=compat/PECL_PORTING;hb=refs/heads/str_size_and_int64

    The replacement tool and the header are in the same folder.

    Regards

    Anatol
  • Jan Ehrhardt at Jan 11, 2014 at 1:31 am

    Nikita Popov in php.internals (Fri, 10 Jan 2014 22:42:49 +0100):
    Or is the point here to intentionally provide a
    maximum amount of BC breakage, so code doesn't "accidentally" continue to
    run (e.g. I think that without the renames extensions could continue to run
    mostly without issue on 32bit.)
    Some of the PECL extensions compiled without really complaining with the
    new experimental branch (on Windows). Anatol's own xmldiff,
    php_blenc.dll (but it did not work), php_uploadprogress.dll and
    php_timezonedb.dll.

    The BC break should probably be even greater, so that cases like the
    blenc extension do not occur.

    I have converted one of my own extensions (that is not even on PECL):
    php_ffmpeg.dll. I did not do that (yet) with ifndef's, but just with
    global searching and replacing. So I have two sources for the same
    extension right now.

    Jan
  • Dmitry Stogov at Jan 23, 2014 at 8:43 am
    I completely agree with Nikita.
    Why to rename LONG->INT STRLEN->STRSIZE in thousands places?
    Why not just define zend_long and zend_ulong to be 64-bit on 64-bit
    platforms and use them instead of int, ulint, zend_int, zend_uint, long,
    ulong where it's necessary.

    Anatol, I understood your point about catching incompatibility code at
    compile-time, but I'm not sure if the new features cost such huge code base
    changes.

    1) 64-bit integers on Windows (they are already 64-bit on other systems)
    2) 64-bit string length. I don't think many people are interested in that.
    Fortunately, the patch doesn't change the zval size, so it shouldn't make a
    lot of harm. However, usage of "zend_size_t" instead of "int" is a bit
    annoying. I would change it into the same "zend_long" or "zend_ulong".

    Thanks. Dmitry.

    On Sat, Jan 11, 2014 at 1:42 AM, Nikita Popov wrote:
    On Fri, Jan 10, 2014 at 3:58 PM, Anatol Belski wrote:

    Hi,

    https://wiki.php.net/rfc/size_t_and_int64

    The discussion time has come. The work on the feature branch continues.
    The current patch is stable enough to be discussed.
    What is the reason behind the renames of IS_LONG to IS_INT (and Z_LVAL to
    Z_IVAL etc), as well as the renames in zpp (s -> S, etc)? Why can't we keep
    the old names here? That should reduce the amount of ifndefs involved a
    lot, as you'd only have to do it for the type declarations themselves, not
    for every single usage. Or is the point here to intentionally provide a
    maximum amount of BC breakage, so code doesn't "accidentally" continue to
    run (e.g. I think that without the renames extensions could continue to run
    mostly without issue on 32bit.)

    Nikita
  • Pierre Joye at Jan 23, 2014 at 9:13 am

    On Thu, Jan 23, 2014 at 9:42 AM, Dmitry Stogov wrote:
    I completely agree with Nikita.
    Why to rename LONG->INT STRLEN->STRSIZE in thousands places?
    Why not just define zend_long and zend_ulong to be 64-bit on 64-bit
    platforms and use them instead of int, ulint, zend_int, zend_uint, long,
    ulong where it's necessary.

    Anatol, I understood your point about catching incompatibility code at
    compile-time, but I'm not sure if the new features cost such huge code base
    changes.
    To catch 64bit issues at compile is immensely valuable. We had so many
    issues in the past, some of them leading to security issues. It is
    also a one time job, with a little extra effort for two years.
    Besides the portability improvements, code review and correctness is
    one of the goal of this RFC. I can't remember to know any widely known
    and sane project relying on on other type for buffer length. PHP does
    not have to be different :)
    1) 64-bit integers on Windows (they are already 64-bit on other systems)
    Almost all :)
    2) 64-bit string length. I don't think many people are interested in that.
    Fortunately, the patch doesn't change the zval size, so it shouldn't make a
    lot of harm. However, usage of "zend_size_t" instead of "int" is a bit
    annoying. I would change it into the same "zend_long" or "zend_ulong".
    It is not about being interested but preventing many security issues
    as well, by default. The large buffer availability is a good side
    effect. The implementation correctness is also drastically improved in
    this case.

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Pierre Joye at Jan 23, 2014 at 10:34 am
    re,
    On Thu, Jan 23, 2014 at 10:13 AM, Pierre Joye wrote:
    On Thu, Jan 23, 2014 at 9:42 AM, Dmitry Stogov wrote:
    I completely agree with Nikita.
    Why to rename LONG->INT STRLEN->STRSIZE in thousands places?
    Why not just define zend_long and zend_ulong to be 64-bit on 64-bit
    platforms and use them instead of int, ulint, zend_int, zend_uint, long,
    ulong where it's necessary.

    Anatol, I understood your point about catching incompatibility code at
    compile-time, but I'm not sure if the new features cost such huge code base
    changes.
    To catch 64bit issues at compile is immensely valuable. We had so many
    issues in the past, some of them leading to security issues. It is
    also a one time job, with a little extra effort for two years.
    Besides the portability improvements, code review and correctness is
    one of the goal of this RFC. I can't remember to know any widely known
    and sane project relying on on other type for buffer length. PHP does
    not have to be different :)
    1) 64-bit integers on Windows (they are already 64-bit on other systems)
    Almost all :)
    2) 64-bit string length. I don't think many people are interested in that.
    Fortunately, the patch doesn't change the zval size, so it shouldn't make a
    lot of harm. However, usage of "zend_size_t" instead of "int" is a bit
    annoying. I would change it into the same "zend_long" or "zend_ulong".
    It is not about being interested but preventing many security issues
    as well, by default. The large buffer availability is a good side
    effect. The implementation correctness is also drastically improved in
    this case.
    After a short chat with Dmitry, it seems that the only open questions are:

    - renaming
       . pros
          . 100% compile time checks, unvaluable
          . clarity, no magic as we have now
          . code correctness, any 64bit port guides cover things the way we
    implemented it

       . cons
         . renaming will create extra work for the next 2 years
         . annoying (while I can live with it given the benefits in the long run)

    - SAPIs
       We have discussed many times the removal of the dead SAPIs. I think
    it is time to remove them and keep only those maintained and actually
    working (some sapis are not even possible to use anymore)

    I think we can clear these questions during the vote phases, as options.

    If anyone has an idea how to keep the advantage brought by the
    renaming (compile checks, clarity, code correctness) without actually
    doing the renaming in extensions, please fire it :)

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Lester Caine at Jan 23, 2014 at 10:54 am

    Pierre Joye wrote:
    I think we can clear these questions during the vote phases, as options.

    If anyone has an idea how to keep the advantage brought by the
    renaming (compile checks, clarity, code correctness) without actually
    doing the renaming in extensions, please fire it:)
    Is this still being put forward for a PHP5.x build? Surely this along with a
    tidy up on base modules that support it would be much better used as a base for
    a new PHP6 plan? Extensions that do not support it can also be left out and we
    have a clean demarcation.

    One thing I would ask is just what 32bit platforms will remain supported. While
    desktop machines are generally 64bit these days, tablet and mobile devices do
    still tend to be 32bit. The ITX based systems I'm working with are still 32bit
    and while they do tend to run as clients to bigger servers, some support their
    own PHP platform. I already have to support different integer sizes anyway and
    assuming PHP is 32bit simplifies things but I'm a little unsure how a change to
    direct support for 64bit might affect that split?

    --
    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
  • Dmitry Stogov at Jan 23, 2014 at 11:55 am
    Of course, we are not going to drop 32-bit support :)
    This patch affects only PHP on 64-bit systems.

    Thanks. Dmitry.

    On Thu, Jan 23, 2014 at 2:56 PM, Lester Caine wrote:

    Pierre Joye wrote:
    I think we can clear these questions during the vote phases, as options.

    If anyone has an idea how to keep the advantage brought by the
    renaming (compile checks, clarity, code correctness) without actually
    doing the renaming in extensions, please fire it:)
    Is this still being put forward for a PHP5.x build? Surely this along with
    a tidy up on base modules that support it would be much better used as a
    base for a new PHP6 plan? Extensions that do not support it can also be
    left out and we have a clean demarcation.

    One thing I would ask is just what 32bit platforms will remain supported.
    While desktop machines are generally 64bit these days, tablet and mobile
    devices do still tend to be 32bit. The ITX based systems I'm working with
    are still 32bit and while they do tend to run as clients to bigger servers,
    some support their own PHP platform. I already have to support different
    integer sizes anyway and assuming PHP is 32bit simplifies things but I'm a
    little unsure how a change to direct support for 64bit might affect that
    split?

    --
    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


    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Derick Rethans at Jan 23, 2014 at 12:17 pm

    On Thu, 23 Jan 2014, Dmitry Stogov wrote:

    Of course, we are not going to drop 32-bit support :)
    This patch affects only PHP on 64-bit systems.
    Really? I thought it would also make PHP's int type 64-bit even on
    32-bit platforms.

    cheers,
    Derick
  • Dmitry Stogov at Jan 23, 2014 at 1:12 pm
    Hi Derick,

    It would be a significant performance degradation :)
    Just imagine how to implement 64-bit multiplication and division on 32-bit
    CPU.

    Thanks. Dmitry.

    On Thu, Jan 23, 2014 at 4:17 PM, Derick Rethans wrote:
    On Thu, 23 Jan 2014, Dmitry Stogov wrote:

    Of course, we are not going to drop 32-bit support :)
    This patch affects only PHP on 64-bit systems.
    Really? I thought it would also make PHP's int type 64-bit even on
    32-bit platforms.

    cheers,
    Derick
  • Lester Caine at Jan 23, 2014 at 1:47 pm

    Dmitry Stogov wrote:
    Hi Derick,

    It would be a significant performance degradation :)
    Just imagine how to implement 64-bit multiplication and division on 32-bit
    CPU.
    My own query was probably more to do with maintaining 32bit results where there
    is interaction with 32bit only systems. But perhaps the question should rather
    be 'Just what will be returned as 64bit where it currently is maintained as
    32bit?' I was under the impression I got 32bit integers even on 64bit
    installations and had to use another method to return the 64bit values core to
    Firebird's generator system.
    Thanks. Dmitry.

    On Thu, Jan 23, 2014 at 4:17 PM, Derick Rethans wrote:
    On Thu, 23 Jan 2014, Dmitry Stogov wrote:

    Of course, we are not going to drop 32-bit support :)
    This patch affects only PHP on 64-bit systems.
    Really? I thought it would also make PHP's int type 64-bit even on
    32-bit platforms.
    --
    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
  • Andrea Faulds at Jan 23, 2014 at 7:17 pm

    On 23/01/14 13:12, Dmitry Stogov wrote:
    It would be a significant performance degradation :)
    Just imagine how to implement 64-bit multiplication and division on 32-bit
    CPU.
    I doubt as much. Aren't the vast majority of servers 64-bit anyway? And
    those that aren't are probably just 32-bit-mode 64-bit CPU servers,
    which wouldn't be slow, right?

    --
    Andrea Faulds
    http://ajf.me/
  • Pierre Joye at Jan 23, 2014 at 7:23 pm

    On Thu, Jan 23, 2014 at 8:17 PM, Andrea Faulds wrote:
    On 23/01/14 13:12, Dmitry Stogov wrote:

    It would be a significant performance degradation :)
    Just imagine how to implement 64-bit multiplication and division on 32-bit
    CPU.

    I doubt as much. Aren't the vast majority of servers 64-bit anyway? And
    those that aren't are probably just 32-bit-mode 64-bit CPU servers, which
    wouldn't be slow, right?
    RIght, 32bit mode are not slower, at least for basic operations, other
    ops are slower (couple of more cycles, less registers, etc.). However
    64bit mode combined with 64 binaries can be much faster than 32bit
    binary on the same processor.


    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Dmitry Stogov at Jan 24, 2014 at 7:32 am
    Unfortunately, my benchmarks on Linux show that 64-bit PHP builds are
    always a bit slower on real-life applications.
    It's because 64-bit PHP uses more memory and as result causes more CPU
    cache misses.

    Thanks. Dmitry.

    On Thu, Jan 23, 2014 at 11:23 PM, Pierre Joye wrote:
    On Thu, Jan 23, 2014 at 8:17 PM, Andrea Faulds wrote:

    On 23/01/14 13:12, Dmitry Stogov wrote:

    It would be a significant performance degradation :)
    Just imagine how to implement 64-bit multiplication and division on
    32-bit
    CPU.

    I doubt as much. Aren't the vast majority of servers 64-bit anyway? And
    those that aren't are probably just 32-bit-mode 64-bit CPU servers, which
    wouldn't be slow, right?
    RIght, 32bit mode are not slower, at least for basic operations, other
    ops are slower (couple of more cycles, less registers, etc.). However
    64bit mode combined with 64 binaries can be much faster than 32bit
    binary on the same processor.


    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Anatol Belski at Jan 24, 2014 at 8:36 am
    Hi Dmitry,
    On Fri, January 24, 2014 08:32, Dmitry Stogov wrote:
    Unfortunately, my benchmarks on Linux show that 64-bit PHP builds are
    always a bit slower on real-life applications. It's because 64-bit PHP uses
    more memory and as result causes more CPU cache misses.
    i suppose the perf test on windows to be done today.

    That topic was also it my mind while worked on str_size_and_int64 branch.
    What I have seen is that till now PHP code doesn't really care about 64
    bit performance. I was reading the "Software Optimization Guide for AMD64
    Processors" http://support.amd.com/TechDocs/25112.PDF and comparing with
    their recomendations one can find many places in PHP code needing some
    refactoring. Some primitive points to name like use of non contiguous
    values in switches, 32 bit vars in loops, no homogeneous 64 bit vars
    usage, etc. - could be improved. One of good moves is usage of the const
    qualifier lately. Now with the consistent 64 bit support such a
    refactoring would have base and sense.

    Regards

    Anatol
  • Dmitry Stogov at Jan 24, 2014 at 11:29 am
    I would be glad t see any 64-bit performance related improvements.

    BTW: the performance degradation is expected. Each pointer is 64-bit
    instead of 32-bit => more memory consumption => more CPU cache pressure =>
    more CPU cache misses.

    On the other hand x86-64 uses more CPU registers, MMX, SSE, passes
    arguments in registers, so it's usually faster on small tasks that keep
    working set in CPU caches.

    Thanks. Dmitry.

    On Fri, Jan 24, 2014 at 12:36 PM, Anatol Belski wrote:

    Hi Dmitry,
    On Fri, January 24, 2014 08:32, Dmitry Stogov wrote:
    Unfortunately, my benchmarks on Linux show that 64-bit PHP builds are
    always a bit slower on real-life applications. It's because 64-bit PHP uses
    more memory and as result causes more CPU cache misses.
    i suppose the perf test on windows to be done today.

    That topic was also it my mind while worked on str_size_and_int64 branch.
    What I have seen is that till now PHP code doesn't really care about 64
    bit performance. I was reading the "Software Optimization Guide for AMD64
    Processors" http://support.amd.com/TechDocs/25112.PDF and comparing with
    their recomendations one can find many places in PHP code needing some
    refactoring. Some primitive points to name like use of non contiguous
    values in switches, 32 bit vars in loops, no homogeneous 64 bit vars
    usage, etc. - could be improved. One of good moves is usage of the const
    qualifier lately. Now with the consistent 64 bit support such a
    refactoring would have base and sense.

    Regards

    Anatol
  • Anatol Belski at Jan 25, 2014 at 10:47 am
    Hi Dmitry,
    On Fri, January 24, 2014 12:29, Dmitry Stogov wrote:
    I would be glad t see any 64-bit performance related improvements.

    BTW: the performance degradation is expected. Each pointer is 64-bit
    instead of 32-bit => more memory consumption => more CPU cache pressure =>
    more CPU cache misses.

    On the other hand x86-64 uses more CPU registers, MMX, SSE, passes
    arguments in registers, so it's usually faster on small tasks that keep
    working set in CPU caches.
    Wouldn't then the small parts improve the whole? Fixing the small cases
    laying on the surface like implicit 32 vs 64 bit type conversions, better
    struct packing and similar measures would already contribute to more
    efficient processor and memory usage. That would probably turn many things
    even more upside down though :) As yep, potentially 64 bit should be
    faster, so it's worth a try to lean PHP towards.

    Especially as you welcome it, I would put the topic on my todo after
    properly finishing this RFC. Besides potential improvement that's also an
    exciting matter.

    Regards

    Anatol
  • Lester Caine at Jan 25, 2014 at 12:30 pm

    Anatol Belski wrote:
    On Fri, January 24, 2014 12:29, Dmitry Stogov wrote:
    I would be glad t see any 64-bit performance related improvements.

    BTW: the performance degradation is expected. Each pointer is 64-bit
    instead of 32-bit => more memory consumption => more CPU cache pressure =>
    more CPU cache misses.

    On the other hand x86-64 uses more CPU registers, MMX, SSE, passes
    arguments in registers, so it's usually faster on small tasks that keep
    working set in CPU caches.
    Wouldn't then the small parts improve the whole? Fixing the small cases
    laying on the surface like implicit 32 vs 64 bit type conversions, better
    struct packing and similar measures would already contribute to more
    efficient processor and memory usage. That would probably turn many things
    even more upside down though:) As yep, potentially 64 bit should be
    faster, so it's worth a try to lean PHP towards.

    Especially as you welcome it, I would put the topic on my todo after
    properly finishing this RFC. Besides potential improvement that's also an
    exciting matter.
    Much of the 'improved performance' provided by later versions of windows is down
    to faster processors to hide the extra bloat created. They have adopted having a
    32bit version and a 64bit version. Making PHP super efficient on 64bit
    processors would be useful, but it still misses the point of being able to fall
    back gracefully to run on 32bit machines? Or is now the time to introduce the
    same differentiation in all builds of PHP? It is built for the platform?

    The main problem here is that changing things to be more 64bit efficient could
    then make things even worse on 32bit? Yes we need to be modernising, but telling
    users to 'read the source code' to find out where functions are now returning 64
    bit values rather than 32bit ones is not the right approach?

    --
    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
  • Anatol Belski at Jan 25, 2014 at 2:54 pm
    Hi Lester,
    On Sat, January 25, 2014 13:32, Lester Caine wrote:
    Anatol Belski wrote:
    On Fri, January 24, 2014 12:29, Dmitry Stogov wrote:

    I would be glad t see any 64-bit performance related improvements.


    BTW: the performance degradation is expected. Each pointer is
    64-bit
    instead of 32-bit => more memory consumption => more CPU cache
    pressure => more CPU cache misses.

    On the other hand x86-64 uses more CPU registers, MMX, SSE, passes
    arguments in registers, so it's usually faster on small tasks that
    keep working set in CPU caches.
    Wouldn't then the small parts improve the whole? Fixing the small cases
    laying on the surface like implicit 32 vs 64 bit type conversions,
    better struct packing and similar measures would already contribute to
    more efficient processor and memory usage. That would probably turn many
    things even more upside down though:) As yep, potentially 64 bit should
    be faster, so it's worth a try to lean PHP towards.

    Especially as you welcome it, I would put the topic on my todo after
    properly finishing this RFC. Besides potential improvement that's also
    an exciting matter.
    Much of the 'improved performance' provided by later versions of windows
    is down to faster processors to hide the extra bloat created. They have
    adopted having a 32bit version and a 64bit version. Making PHP super
    efficient on 64bit processors would be useful, but it still misses the
    point of being able to fall back gracefully to run on 32bit machines? Or
    is now the time to introduce the same differentiation in all builds of
    PHP? It is built for the platform?


    The main problem here is that changing things to be more 64bit efficient
    could then make things even worse on 32bit? Yes we need to be modernising,
    but telling users to 'read the source code' to find out where functions
    are now returning 64 bit values rather than 32bit ones is not the right
    approach?
    this RFC has no plans to discriminate 32-bit platforms, but merely to
    improve the 64-bit ones. 32-bit platforms are nowadays mature, consistent
    and well supported, whereas 64-bit platforms have much more non exhausted
    potential and still luck on proper software ports at many places.

    Regards

    Anatol
  • Anatol Belski at Jan 26, 2014 at 10:54 am
    Hi Dmitry,
    On Fri, January 24, 2014 09:36, Anatol Belski wrote:
    Hi Dmitry,

    On Fri, January 24, 2014 08:32, Dmitry Stogov wrote:

    Unfortunately, my benchmarks on Linux show that 64-bit PHP builds are
    always a bit slower on real-life applications. It's because 64-bit PHP
    uses more memory and as result causes more CPU cache misses.
    i suppose the perf test on windows to be done today.
    here's the perf test result I got from Steve. All the numbers are test
    scores, the meaning is the same as one could already have seen in the
    other perf tests of this art
    http://windows.php.net/downloads/snaps/ostc/pftt/perf/ . Below are also
    the Steve's notes about what he's seen during tesing.

    Regards, Anatol

    ============= FORWARDED =============

    PHP Version Wordpress Drupal
    Joomla

    str_size_and_int64-x86 NoCache: 68 NoCache: 70
    NoCache: 53
                                    Cache: 284 Cache: 393
    Cache: 127

    php-5.5.8-nts-Win32-VC11-x86 NoCache: 67 NoCache: 69
    NoCache: 53
                                    Cache: 280 Cache: 390
    Cache: 125

    str_size_and_int64-x64 NoCache: 58 NoCache: 64
    NoCache: 50
                                    Cache: 313* Cache: 348*
    Cache: 100*

    php-5.5.8-nts-Win32-VC11-x64 NoCache: 59 NoCache: 65
    NoCache: 51
                                    Cache: 270* Cache: **
    Cache: **

    • The x86 build of the str_size_and_int64 is consistent with the x86 build
    of 5.5.8.
    • The x64 build of the str_size_and_int64 branch was a bit slower than the
    x86 build of any version, as expected.
    • * I had some issues with the x64 versions of 5.5.8 and
    str_size_and_int64 when testing with opcache enabled. Typically the
    scripts will test each application three times with 16/32/64 virtual
    clients. For the str_size_and_int64 build I could get 1 or 2 out of the
    three runs to produce good results, and then the other runs would just
    return 500 errors.
    • The opcache results I could get from the x64 build of str_size_and_int64
    were pretty good, and I even saw better perf with Wordpress for some
    reason.
    • The 5.5.8 x64 build was even worse. With the opcache scenario, I was
    not able to get decent results for Drupal and Joomla after several
    attempts.

    The results look promising and overall very consistent with standard PHP.
    However, it’s clear we need to resolve these issues with Opcache and the
    x64 builds on Windows before 5.6.0-final. Otherwise x64 builds on Windows
    will be a non-starter for production use.

    ============= END FORWARDED =============
  • Anatol Belski at Jan 26, 2014 at 12:52 pm

    On Sun, January 26, 2014 11:54, Anatol Belski wrote:
    Hi Dmitry,

    On Fri, January 24, 2014 09:36, Anatol Belski wrote:

    Hi Dmitry,



    On Fri, January 24, 2014 08:32, Dmitry Stogov wrote:

    Unfortunately, my benchmarks on Linux show that 64-bit PHP builds are
    always a bit slower on real-life applications. It's because 64-bit
    PHP
    uses more memory and as result causes more CPU cache misses.
    i suppose the perf test on windows to be done today.
    here's the perf test result I got from Steve. All the numbers are test
    scores, the meaning is the same as one could already have seen in the
    other perf tests of this art
    http://windows.php.net/downloads/snaps/ostc/pftt/perf/ . Below are also
    the Steve's notes about what he's seen during tesing.

    Regards, Anatol


    ============= FORWARDED =============


    PHP Version Wordpress DrupalJoomla


    str_size_and_int64-x86 NoCache: 68 NoCache: 70
    NoCache: 53
    Cache: 284 Cache: 393
    Cache: 127


    php-5.5.8-nts-Win32-VC11-x86 NoCache: 67 NoCache: 69
    NoCache: 53
    Cache: 280 Cache: 390
    Cache: 125


    str_size_and_int64-x64 NoCache: 58 NoCache: 64
    NoCache: 50
    Cache: 313* Cache: 348*
    Cache: 100*


    php-5.5.8-nts-Win32-VC11-x64 NoCache: 59 NoCache: 65
    NoCache: 51
    Cache: 270* Cache: **
    Cache: **


    • The x86 build of the str_size_and_int64 is consistent with the x86
    build of 5.5.8. • The x64 build of the str_size_and_int64 branch was a bit
    slower than the x86 build of any version, as expected. • * I had some
    issues with the x64 versions of 5.5.8 and str_size_and_int64 when testing
    with opcache enabled. Typically the scripts will test each application
    three times with 16/32/64 virtual clients. For the str_size_and_int64
    build I could get 1 or 2 out of the three runs to produce good results,
    and then the other runs would just return 500 errors. • The opcache results
    I could get from the x64 build of str_size_and_int64
    were pretty good, and I even saw better perf with Wordpress for some
    reason. • The 5.5.8 x64 build was even worse. With the opcache scenario,
    I was
    not able to get decent results for Drupal and Joomla after several
    attempts.

    The results look promising and overall very consistent with standard PHP.
    However, it’s clear we need to resolve these issues with Opcache and the
    x64 builds on Windows before 5.6.0-final. Otherwise x64 builds on
    Windows
    will be a non-starter for production use.

    ============= END FORWARDED =============
    Now with hopefully better looking table.

    PHP Version Wordpress Drupal Joomla

    str_size_and_int64-x86 NoCache: 68 NoCache: 70 NoCache: 53
                                    Cache: 284 Cache: 393 Cache: 127

    php-5.5.8-nts-Win32-VC11-x86 NoCache: 67 NoCache: 69 NoCache: 53
                                    Cache: 280 Cache: 390 Cache: 125

    str_size_and_int64-x64 NoCache: 58 NoCache: 64 NoCache: 50
                                    Cache: 313* Cache: 348* Cache: 100*

    php-5.5.8-nts-Win32-VC11-x64 NoCache: 59 NoCache: 65 NoCache: 51
                                    Cache: 270* Cache: ** Cache: **

    Cheers, Anatol
  • Pierre Joye at Jan 26, 2014 at 7:01 pm
    On Sun, Jan 26, 2014 at 11:54 AM, Anatol Belski wrote:

    Some clarifications:
    • The x86 build of the str_size_and_int64 is consistent with the x86 build
    of 5.5.8.
    Meaning, no delta between patched and standard branch.
    • The x64 build of the str_size_and_int64 branch was a bit slower than the
    x86 build of any version, as expected.
    here we refer to the patched version.
    • * I had some issues with the x64 versions of 5.5.8 and
    In this case we refer to the standard branch build using the x64 mode
    of the compiler, no patch applied.
    str_size_and_int64 when testing with opcache enabled. Typically the
    scripts will test each application three times with 16/32/64 virtual
    clients. For the str_size_and_int64 build I could get 1 or 2 out of the
    three runs to produce good results, and then the other runs would just
    return 500 errors.
    That's the known issue we have with opcache on 64bit using 64bit
    binaries. It is due to the memory management. The int64/size_t patch
    is not causing this bug.

    • The 5.5.8 x64 build was even worse. With the opcache scenario, I was
    not able to get decent results for Drupal and Joomla after several
    attempts.
    Again, we have to keep in mind that the x64 is not the int64/size_t.

    cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Dmitry Stogov at Jan 27, 2014 at 6:01 am
    Hi Pierre,

    On Sun, Jan 26, 2014 at 11:01 PM, Pierre Joye wrote:

    On Sun, Jan 26, 2014 at 11:54 AM, Anatol Belski wrote:

    Some clarifications:
    • The x86 build of the str_size_and_int64 is consistent with the x86 build
    of 5.5.8.
    Meaning, no delta between patched and standard branch.
    • The x64 build of the str_size_and_int64 branch was a bit slower than the
    x86 build of any version, as expected.
    here we refer to the patched version.
    • * I had some issues with the x64 versions of 5.5.8 and
    In this case we refer to the standard branch build using the x64 mode
    of the compiler, no patch applied.
    str_size_and_int64 when testing with opcache enabled. Typically the
    scripts will test each application three times with 16/32/64 virtual
    clients. For the str_size_and_int64 build I could get 1 or 2 out of the
    three runs to produce good results, and then the other runs would just
    return 500 errors.
    That's the known issue we have with opcache on 64bit using 64bit
    binaries. It is due to the memory management. The int64/size_t patch
    is not causing this bug.
    If you know how to fix it, please provide a patch.

    Thanks. Dmitry.

    • The 5.5.8 x64 build was even worse. With the opcache scenario, I was
    not able to get decent results for Drupal and Joomla after several
    attempts.
    Again, we have to keep in mind that the x64 is not the int64/size_t.

    cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Pierre Joye at Jan 27, 2014 at 6:59 am
    Hi Dmitry,
    On Mon, Jan 27, 2014 at 7:01 AM, Dmitry Stogov wrote:

    If you know how to fix it, please provide a patch.
    We will happily provide one, but the last attempt was rejected
    (removed the fixed addresses). Ideally we should port the MM from
    wincache, as it covers all these issues pretty well.

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Dmitry Stogov at Jan 27, 2014 at 7:31 am
    Fixed addresses were proposed as workaround by someone from Microsoft and
    they worked fine for 32-bit builds.
    I'm not sure if removing them would help for 64-bit in general. It may work
    on some systems/builds and not on the others.
    It just can't be guaranteed to work with that windows API.

    In case wincache uses some different approach to create shared memory, and
    it may guarantee multiple processes to map shared segment into the same
    address space, we should use it.

    Thanks. Dmitry.

    On Mon, Jan 27, 2014 at 10:59 AM, Pierre Joye wrote:

    Hi Dmitry,
    On Mon, Jan 27, 2014 at 7:01 AM, Dmitry Stogov wrote:

    If you know how to fix it, please provide a patch.
    We will happily provide one, but the last attempt was rejected
    (removed the fixed addresses). Ideally we should port the MM from
    wincache, as it covers all these issues pretty well.

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Pierre Joye at Jan 27, 2014 at 8:21 am

    On Mon, Jan 27, 2014 at 8:31 AM, Dmitry Stogov wrote:
    Fixed addresses were proposed as workaround by someone from Microsoft and
    they worked fine for 32-bit builds.
    I'm not sure if removing them would help for 64-bit in general. It may work
    on some systems/builds and not on the others.
    It just can't be guaranteed to work with that windows API.

    In case wincache uses some different approach to create shared memory, and
    it may guarantee multiple processes to map shared segment into the same
    address space, we should use it.
    I proposed it before 5.5.0, with a cleaner patch than the initial one.

    I will go with the wincache port, it is well tested and works on all
    architectures.

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Pierre Joye at Jan 24, 2014 at 9:34 am

    On Fri, Jan 24, 2014 at 8:32 AM, Dmitry Stogov wrote:
    Unfortunately, my benchmarks on Linux show that 64-bit PHP builds are always
    a bit slower on real-life applications.
    It's because 64-bit PHP uses more memory and as result causes more CPU cache
    misses.
    That's something we can solve, it does not sound like a stopper to me.
    It is also about time to focus on 64bit much more widely, while
    keeping support for x32.



    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Dmitry Stogov at Jan 24, 2014 at 11:36 am
    it's not a stopper. It's just a fact and it's not related to this patch at
    all. Any performance related improvements are always welcome :)

    X32 is not the same as x86. It is a new ABI (not widely used yet) , it's
    actually executes 64-bit instructions but uses 32-bit pointers.
    For tasks that don't really need huge amount of memory, it takes advantages
    from both (x86 and x86-64) ABIs and as result such applications compiled
    for X32 may run ~10% faster.

    Thanks. Dmitry.

    On Fri, Jan 24, 2014 at 1:34 PM, Pierre Joye wrote:
    On Fri, Jan 24, 2014 at 8:32 AM, Dmitry Stogov wrote:
    Unfortunately, my benchmarks on Linux show that 64-bit PHP builds are always
    a bit slower on real-life applications.
    It's because 64-bit PHP uses more memory and as result causes more CPU cache
    misses.
    That's something we can solve, it does not sound like a stopper to me.
    It is also about time to focus on 64bit much more widely, while
    keeping support for x32.



    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Lester Caine at Jan 23, 2014 at 7:40 pm

    Andrea Faulds wrote:
    It would be a significant performance degradation :)
    Just imagine how to implement 64-bit multiplication and division on 32-bit
    CPU.
    I doubt as much. Aren't the vast majority of servers 64-bit anyway? And those
    that aren't are probably just 32-bit-mode 64-bit CPU servers, which wouldn't be
    slow, right?
    Except that PHP is not just used on servers?
    I doubt figures are available, but it would be interesting to find out how big
    the minority is who use PHP to run local applications on local hardware? That
    hardware may well be 32bit still ...

    --
    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
  • Nikita Popov at Jan 23, 2014 at 2:29 pm

    On Thu, Jan 23, 2014 at 11:56 AM, Lester Caine wrote:

    Pierre Joye wrote:
    I think we can clear these questions during the vote phases, as options.

    If anyone has an idea how to keep the advantage brought by the
    renaming (compile checks, clarity, code correctness) without actually
    doing the renaming in extensions, please fire it:)
    Is this still being put forward for a PHP5.x build? Surely this along with
    a tidy up on base modules that support it would be much better used as a
    base for a new PHP6 plan? Extensions that do not support it can also be
    left out and we have a clean demarcation.
    I agree with Lester (for once ^^). I think this change is too large for PHP
    5.6. While the releaseprocess RFC does not guarantee compatibility of our
    internal APIs, it does say that source compatibility *should* be preserved
    for minor versions. Until now we stuck with that rule: Every minor release
    a few APIs are changed, but "few" usually means something like three or
    four, not five hundred.

    If this patch is included in PHP 5.6 I think it is very likely that many
    extensions will not be updated or take a long while in updating. It's one
    thing to add two or three new ifdefs to support a new PHP release and
    something entirely else to change virtually all types in your code and
    verify that it is still safe with the new sizes.

    I remember how lack of proper APC support was seen as a major problem with
    adoption of PHP 5.4 - now imagine how lack of support by nearly all
    extensions would look like...

    As such I think that PHP 6 is a better place for this patch. PHP 6 will
    presumably also clean up / change many other internal APIs, so we can have
    all the major internal (and external ^^) breakage in one release. At that
    point it might also make sense for many people to support separate versions
    of extensions for PHP 5 and 6 to avoid the ifdef-hell.

    Nikita
  • Nikita Popov at Jan 23, 2014 at 3:48 pm

    On Thu, Jan 23, 2014 at 4:14 PM, Martin Keckeis wrote:

    If this patch is included in PHP 5.6 I think it is very likely that many
    extensions will not be updated or take a long while in updating. It's one
    thing to add two or three new ifdefs to support a new PHP release and
    something entirely else to change virtually all types in your code and
    verify that it is still safe with the new sizes.

    I remember how lack of proper APC support was seen as a major problem with
    adoption of PHP 5.4 - now imagine how lack of support by nearly all
    extensions would look like...
    If i look on the progress list, the most common used extensions are
    already ported?
    https://wiki.php.net/rfc/string-size_t/progress
    Those are bundled extensions. All core extensions will be updated before
    this lands (at least I'd assume so, would make little sense otherwise). I'm
    talking about third-party extensions here, e.g. those on PECL or elsewhere.
    Updating bundled extensions is simple because you only need to support the
    new APIs, whereas third-party extensions need to support multiple PHP
    versions - if the API changes so drastically that is complicated.

    Nikita

Related Discussions