On Fri, May 2, 2014 at 6:48 PM, Bob Weinand wrote:
Am 2.5.2014 um 18:28 schrieb Ferenc Kovacs <firstname.lastname@example.org
On Fri, May 2, 2014 at 6:11 PM, Ferenc Kovacs wrote:
On Fri, May 2, 2014 at 5:52 PM, Hannes Magnusson wrote:
On Fri, May 2, 2014 at 6:17 AM, Jan Ehrhardt wrote:
Ferenc Kovacs in php.qa (Fri, 2 May 2014 12:42:55 +0200):
ext\apcu\apc_bin.c(238) : error C2065: 'IS_CONSTANT_ARRAY' :
Afair this was mentioned in UPGRADING.INTERNALS, if I remember wrong
open a bugreport.
Might be that it is mentioned there (did not check yet), but to an
innocent bystander it looks like a BC break between beta1 and beta2.
l. Removal of IS_CONSTANT_ARRAY and IS_CONSTANT_INDEX hack
These two #defines disappeared. Instead we have now IS_CONSTANT_AST
covers also the functionality IS_CONSTANT_ARRAY bid and furthermore the
hack for marking zvals as constant index with IS_CONSTANT_INDEX is now
superfluous and so removed.
Please note that IS_CONSTANT_AST now has the same value than
Could someone be.. like just a tiny littlebit more professional then
to shit over other people work in the upgrading notes?
This is not the place for to show off how much better you are then
And why does it have to be renamed anyway? It has the same value. Does
the same thing. It just got renamed to piss over people?
PHP Quality Assurance Mailing List <http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
moving the discussion to internals@, CCing Bob, as he is the author of
To my understanding this change was made to fixhttps://bugs.php.net/bug.php?id=66015
I was aware that it is a BC break, but I didn't realized that it will
affect other extensions before the first report from the wincache dev
Not sure if removing this #defines is really neccessary to fix the bug
@Tyr43l - http://tyrael.hu
from a quick search search on lxr.php.net the following extensions are
using IS_CONSTANT_ARRAY or IS_CONSTANT_INDEX
and probably a couple of other exts which isn't on lxr.
whats even more interesting is that ext/opcache still referencing both of
those, so it isn't even cleaned up from php-src.
what is the current workflow for opcache these days? I know that they have
their own repo, and they are merging from there to php-src.git and that
they are also maintain compatibility with lower versions for installing
opcache via pecl, so maybe it is normal to have those references?
personally I think that compatibility with already existing extensions is
pretty important, because that is a major reason which holds back people
from upgrading to new php versions early.
so internal API breaks like that should happen early in the development
process, have a clear communication and should be always for a good reason.
@Tyr43l - http://tyrael.hu
At the time when doing this change, I had fixed all the bundled extensions.
So, e.g. opcache shouldn't be a problem.