[PHP-DEV] PHP 5.4.32 Released
Hello! The PHP development team announces the immediate availability of PHP 5.4.32. 16 bugs were fixed in this release, including the following security-related issues: CVE-2014-2497, CVE-2014-3538, CVE-2014-3587, CVE-2014-3597, CVE-2014-4670, CVE-2014-4698, CVE-2014-5120. All PHP 5.4 users are encouraged to upgrade to this version. For source downloads of PHP 5.4.32 please visit our downloads page: http://www.php.net/downloads.php Windows binaries can be found on http://windows.php.net/download/ The list of changes are recorded in the ChangeLog: http://www.php.net/ChangeLog-5.php#5.4.32 Stanislav Malyshev PHP 5.4 RM -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 64-bit integers and 64-bit string length patch is ready to be merged
zend_long/zend_ulong without renaming everything else would be a perfect solution from my point of view. Thanks. Dmitry. On Fri, Aug 22, 2014 at 12:49 AM, Nikita Popov nikita@gmail.com wrote: On Thu, Aug 21, 2014 at 7:23 PM, Dmitry Stogov dmi...@zend.com wrote: Hi, Thanks to Anatol and Pierre the 64-bit patch is ready https://github.com/weltling/php-src I made quick code review and don't see any technical problems now. The performance and memory consumption difference is negligible. see https://docs.google.com/spreadsheets/d/1PD4oiiXz6B0JbeZYnUSat5fHoq3_jAiCeI2cGHJ3UtQ/edit#gid=0 The patch breaks one test on 32-bit Linux: ext/date/tests/bug53437_var3.phpt (seems to be a bogus test and wrong behavior in php5.6 and below) and one test on 64-bit Linux: ext/standard/tests/array/array_pad_variation2.phpt (has to be analyzed) The only thing that I don't like is a massive renaming described here https://wiki.php.net/rfc/size_t_and_int64_next#semantical_macro_renamings IS_LONG - IS_INT Z_LVAL - L_IVAL etc On one hand using INT may be more consistent, on the other hand it's going to break habits and make addition headache for merging from php-5 (I know, phpng already made problems) I'm not sure how to proceed. If I'm alone, lets go ahead with new names. If some others prefer old names we will probably need voting. Despite of renaming, I would like to see this patch in master ASAP. Thanks. Dmitry. I am against merging this with the long-int rename everywhere. This seems like change for the sake of change. I am also concerned that we now have zend_uint_t (a 64-bit integer type) and zend_uint (a 32-bit integer type). Notice the difference? Yes, it's the missing _t. I would appreciate it if we could consider the following naming convention: * zend_(u)int - 32 bit integer type * zend_(u)long - 64 bit integer type (on 64 bit systems) This retains the original meaning of the type, with the tweak that zend_(u)long will be 64bit on LLP64 systems as well. This avoids the confusion of having two types that only differ by a _t suffix and have totally different meanings. It also removes any need to rename everything from LONG to INT. Thanks, Nikita
Re: [PHP-DEV] 64-bit integers and 64-bit string length patch is ready to be merged
On Fri, Aug 22, 2014 at 8:45 AM, Dmitry Stogov dmi...@zend.com wrote: zend_long/zend_ulong without renaming everything else would be a perfect solution from my point of view. Again, no. long is the worst type ever, be as type or in names (ppl then use this type to match the macro names). If there is a need for clearer names, we can deal with that later. Maybe Andrea will do it with her bigint patch. But using names that do not actually represent what they actually use is a no go. By the way, we have the same issue for the zend_string macros, just damned confusing and the amount of fixes about their usage confirm that. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 64-bit integers and 64-bit string length patch is ready to be merged
On 21/08/2014 19:42, Andrea Faulds wrote: * IS_LONG/long - 32-bit or 64-bit integer (machine-dependant) * IS_BIGINT/bigint - arbitrary-size integer * IS_BIGINT_OR_LONG/integer - either a long or a bigint (pseudo-type) Replacing IS_LONG with IS_INT kinda ruins my naming scheme. The intention is that “integer” and “int” are synonyms for “long or bigint”. However, if internally an int is one thing and to userland it’s another, that would be problematic. If this goes through, I’d probably make my bigints patch rename IS_INT to something new again, probably IS_SMALLINT or even back to IS_LONG. wouldn't the following work for you? * IS_INT * IS_BIGINT * IS_INT_OR_BIGINT After all, SQL has INT(EGER) and BIGINT, albeit with different meanings. In fact bigint itself to me and possibly many other developers means a 64bit int, not a GMP int. Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.5.16 is available
Hello! The PHP development team announces the immediate availability of PHP 5.5.16. This fixes some bugs against 5.5.15 and addresses five CVEs. All PHP 5.5 users are encouraged to upgrade to this version. For source downloads of PHP 5.5.16 please visit our downloads page: http://www.php.net/downloads.php Windows binaries can be found on http://windows.php.net/download/ The full list of changes is recorded in the ChangeLog: http://www.php.net/ChangeLog-5.php#5.5.16 Julien Pauli David Soria Para
Re: [PHP-DEV] 64-bit integers and 64-bit string length patch is ready to be merged
On 21/08/14 19:10, Andrea Faulds wrote: I would instead to ask you to try to migrate a not so trivial extension :) No, seriously. Why can’t a sed script be used to change a constant name? Can you tell me why that wouldn’t work? Compatibility across all builds? Many of the times 'blanket' changes are applied the edge cases simply get missed because nobody actually checked each change? :( I'm still missing where BIGINT fit into this and that is the only area where we need 64bit numbers that work transparently on a 32bit build? Fixing one without also covering the other just seems wrong especially if it then needs further changes in the same area? -- 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
Re: [PHP-DEV] 64-bit integers and 64-bit string length patch is ready to be merged
Moin, On Thu, August 21, 2014 19:23, Dmitry Stogov wrote: Hi, Thanks to Anatol and Pierre the 64-bit patch is ready https://github.com/weltling/php-src I made quick code review and don't see any technical problems now. The performance and memory consumption difference is negligible. see https://docs.google.com/spreadsheets/d/1PD4oiiXz6B0JbeZYnUSat5fHoq3_jAiCeI 2cGHJ3UtQ/edit#gid=0 The patch breaks one test on 32-bit Linux: ext/date/tests/bug53437_var3.phpt (seems to be a bogus test and wrong behavior in php5.6 and below) and one test on 64-bit Linux: ext/standard/tests/array/array_pad_variation2.phpt (has to be analyzed) The only thing that I don't like is a massive renaming described here https://wiki.php.net/rfc/size_t_and_int64_next#semantical_macro_renamings IS_LONG - IS_INT Z_LVAL - L_IVAL etc On one hand using INT may be more consistent, on the other hand it's going to break habits and make addition headache for merging from php-5 (I know, phpng already made problems) I'm not sure how to proceed. If I'm alone, lets go ahead with new names. If some others prefer old names we will probably need voting. Despite of renaming, I would like to see this patch in master ASAP. Thanks. Dmitry. the patch is merged by now as is. I greatefuly thank all the supporters, especially Nikita for the idea on how to join phpng and str-size_and_int64 with minimal loss and Dmitry for the closer look. I think it's feasible solving the naming issues with Andrea's or some separate RFC. Regards anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Merges between PHP5 and PHP7
Hi, as there are many data type changes, here's an idea on how to simplify the merges. Git supports custom merge drivers which attracted my attention, so I've ended up with the following trick: === Add to .git/config === [merge 7] name = Compatibility merge between PHP5 and PHP7 driver = ./replace.sh %A %O %B === Add to .git/info/attributes === *.c merge=7 *.h merge=7 *.re merge=7 *.l mrege=7 *.y merge=7 === Create replace.sh == #/bin/bash CURRENT=$1 ANCESTOR=$2 OTHER=$3 # http://git.php.net/?p=php-src.git;a=blob;f=compat/replace.php;hb=refs/heads/str_size_and_int64 php /path/to/replace.php --macros $ANCESTOR exec git merge-file $CURRENT $ANCESTOR $OTHER The basic idea behind this - do some automatic processing on the fale which is getting in before merge. Say when merging from PHP5 to PHP7, one could automatically replace macro names or whatever, we can extend it. For now I've just added the macro script. This can solve simple cases yet, for example if something like this comes in: if(type == IS_LONG) it'll overwrite it to if(type == IS_INT) before merge start, so the automatic merge will go smoothly. In the case for example like char *hello = estrdup(hello); to zend_string * or long one = Z_LVAL(z_one); to php_int_t one = Z_IVAL(z_one); the automatic replacement is not that easy to do, so this would fail (even the macro names were the same, long vs php_int_t or other placeholder name would fail). But at least we had a mechanism getting rid of the simple cases, no matter how the naming issues was solved. Just as side effect, the git attributes will apply to all the branches, so that should be activated only when merging 5 to 7. I think a tip from someone more experienced in git might help to solve this or improve this mechanism. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)
On 21/08/14 19:17, Stas Malyshev wrote: We have millions of people using PHP 5, and the goal is for almost all of them to eventually use PHP 7, otherwise there's no point in it. Each BC break creates another hurdle on the way to it. We should take it seriously. Currently we have millions still using 5.2 because the changes to 5.3/4 require work. 'strict' while something one can switch off HAS to be reworked for in order to move that code forward and remove the problems caused by third party hosting changes that may well be out of a users control. Many of the changes being put forward will probably not affect older code, as it's not been using these 'improvements' anyway, but it would be nice if as part of the PHP7 process there was a mechanism which could scan the code and at least tag what areas need attention rather than the current mechanism of having to keep one eye on the error logs for changes that have been missed. I think Derick is picking up subtle changes almost to style which are difficult to detect but will result in changes in outcome, and those sorts of changes need the most support to identify if they go forward? It looks like I've lost PHPEclipse as a mechanism that could provide this level of checking as it seems to have lost support, and I still don't find PDT as capable in this sort of area :( -- 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
Re: [PHP-DEV] New Memory Manager for PHP7
Hi, I'm going to commit this on next week, if nobody cares. MM is a self containing subsystem, and it must not affect anything else. Thanks. Dmitry. On Mon, Aug 18, 2014 at 10:07 PM, Levi Morrison le...@php.net wrote: On Mon, Aug 18, 2014 at 12:04 PM, Nikita Popov nikita@gmail.com wrote: On Mon, Aug 18, 2014 at 7:59 PM, Levi Morrison le...@php.net wrote: On Mon, Aug 18, 2014 at 6:04 AM, Dmitry Stogov dmi...@zend.com wrote: Hi, Please take a look into the proposed new Memory Manager for PHP: https://github.com/php/php-src/pull/777 It looks like the gains are mostly earned by passing size information; is that correct? Nope, this is an entirely new allocator implementation. GitHub doesn't show it in the diff because there are too many changes. See the file https://github.com/dstogov/php-src/blob/xx_malloc/Zend/zend_alloc.c Ah, I knew it couldn't be that simple. Thanks for pointing out my oversight.
[PHP-DEV] [RFC] Better type names for int64 RFC
Hi internals! Today the int64 RFC has been merged, despite objections regarding the naming changes it introduces. As we were not given a chance to resolve this issue before the merge, a short proposal has been created, which aims to revert all unnecessary naming changes and instead use type names that are consistent with the existing code base and expectations: https://wiki.php.net/rfc/better_type_names_for_int64 Due to the unexpected merge on short notice, with no chance for discussion, this issue is blocking a number of other patches. As such I ask if we can move through this RFC with a shortened cycle. I would not appreciate having to wait three weeks to have a workable codebase again. Nikita
Re: [PHP-DEV] [RFC] Better type names for int64 RFC
On Fri, 2014-08-22 at 13:16 +0200, Nikita Popov wrote: Hi internals! Today the int64 RFC has been merged, despite objections regarding the naming changes it introduces. As we were not given a chance to resolve this issue before the merge, a short proposal has been created, which aims to revert all unnecessary naming changes and instead use type names that are consistent with the existing code base and expectations: https://wiki.php.net/rfc/better_type_names_for_int64 Due to the unexpected merge on short notice, with no chance for discussion, this issue is blocking a number of other patches. As such I ask if we can move through this RFC with a shortened cycle. I would not appreciate having to wait three weeks to have a workable codebase again. Nikita Morning internals, I'd very much like the same as Nikita; that's expected names, and quickly. Already it is going to be extremely difficult to maintain extensions for PHP7 and PHP7, we don't need it to get harder, it is not enough to say that we have to work something out. Fix it, fix it, fix it !! Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Better type names for int64 RFC
Am 22.8.2014 um 13:16 schrieb Nikita Popov nikita@gmail.com: Hi internals! Today the int64 RFC has been merged, despite objections regarding the naming changes it introduces. As we were not given a chance to resolve this issue before the merge, a short proposal has been created, which aims to revert all unnecessary naming changes and instead use type names that are consistent with the existing code base and expectations: https://wiki.php.net/rfc/better_type_names_for_int64 Due to the unexpected merge on short notice, with no chance for discussion, this issue is blocking a number of other patches. As such I ask if we can move through this RFC with a shortened cycle. I would not appreciate having to wait three weeks to have a workable codebase again. Nikita Yes, please. We're all in favor of the 64 bit implementation, but definitely not on the naming. I think it was a big mistake to not separate the naming and implementation votes initially. I also would support a shorter RFC cycle, due to its blocking nature. [Vote in 2-3 days, vote lasting one week as usual] Bob
Re: [PHP-DEV] [RFC] Integer Semantics
On Wed, 20 Aug 2014, Andrea Faulds wrote: On 20 Aug 2014, at 03:53, Laruence larue...@php.net wrote: On Wed, Aug 20, 2014 at 6:36 AM, Andrea Faulds a...@ajf.me wrote: Good evening, I have made an RFC which would make some small changes to how integers are handled, targeted at PHP 7: https://wiki.php.net/rfc/integer_semantics I'd like don't change the works behavior. make it act the similar as C does. For some of these things the behaviour is explicitly undefined in C, meaning it’s dangerous for us not to handle them specially, as undefined behaviour seems to give compilers an unlimited license to do absolutely anything at all. Although I think it is good to make it work the same on every platform, I do think that changing it to *match* what the most used compiler (GCC) on our most used platform (Linux/AMD64) is what the new behaviour should be like — not something that looks best. I think that's what Laruence was trying to say as well. It causes the least amount of BC breaks for our users. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Merges between PHP5 and PHP7
On Fri, 22 Aug 2014, Anatol Belski wrote: as there are many data type changes, here's an idea on how to simplify the merges. Git supports custom merge drivers which attracted my attention, so I've ended up with the following trick: As there are that many differences, does it still make sense to GIT merge PHP 5 changes up to 7 at all? Shouldn't we just do it by hand. I would expect that to have a much greater rate of success. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 security only
On Wed, Aug 20, 2014 at 10:45 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Apparently the fix for #67724 [2] caused #67865 [1], but I already have a fix for the fix (oh my) [3]. I've reverted it from 5.4.32, but please commit this fix in 5.4. As phar is currently broken, fix for this qualifies as important. Same for 5.5. Reverted from 5.5.16 but should be commited to 5.5 branch for 5.5.17 :-) Julien.P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Better type names for int64 RFC
On Fri, 22 Aug 2014, Nikita Popov wrote: Hi internals! Today the int64 RFC has been merged, despite objections regarding the naming changes it introduces. As we were not given a chance to resolve this issue before the merge, a short proposal has been created, which aims to revert all unnecessary naming changes and instead use type names that are consistent with the existing code base and expectations: https://wiki.php.net/rfc/better_type_names_for_int64 Due to the unexpected merge on short notice, with no chance for discussion, this issue is blocking a number of other patches. As such I ask if we can move through this RFC with a shortened cycle. I would not appreciate having to wait three weeks to have a workable codebase again. Yes please. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Better type names for int64 RFC
Hi Nikita, On Fri, August 22, 2014 13:16, Nikita Popov wrote: Hi internals! Today the int64 RFC has been merged, despite objections regarding the naming changes it introduces. As we were not given a chance to resolve this issue before the merge, a short proposal has been created, which aims to revert all unnecessary naming changes and instead use type names that are consistent with the existing code base and expectations: https://wiki.php.net/rfc/better_type_names_for_int64 Due to the unexpected merge on short notice, with no chance for discussion, this issue is blocking a number of other patches. As such I ask if we can move through this RFC with a shortened cycle. I would not appreciate having to wait three weeks to have a workable codebase again. Nikita to be complete, the RFC probably should take in account several new identifiers which came in (zend_off_t, zend_stat_t and co.). As their naming scheme is probably somewhat different. I've just documented those http://git.php.net/?p=php-src.git;a=blob;f=UPGRADING.INTERNALS and continue. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] com php-src: fixes to date: ext/date/lib/timelib.c ext/date/lib/timelib.h ext/date/php_date.c ext/date/php_date.h
On Fri, Aug 22, 2014 at 2:01 PM, Derick Rethans der...@php.net wrote: On Mon, 18 Aug 2014, Anatol Belski wrote: Commit:e49e163a9ed7d4e38f9ab724003c46c9f1ea2cb4 Author:Anatol Belski a...@php.net Mon, 18 Aug 2014 18:57:55 +0200 Parents: b8324e6d635450562ecb253af38f22105e19e460 Branches: master Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=e49e163a9ed7d4e38f9ab724003c46c9f1ea2cb4 Log: fixes to date Changed paths: M ext/date/lib/timelib.c M ext/date/lib/timelib.h You can't just change timelib and introduce PHP specific constructs. It should be compilable outside of PHP as well. Then the right type must be used accordingly to the current architecture. long is just meaningless and should be avoided. While I understand that this part of the core, always enabled and widely used extension could be used outside PHP, it should be clean and uses portable types. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Better type names for int64 RFC
On Fri, Aug 22, 2014 at 1:16 PM, Nikita Popov nikita@gmail.com wrote: Hi internals! Today the int64 RFC has been merged, despite objections regarding the naming changes it introduces. As we were not given a chance to resolve this issue before the merge, a short proposal has been created, which aims to revert all unnecessary naming changes and instead use type names that are consistent with the existing code base and expectations: https://wiki.php.net/rfc/better_type_names_for_int64 Due to the unexpected merge on short notice, with no chance for discussion, this issue is blocking a number of other patches. As such I ask if we can move through this RFC with a shortened cycle. I would not appreciate having to wait three weeks to have a workable codebase again. I also request to let me add options for actual good naming (see my previous reply). I would also strongly suggest to group these renaming actions in one RFC and get rid of it in the next couple of weeks (following the usual periods for a RFC). STR macros being on top of my list. And I'd to remember that we suffer from double standards while you guys do whatever you want with ng, and certainly with ast as well. I wonder what you would say if we begin to be as picky and keep asking to change things for months :/ Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Better type names for int64 RFC
On Fri, Aug 22, 2014 at 1:16 PM, Nikita Popov nikita@gmail.com wrote: Hi internals! Today the int64 RFC has been merged, despite objections regarding the naming changes it introduces. As we were not given a chance to resolve this issue before the merge, a short proposal has been created, which aims to revert all unnecessary naming changes and instead use type names that are consistent with the existing code base and expectations: https://wiki.php.net/rfc/better_type_names_for_int64 Due to the unexpected merge on short notice, with no chance for discussion, this issue is blocking a number of other patches. As such I ask if we can move through this RFC with a shortened cycle. I would not appreciate having to wait three weeks to have a workable codebase again. I am against what you propose while being open to have better naming. Keeping what we have in 5.x is a huge mistake and will cause many issues, just like what NG does by using the same APIs or macros names but with different argument types. One example is the STR macro, a major pain. And the names of a macro should match what they actually do and the actually types they deal with, not some random totally misleading names. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Better type names for int64 RFC
On Fri, Aug 22, 2014 at 1:28 PM, Bob Weinand bobw...@hotmail.com wrote: Yes, please. We're all in favor of the 64 bit implementation, but definitely not on the naming. I think it was a big mistake to not separate the naming and implementation votes initially. I also would support a shorter RFC cycle, due to its blocking nature. [Vote in 2-3 days, vote lasting one week as usual] No. -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] com php-src: fixes to date: ext/date/lib/timelib.c ext/date/lib/timelib.h ext/date/php_date.c ext/date/php_date.h
On Fri, August 22, 2014 14:15, Pierre Joye wrote: On Fri, Aug 22, 2014 at 2:01 PM, Derick Rethans der...@php.net wrote: On Mon, 18 Aug 2014, Anatol Belski wrote: Commit:e49e163a9ed7d4e38f9ab724003c46c9f1ea2cb4 Author:Anatol Belski a...@php.net Mon, 18 Aug 2014 18:57:55 +0200 Parents: b8324e6d635450562ecb253af38f22105e19e460 Branches: master Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=e49e163a9ed7d4e38f9a b724003c46c9f1ea2cb4 Log: fixes to date Changed paths: M ext/date/lib/timelib.c M ext/date/lib/timelib.h You can't just change timelib and introduce PHP specific constructs. It should be compilable outside of PHP as well. Then the right type must be used accordingly to the current architecture. long is just meaningless and should be avoided. While I understand that this part of the core, always enabled and widely used extension could be used outside PHP, it should be clean and uses portable types. I see, so I could suggest to introduce similar portable datatype inside of the timelib. Or, what i see there - the defs for timelib_ull and timelib_ll, with a little tweak they would be usable too. What would suffice? Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Better type names for int64 RFC
Pierre Joye in php.internals (Fri, 22 Aug 2014 14:17:04 +0200): And I'd to remember that we suffer from double standards while you guys do whatever you want with ng, and certainly with ast as well. Just a side note: talking in you guys and we is not constructive. I had the idea you had come a lot closer while working on the 64bit patch. Do not spoil that. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] com php-src: fixes to date: ext/date/lib/timelib.c ext/date/lib/timelib.h ext/date/php_date.c ext/date/php_date.h
On Fri, August 22, 2014 14:54, Derick Rethans wrote: On Fri, 22 Aug 2014, Anatol Belski wrote: On Fri, August 22, 2014 14:01, Derick Rethans wrote: On Mon, 18 Aug 2014, Anatol Belski wrote: Commit:e49e163a9ed7d4e38f9ab724003c46c9f1ea2cb4 Author:Anatol Belski a...@php.net Mon, 18 Aug 2014 18:57:55 +0200 Parents: b8324e6d635450562ecb253af38f22105e19e460 Branches: master Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=e49e163a9ed7d4e38f9 ab7 24003c46c9f1ea2cb4 Log: fixes to date Changed paths: M ext/date/lib/timelib.c M ext/date/lib/timelib.h You can't just change timelib and introduce PHP specific constructs. It should be compilable outside of PHP as well. I see, so I could suggest to introduce similar portable datatype inside of the timelib. Or, what i see there - the defs for timelib_ull and timelib_ll, with a little tweak they would be usable too. What would suffice? Yeah, those datatypes should already be there. What needs fixing to make it work? I think now that it's unavoidable to create an arch dependent portable type as timelib_sll is always 64 bit. Please take a look https://gist.github.com/weltling/e2c295a1c2efed62890e . The only difference here would be that it would always return timelib_sll even on 32 bit build (however within 32 bit range). If not that, it'd be probably ok. But IMHO not clean. Probably it would be better to pull the #ifdef's into the timelib.h header to define things like TIMELIB_SLL_MAX and so on, and also to define a portable type, then several places in timelib could be moved to portable types. I you don't mind, i'd rather go this way. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 64-bit integers and 64-bit string length patch is ready to be merged
On 22 Aug 2014, at 08:10, Matteo Beccati p...@beccati.com wrote: On 21/08/2014 19:42, Andrea Faulds wrote: * IS_LONG/long - 32-bit or 64-bit integer (machine-dependant) * IS_BIGINT/bigint - arbitrary-size integer * IS_BIGINT_OR_LONG/integer - either a long or a bigint (pseudo-type) Replacing IS_LONG with IS_INT kinda ruins my naming scheme. The intention is that “integer” and “int” are synonyms for “long or bigint”. However, if internally an int is one thing and to userland it’s another, that would be problematic. If this goes through, I’d probably make my bigints patch rename IS_INT to something new again, probably IS_SMALLINT or even back to IS_LONG. wouldn't the following work for you? * IS_INT * IS_BIGINT * IS_INT_OR_BIGINT After all, SQL has INT(EGER) and BIGINT, albeit with different meanings. In fact bigint itself to me and possibly many other developers means a 64bit int, not a GMP int. It’s doable, it’s just confusing. From userland, “int” can be either IS_INT or IS_BIGINT. I’d rather it was IS_LONG or something. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Better type names for int64 RFC
On 8/22/14, 5:11 AM, Pierre Joye wrote: On Fri, Aug 22, 2014 at 1:28 PM, Bob Weinand bobw...@hotmail.com wrote: Yes, please. We're all in favor of the 64 bit implementation, but definitely not on the naming. I think it was a big mistake to not separate the naming and implementation votes initially. I also would support a shorter RFC cycle, due to its blocking nature. [Vote in 2-3 days, vote lasting one week as usual] No. Since this is obviously contentious it should follow the normal RFC cycle. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] com php-src: fixes to date: ext/date/lib/timelib.c ext/date/lib/timelib.h ext/date/php_date.c ext/date/php_date.h
On Fri, 22 Aug 2014, Anatol Belski wrote: On Fri, August 22, 2014 14:54, Derick Rethans wrote: Yeah, those datatypes should already be there. What needs fixing to make it work? I think now that it's unavoidable to create an arch dependent portable type as timelib_sll is always 64 bit. Please take a look https://gist.github.com/weltling/e2c295a1c2efed62890e . The only difference here would be that it would always return timelib_sll even on 32 bit build (however within 32 bit range). If not that, it'd be probably ok. But IMHO not clean. Probably it would be better to pull the #ifdef's into the timelib.h header to define things like TIMELIB_SLL_MAX and so on, and also to define a portable type, then several places in timelib could be moved to portable types. I you don't mind, i'd rather go this way. Right, but timelib_ssl is supposed to be that portable 64bit int type. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Better type names for int64 RFC
On 22 Aug 2014, at 12:16, Nikita Popov nikita@gmail.com wrote: As we were not given a chance to resolve this issue before the merge, a short proposal has been created, which aims to revert all unnecessary naming changes and instead use type names that are consistent with the existing code base and expectations: https://wiki.php.net/rfc/better_type_names_for_int64 Due to the unexpected merge on short notice, with no chance for discussion, this issue is blocking a number of other patches. As such I ask if we can move through this RFC with a shortened cycle. I would not appreciate having to wait three weeks to have a workable codebase again. I’m very much in favour of this RFC. It is not necessary to change the type names after all; if people turn on compiler warnings, they’ll find out what’s broken anyway. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Better type names for int64 RFC
Andrea Faulds in php.internals (Fri, 22 Aug 2014 16:32:51 +0100): Im very much in favour of this RFC. It is not necessary to change the type names after all; if people turn on compiler warnings, theyll find out whats broken anyway. 'people'? Which people? Will a normal user ever notice anything of the change from long to int? Isn't this something that only developers of extensions will notice? My guess is that this chnage is only a minor point when converting extensions to ng. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] com php-src: fixes to date: ext/date/lib/timelib.c ext/date/lib/timelib.h ext/date/php_date.c ext/date/php_date.h
On Fri, August 22, 2014 17:17, Derick Rethans wrote: On Fri, 22 Aug 2014, Anatol Belski wrote: On Fri, August 22, 2014 14:54, Derick Rethans wrote: Yeah, those datatypes should already be there. What needs fixing to make it work? I think now that it's unavoidable to create an arch dependent portable type as timelib_sll is always 64 bit. Please take a look https://gist.github.com/weltling/e2c295a1c2efed62890e . The only difference here would be that it would always return timelib_sll even on 32 bit build (however within 32 bit range). If not that, it'd be probably ok. But IMHO not clean. Probably it would be better to pull the #ifdef's into the timelib.h header to define things like TIMELIB_SLL_MAX and so on, and also to define a portable type, then several places in timelib could be moved to portable types. I you don't mind, i'd rather go this way. Right, but timelib_ssl is supposed to be that portable 64bit int type. Exactly, it's 64 bit, that's why the patch in the gist would cause compiler warning when timelib_date_to_int() used in 32 bit PHP. But we need a type which would go with PHP types bitness, probably timelib_int or alike. Or how would you see the solution, always 64 bit? Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 security only
On 22/08/14 13:56, Julien Pauli wrote: On Wed, Aug 20, 2014 at 10:45 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Apparently the fix for #67724 [2] caused #67865 [1], but I already have a fix for the fix (oh my) [3]. I've reverted it from 5.4.32, but please commit this fix in 5.4. As phar is currently broken, fix for this qualifies as important. Same for 5.5. Reverted from 5.5.16 but should be commited to 5.5 branch for 5.5.17 :-) Thank you for taking care! It's already been committed to 5.4, 5.5, 5.6 and master. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New Memory Manager for PHP7
On Fri, Aug 22, 2014 at 4:04 AM, Dmitry Stogov dmi...@zend.com wrote: Hi, I'm going to commit this on next week, if nobody cares. MM is a self containing subsystem, and it must not affect anything else. Thanks. Dmitry. I compared this to master on a small PHP array vs SplFixedArray performance test I had lying around. It's a fairly small difference, but the new memory manager does seem to be consistently faster. No complaints from me. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Better type names for int64 RFC
2014.08.22. 17:56 ezt írta (Jan Ehrhardt php...@ehrhardt.nl): Andrea Faulds in php.internals (Fri, 22 Aug 2014 16:32:51 +0100): I’m very much in favour of this RFC. It is not necessary to change the type names after all; if people turn on compiler warnings, they’ll find out what’s broken anyway. 'people'? Which people? Will a normal user ever notice anything of the change from long to int? Isn't this something that only developers of extensions will notice? My guess is that this chnage is only a minor point when converting extensions to ng. People means ext devs here. The concern raised here that if we delay the namechange then early adopters(ext developers adding support for php7) have to update their code twice. I don't think this will major pita (compared to the phpng changes or other upcoming stuff) but would have been nice resolving this before the merge
Re: [PHP-DEV] [RFC] Better type names for int64 RFC
Ferenc Kovacs in php.internals (Fri, 22 Aug 2014 18:59:01 +0200): People means ext devs here. OK. The concern raised here that if we delay the namechange then early adopters(ext developers adding support for php7) have to update their code twice. Provided the name change (back!) is agreed upon. Now that is has been changed once, there is a chance to look at it with an open mind and decide what is best for the coming years. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Better type names for int64 RFC
On Aug 22, 2014 5:33 PM, Andrea Faulds a...@ajf.me wrote: On 22 Aug 2014, at 12:16, Nikita Popov nikita@gmail.com wrote: As we were not given a chance to resolve this issue before the merge, a short proposal has been created, which aims to revert all unnecessary naming changes and instead use type names that are consistent with the existing code base and expectations: https://wiki.php.net/rfc/better_type_names_for_int64 Due to the unexpected merge on short notice, with no chance for discussion, this issue is blocking a number of other patches. As such I ask if we can move through this RFC with a shortened cycle. I would not appreciate having to wait three weeks to have a workable codebase again. I’m very much in favour of this RFC. It is not necessary to change the type names after all; if people turn on compiler warnings, they’ll find out what’s broken anyway. That's one of my points. They won't for all cases. And why good names reflecting the underlying type will help. It is what the 1st version if the int64 rfc did.
Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
On 18/08/2014 18:41, Nikita Popov wrote: I've opened the vote on the Abstract Syntax Tree RFC: https://wiki.php.net/rfc/abstract_syntax_tree#vote After speaking with other members of AFUP (French UG) about this RFC, we pretty much all agree that a cleaner compilation process is a nice improvement. It should help us getting some syntax options that were impossible before, and there is not too much impact for developers and their existing applications. So, basically: +1 -- Pascal MARTIN http://blog.pascal-martin.fr/ @pascal_martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: 5.6.0 final is near
On Sun, Aug 17, 2014 at 11:25 AM, Ferenc Kovacs tyr...@gmail.com wrote: Hi, I'm planning to release 5.6.0 from RC4 if nothing serious comes up, so this is just a heads-up: if you think that there is some fix, which should make into the 5.6.0 final (which isn't in RC4) or if you think that there is some blocker issue which should be solved before the 5.6.0 final release, please drop me an email just to be sure. Thanks! -- Ferenc Kovács @Tyr43l - http://tyrael.hu Hi, it seems that we have a blocker: https://bugs.php.net/bug.php?id=67694 ps: thanks to Florian for pinging me about it, I missed this one :( -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] Better type names for int64 RFC
On 8/22/14, 11:38 AM, Pierre Joye wrote: On Aug 22, 2014 5:33 PM, Andrea Faulds a...@ajf.me wrote: On 22 Aug 2014, at 12:16, Nikita Popov nikita@gmail.com wrote: As we were not given a chance to resolve this issue before the merge, a short proposal has been created, which aims to revert all unnecessary naming changes and instead use type names that are consistent with the existing code base and expectations: https://wiki.php.net/rfc/better_type_names_for_int64 Due to the unexpected merge on short notice, with no chance for discussion, this issue is blocking a number of other patches. As such I ask if we can move through this RFC with a shortened cycle. I would not appreciate having to wait three weeks to have a workable codebase again. I’m very much in favour of this RFC. It is not necessary to change the type names after all; if people turn on compiler warnings, they’ll find out what’s broken anyway. That's one of my points. They won't for all cases. And why good names reflecting the underlying type will help. It is what the 1st version if the int64 rfc did. The end result here is likely that in order to write a portable extension, extension authors will simply do: #ifndef IS_LONG # define IS_LONG IS_INT # define Z_STRLEN Z_STRSIZE # define RETURN_LONG RETURN_INT # define RETVAL_LONG RETVAL_INT # define Z_LVAL Z_IVAL ... #endif and not change a single macro anywhere in the actual code. That's certainly what I would do. And if the current naming survives we should provide a macro_compat.h file with the complete set. Overall I don't think trying to make the macro names match the underlying types exactly is worth the hassle here. Our audience for this is extension authors. In most cases the author doesn't necessarily care about the subtle differences between calling it IS_LONG and IS_INT and I don't think it actually makes it any more clear to a C developer. int is not a well-defined cross-platform type anymore than a long is. So we are swapping one set of vague names for another set of vague names. I'd much rather see a nice clear README.TYPES or perhaps it is simply part of the existing README.PARAMETER_PARSING_API which defines exactly what these various macros mean. -Rasmus signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Better type names for int64 RFC
On 23 Aug 2014, at 03:05, Rasmus Lerdorf ras...@lerdorf.com wrote: The end result here is likely that in order to write a portable extension, extension authors will simply do: #ifndef IS_LONG # define IS_LONG IS_INT # define Z_STRLEN Z_STRSIZE # define RETURN_LONG RETURN_INT # define RETVAL_LONG RETVAL_INT # define Z_LVAL Z_IVAL ... #endif and not change a single macro anywhere in the actual code. That’s a very good point. It’s easy to forget that many people write cross-version compatible extensions. That's certainly what I would do. And if the current naming survives we should provide a macro_compat.h file with the complete set. Perhaps we could backport the new types, too, and make them just aliases on older PHP versions? For example, zend_int would be a long in 5.5 and 5.6, but a 64-bit-on-64-bit type on 7. Overall I don't think trying to make the macro names match the underlying types exactly is worth the hassle here. Our audience for this is extension authors. In most cases the author doesn't necessarily care about the subtle differences between calling it IS_LONG and IS_INT and I don't think it actually makes it any more clear to a C developer. int is not a well-defined cross-platform type anymore than a long is. So we are swapping one set of vague names for another set of vague names. I'd much rather see a nice clear README.TYPES or perhaps it is simply part of the existing README.PARAMETER_PARSING_API which defines exactly what these various macros mean. +1 to that. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP namespace?
Hi Rowan, On Mon, Aug 18, 2014 at 12:28 AM, Rowan Collins rowan.coll...@gmail.com wrote: On 15/08/2014 01:46, Yasuo Ohgaki wrote: On Wed, Jul 30, 2014 at 9:35 PM, Rowan Collins rowan.coll...@gmail.com mailto:rowan.coll...@gmail.com wrote: Making small changes, such as extra function aliases, or identical versions of existing functions with switched parameter order, just adds to the overall confusion and list of special cases that users have to carry around when reading and writing code. We make small changes in versions always. API changes are small changes also. The difference is BC. Since API change breaks APP, it wasn't changed for a long time. Use of alias was proposed several times, but it wasn't optimum and couldn't reach to consensus. When we talk about compatibility of an API, we are normally talking about how an existing piece of code connects to another program, library, or service. But when you're talking about the core functions of a language, the consumer of that API is the programmer themselves, when writing new code and reading old. One of the problems which we would like to fix is that pogrammers have to stop and think Does array_map take the array first, or the callback? Because there isn't a good rule of thumb, each function has to be remembered or looked up individually. I have previously been tempted by the thought of adding a new set of functions with a clearer design, but on reflection, I realise that you just end up making the problem worse: now the programmer has to ask themselves extra questions, like Does PHP\Array\map take the arguments in the same order as array_map? Which am I supposed to be using in this project? Add in namespace aliasing, or a magic ini setting that hides the old functions and puts the new ones in their place, and reading code becomes equally confusing: When it says array_map here, is that the classic PHP function, or a new version aliased in? What differences are there between the two? I'm not intended to divide global name space into parts. Current(most updated API) namespace and legacy(older API) namespace would be enough. Namespace may have version. (5, 7, and so on) Therefore, user would not confuse like you describe. For example, when a library major version incremented, API may differ. Users may use new or old API selectively. I would like to have a choice to use cleaner API or older API like library API. If we divide namespace into pieces and change API frequently (i.e with minor or bugfix version up), then it's confusing for sure. I'll against such usage. With namespace, user may choose. We don't force users to *new* or *old* way. Individual users can't choose, because they will be contributing to projects - be they open source or commercial - with coding standards based on the platforms supported, the size of the existing code base, and the prejudices of project leaders. And the current trend in open source projects is towards more co-operation and standardisation (e.g. PHP-FIG), so adding a new thing to disagree on would be unfortunate to say the least. Libraries/Projects may choose appropriate namespace (e.g. 5, 7, and so on) like choosing specific library version mostly. Issue would be if new PHP allows to import namespace into \ (root). Older PHP would complain if default namespace is specified in scripts. php use PHP\5 as \; Parse error: syntax error, unexpected '\' (T_NS_SEPARATOR), expecting identifier (T_STRING) in php shell code on line 1 and PHP does not have C like macro. I have to come up with solution for this. If we care about confusion, we may change API only with major release to minimize it. I can't imagine an API change of that sort being even considered outside of a major release. Unless we rewrite everything completely, it wouldn't be accomplished. This has been said for years (more than a decade AFAIK) and didn't happen. Therefore, new API is not feasible by history. So what is it you suggest instead? A series of namespaces with slightly different versions of all the functions, introduced over time, and every file having to declare at the top use PHP7;, use PHP8; etc? Yes. Something like this. Since 'PHP' is reserved namespace name, PHP\5, PHP\7, PHP\8 perhaps. Use of namespace guarantees new PHP has consistent/modern API. This will neutralize/negate all cons, IMO. I'm really not sure what problems adding one or more namspaces solves. If you just arrange the existing functions into namespaces with better naming conventions, then it's just the same as any other set of aliases; it's clear which are the old names and which the new, but that's about the only benefit. If you make the functions superficially similar, but with minor changes like argument order or error-handling, then the cost of adoption is even higher. I like alias also and have proposed use of aliases before. It may be good idea to use
Re: [PHP-DEV] [RFC] Better type names for int64 RFC
hi Rasmus,
On Sat, Aug 23, 2014 at 4:05 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 8/22/14, 11:38 AM, Pierre Joye wrote:
On Aug 22, 2014 5:33 PM, Andrea Faulds a...@ajf.me wrote:
On 22 Aug 2014, at 12:16, Nikita Popov nikita@gmail.com wrote:
As we were not given a chance to resolve this issue before the merge, a
short proposal has been created, which aims to revert all unnecessary
naming changes and instead use type names that are consistent with the
existing code base and expectations:
https://wiki.php.net/rfc/better_type_names_for_int64
Due to the unexpected merge on short notice, with no chance for
discussion,
this issue is blocking a number of other patches. As such I ask if we
can
move through this RFC with a shortened cycle. I would not appreciate
having
to wait three weeks to have a workable codebase again.
I’m very much in favour of this RFC. It is not necessary to change the
type names after all; if people turn on compiler warnings, they’ll find out
what’s broken anyway.
That's one of my points. They won't for all cases. And why good names
reflecting the underlying type will help. It is what the 1st version if the
int64 rfc did.
The end result here is likely that in order to write a portable
extension, extension authors will simply do:
#ifndef IS_LONG
# define IS_LONG IS_INT
# define Z_STRLEN Z_STRSIZE
# define RETURN_LONG RETURN_INT
# define RETVAL_LONG RETVAL_INT
# define Z_LVAL Z_IVAL
...
#endif
and not change a single macro anywhere in the actual code.
If the int64 RFC was accepted for 5.x, this solution would be perfect
(except from a confusing usage and type point of view). But you would
also need #ifdef for the declarations when used with zpp, or storing
values in variables, for the zval integer and strings values:
/* for zval string */
#if PHP_MAJOR_VERSION 6
size_t str_size;
char *str;
#else
int str_size;
char *str;
#endif
Same for zpp argument_
#if PHP_MAJOR_VERSION 6
zend_string path;
#else
int str_size;
char *path;
int path_len;
#endif
Besides that many changes can't be aliased, same APIs or macros use
different arguments or argument content, f.e. the hash api:
f.e.:
- warning at build time:
ex 1:
- php_basename(path_cleaned, path_cleaned_len, NULL, 0,
file_basename, (size_t *)file_basename_len TSRMLS_CC);
+ file_basename = php_basename(path_cleaned, path_cleaned_len, NULL,
0 TSRMLS_CC);
ex 2:
- add_next_index_string(return_value, fullpath, 1);
+ add_next_index_string(return_value, fullpath);
- or even more dangerous if forgotten (no compile time detection (size
and return value):
ex 1 (hash functions):
- if (zend_hash_find(HASH_OF(options), add_path, sizeof(add_path),
(void **)option) == SUCCESS) {
+ if ((option = zend_hash_str_find(HASH_OF(options), add_path,
sizeof(add_path) - 1)) != NULL) {
- zend_hash_add(prop_handler, name, strlen(name)+1, hnd,
sizeof(zip_prop_handler), NULL);
+ zend_hash_str_add_mem(prop_handler, name, strlen(name), hnd,
sizeof(zip_prop_handler));
ex 2:
use of string will need different free calls:
- efree(file_basename);
+ STR_RELEASE(file_basename);
That's certainly what I would do. And if the current naming survives we
should provide a macro_compat.h file with the complete set.
The more exts I work on the less I think our current flow for git will
work out of the box. I am slowly considering creating separate
branches for 7 and 5.x, with different packages for the releases
(avoiding to have to upload/download two code bases when only one is
used). But this is almost another topic, I will post a mail about it
and see how Pickle could help here.
Overall I don't think trying to make the macro names match the
underlying types exactly is worth the hassle here. Our audience for this
is extension authors. In most cases the author doesn't necessarily care
about the subtle differences between calling it IS_LONG and IS_INT and I
don't think it actually makes it any more clear to a C developer. int
is not a well-defined cross-platform type anymore than a long is.
Well, in the context of of the integer case, zend_uint vs zend_int_t,
it is. Or it is for the case used in the engine. Nikita and I had a
long discussions last night. We came to two conclusions:
- zend_uint should go away.
- uint32_t should be used instead
- zend_int_t could remain
. it matches the respective, architecture specific int32_t and
int64_t being used behind it. _t standing for _typed just like in the
standard types intXX_t
- We did not reach an agreement about IS_LONG.
My point: If we keep it, it increases the porting bugs. As we already
have seen in many extensions, is confusing and devs forgot to check
the type. IS_INT matches PHP's integer, which is architecture
dependent, devs may be more careful.
Nikita's point is about not changing it for changing it along what is
described in the RFC (@Nikita, please complete :)
Pretty much the same applies to the Z_STRLEN vs T_STRSIZE. Here I came
back to
