Hi!
a little correction: 5.5.18 is expected next week (not in two weeks) and as
5.4 is in security fix mode, 5.4.34 will only happen when we have security
fixes to release.
Yes, time has passed since we started to discuss it :) 5.4/5.5 (and now
5.6) is expected on October 16th (tags go out on
Hi!
* opcache
For opcache I guess that'd be Dmitry probably.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
As such I'm re-proposing this RFC for inclusion in PHP 7:
https://wiki.php.net/rfc/engine_exceptions_for_php7
The RFC text is essentially the same as previously, with the primary
difference being that parse errors are now converted to exceptions as well.
This was previously not
Hi!
Easy to implement, too. What are the list’s thoughts? I don’t think it really
hampers readability much.
It's pretty faint praise - doesn't hamper much. I think language
feature should do better than not hurting too much. We don't need to
change things and fragment the language just
Hi!
Case in point: The current zend_language_scanner.c has been generated by
Andrea, who uses a different re2c version from everybody else (0.13.6
instead of 0.13.5). This means that if I do some tiny change to
zend_language_scanner.l I immediately get a 3000 line diff. So we just end
up
Hi!
Sorry to intrude, but why would building be harder? Tbh I don't see the
Because there are more dependencies and tools needed to build the
parsers. You'd have to have recent re2c, for example. Which does not
come by default with many systems. I see no reason to add this hurdle
with no
Hi!
I wonder if one could replace that release server with a simple vagrant
setup or similar so the RM can actually create release archives on his
own.
I've always packaged 5.4 on my local machine, but it may have a downside
of using different bison/automake/etc. version and produce a
Hi!
May be this overflow checks should be optional?
In old ages compilers for Wirth family languages had option to enable or
disable overflow checks.
If option is enabled we may throw an exception, if no - work as today.
Any user would be able to chose between compatibility and safety.
Hi!
Why do array_* functions not treat strings as arrays of bytes?
How that's related? We're not talking about array_* functions, we're
talking about list() operator.
get busy :) - If we want to say yea list() should work with strings,
but no other array functions should work with strings,
Hi!
Long story short, because FETCH_DIM_R now supports CONST and TMP_VAR
operands, we can always use it and FETCH_DIM_TMP_VAR can be dropped -
that's all that has to be done in order to always support strings and
objects in list(). (I've linked a patch for this previously, see
Hi!
* Strings are _not_ treated as arrays of bytes everywhere.
This is true. However, sometimes they are. E.g., $string[0] is
meaningful, while array_flip($string) is not.
* If we intend to give strings more array-like support after this RFC
We don't intend to give strings anything - both
Hi!
Joe Watkins wrote (for fun) a new operator, `addressof`. Code is
here: https://github.com/krakjoe/php-src/compare/addressof
I think it makes more sense than a new method on all objects. You could
Nobody talks about new method on all objects (it's also not really
possible in PHP). We're
Hi!
In released 5.4.33 (and 5.5.17) you have 6569db8 + 84a4041 + 32be79d
(notice I have revert these 3 patches for downstream)
In 5.4/5.5/5.6 you have 6569db8 + 84a4041 + 32be79d + f86b219 + 3728449
(all reverted in 5.6.1)
As you said, 5.4 is now supposed to be security-only so I
Hi!
and weird to me, and can be quickly emulated with list($a,$b) =
str_split([“ab”][0]); if someone was actually using it.
BC breaks don't work this way. When somebody's code would break on PHP
7, their first move would not be oh, great, let's refactor it, it was
too arcane anyway. It would
Hi!
I had a discussion with another core dev who told me he did the opposite:
develop on PHP-5.5, then move the fix/feature up to the new branches (first
PHP-5.6, then master).
If you talking about developing new features, you can not develop on 5.5
because 5.5 is a stable release that is
Hi!
After a quick check
6569db8 and 32be79d are in 5.4.33 / 5.5.17 / 5.6.1RC1
f86b219 and 3728449 are in 5.6.1RC1 only
So, for 5.4 should we revert 6569db8 and 32be79d then? What about
upmerging to 5.5? What about f86b2193, should this be reverted too? I'm
feeling I don't understand what is
Hi!
I will review and report back on the 5.6.1 later today. I've checked with
the horde folks and my recent uncommitted patch resolves any bugs (both old
and new). I plan to commit this for 5.4 and 5.5 today and then subsequently
What is this new patch? Please note 5.4 is now supposed to be
Hi!
As you said, 5.4 is now supposed to be security-only so I rather
think we should revert to 5.4.32 code and have the upcoming fix only
in 5.5+ (so in 5.5.18RC and 5.6.2RC)
OK, I'll revert it then to 5.4.32 state tomorrow. But the problem is
up-merging it - are there any fixes already
Hi!
It was on design. list() was intended to support plain arrays only.
I'm not sure I'm getting this point - why list($a, $b) = $foo is not
just translated as $a = $foo[0], $b = $foo[1], etc.? Is it hard to make
it work that way?
--
Stanislav Malyshev, Software Architect
SugarCRM:
Hi!
Well, then let's remove this restriction from resources, too.
Not sure what use would it be for resources - resource IDs are not
controlled by user code and for all intents and purposes are opaque
numbers, which also do not have to be unique over the life of the
script. What use would it be
Hi!
That said, most cases of garbage in, garbage out would presumably
remain so, since most ZPP failures result in a return of NULL or
FALSE, which would probably end up cast back to the expected type
(int(0), string(''), etc) by the surrounding code.
Right. It’s not an
Hi!
I also wonder why we still need them. Doing what has been done with gmp
for all resources would be a good move for 7.
In general, I think we do not - IIRC everything resources do objects can
do better now, and the problems that prevented one from using objects
instead of resources are long
Hi!
There the assumption would be that this leads to an array $a with two
elements, where in fact there is only one if __toString() is being
called. The only thing making sense would be using using the objects
identity (i.e. via spl_object_hash()) everything else leads to issues.
This is a
Hi!
I already figured out how to solve the `is_resource()` issue. Create
an almost-useless, uninstantiatable class called Resource which any
new resource-replacing classes inherit from. Then, make
`is_resource()` check whether something is an instance of that
class.
This is a nice idea, but
Hi!
I’m not sure that’d make much sense. The object isn’t the key, the
value the magic method returns is. It would be quite odd to do this:
$someArray = [$my__hashImplementingObject = 1];
var_dump($someArray);
And see something like this, because we’ve called a hash function:
Hi!
So, the problem comes with built-in functions, which have some side
effect, which can be usefully run with a bogus value for an integer
argument. In contrast, any function which has some side effect which is
actively harmful given a bogus value would be a beneficiary of the change.
No
Hi!
I clearly didn't google, it would be interesting to see comparisons of high
speed PHP serialization libraries. I for one would be happy, in PHP 7, to
break BC serialization syntax in favour of putting in a much faster
serializer by default. Similar scenario to putting in Zend OpCache by
Hi!
Perhaps a compromise would be to choose the quickest method of
serialization, add it to PHP core.
In php.ini add the directive
serialization.method = msgpack / Igbinary /
We could, but what if you need to read/write data specifically from
current PHP serializer? You'd have to mess
Hi!
I do believe that the UString class would benefit from such a change.
Why would it be confusing to implement this?
For some objects, it may lead to rather strange results - i.e.,
Exception has __toString() but probably not very useful one for use as
an array key. So may some other
Hi!
Good evening again,
Here’s a new RFC: https://wiki.php.net/rfc/zpp_fail_on_overflow
Thoughts appreciated, as is help with the patch, though I can probably manage
on my own.
It would be nice to describe why this change is good. So far the
motivation is it is unintuitive which is a
Hi!
Most?
Python has it, java too, ruby and perl not. We can continue to list
those having them or not, not sure that brings much to this discussion.
Only Python 3 has it, and I'm not sure bringing up Python 3, given its
known adoption issues, is the best example how we could plan PHP 7. In
Hi!
I'll implement optional (and not default) support of IDN in filter_var().
Does anyone known if it's better to use libIDN (LGPL) or ICU (custom
license deviated from the X license) from a license point of view?
ICU is definitely better since we already have a lot of code using ICU
and
Hi!
There is an even better way to do this; add an additional parameter to
serialize and unserialize to serialize as and unserialize as:
$bin = serialize($data_struct, 'igbinary');
$data_struct = unserialize($bin, 'igbinary');
This is cleaner, but if you can do this (code change), why you
Hi!
I didn’t close it because the time suited me most. I made an honest
mistake and closed it 22 or so hours early because I forgot I’d
opened the vote at ~23:00 and not ~02:00. Unfortunately, I realised
my mistake after merging the patch. This was definitely not
intentional.
That's why we
Hi!
- One about having scalar typed arguements, hinted or not, simple
yes/no, so we at least agree on having the feature
I'm not sure how that would work. We agree on having what feature?
Having coercive typing and having strict typing are two different
options, working in different way and
Hello!
The PHP development team announces the immediate availability of PHP
5.4.33. 10 bugs were fixed in this release. All PHP 5.4 users are
encouraged to upgrade to this version.
This release is the last planned release that contains regular bugfixes.
All the consequent releases will contain
Hi!
The general concept should be called Optional Type Declarations, to
replace “Type Hinting. They are type declarations, and they are
optional. Thus the name. For the things themselves, they’re just Type
Declarations, to replace “Type Hints. So, for example:
I'd just call it type
Hi!
The above are, as far as I’m concerned, all potential candidates for
removal in PHP 7, so in order to reliably test a deprecated function
I would suggest introducing a hidden function with this signature:
void __deprecated__() { }
And mark that function as eternally deprecated using
Hi!
I agree that 100% is an unrealistic goal, but I don't think I've yet
seen someone actually point at a documented set of rules that even 80%
of current functions follow. I guess there is a default/normal usage of
The rules are in zpp, and every function that uses zpp automatically
Hi!
oa-res-27-90:php-src ajf$ sapi/cli/php -r 'function foobar(int $a) {
var_dump($a); } foobar(1.5);'
Catchable fatal error: Argument 1 passed to foobar() must be of the
type int, float given, called in Command line code on line 1 and
defined in Command line code on line 1
Calling this
Hi!
Please take a look and make your opinion.
https://wiki.php.net/rfc/fix_list_behavior_inconsistency
This inconsistency might be interpreted like a bug, but fixing it might
break existing PHP code (at least my attempt to fix it in documented way
broke few phpt tests).
I think it makes
Hi!
The vote would be for the RFC as it is. Possible changes are things
in the RFC I was uncertain on. I might hold votes on some of them,
actually.
I'm sorry, but this makes little sense to me. There are a number of
mutually contradictory options here, how you can vote for them as it
is?
Hi!
The “possible changes” section only details possible *changes*, that
is, changes to the RFC that could be made, but have not been. So you
OK, so by possible changes you mean things that could have been into
RFC, but were rejected and are not part of the RFC? Then I agree it is
clear but
Hi!
This is exactly the issue we are battling here. One side wants to be
consistent with inconsistencies (and tbh quite confusing) while the other
side wants to allow userland implemented APIs to actually be consistent.
It's not the issue here. Nobody wants 100% of functions to do the same,
Hi!
No, no it would not. PHP’s explicit casts cannot fail, and there is
absolutely no good reason to change this. If people want strict
casting, we can add new functions or operators for that specifically.
But to break explicit casts and make them sometimes fail would cause
innumerable bugs
Hi!
So what is the resolution for this? Should we roll back the fix,
implement the new one and have one more RC, do something else?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Hi!
Still hoping for 5.4 for at least the security related view with uniqid().
:-)
BTW, I also removed the useless modulo from microtime(). (The GitHub patch
is breaking the uniqid.c header... ignore.)
Let's ensure it works fine first, when we're sure it's good for 5.5 we
can see what
Hi!
As I understand correctly the only reason we have this discussion is
the performance impact of zpp with some functions, mainly
ZEND_FUNCTIONs. What prevents us to make them operators? That may
break things like call_user_func(strlen, $arg), array_map and the
There's also an issue that
be for security-related bugfixes. Thus, it is very important to test
this version thoroughly, as regressions in this version may be more
problematic to fix.
The release is planned in 2 weeks, September 18th, if no critical issues
will be discovered in the RC.
Regards,
Stas Malyshev
PHP 5.4 RM
--
PHP
Hi!
I have one fix for imagecrop, should be applied by tomorrow.
Didn't see the fix, so I've tagged without it in the meantime, but if
it's ready I could retag.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing
Hi!
I've created a proposed fix for #67644:
https://github.com/php/php-src/pull/798
It is the most conservative one which I'm thinking of putting into 5.4,
so that at least we won't have segfaults. If we want to improve upon it,
we can do that in 5.5/5.6, but I'd like at least plug the
Hi!
One line fix, nice :)
A quick question about how resources are freed :
if some variables are computed inside a singleton and read through a
myclass::instance()-get_my_variable(), should we expect to have those
variables available when calling ob_start() callbacks ?
From
Hi!
On Tue, Sep 2, 2014 at 12:56 AM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
I've created a proposed fix for #67644:
https://github.com/php/php-src/pull/798
Looks like this fix breaks some tests, so I'm not feeling good putting it
into 5.4. I'll revert it for now and try
Hi!
I have one fix for imagecrop, should be applied by tomorrow.
OK, go ahead and commit it, I'll wait until it's in.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Hi!
It's much more optimized than what's there now, and slightly over the old
implementation. Not sure if I should give the saved patch link, or the
live compare (?) on Github, so I'll do both for now:
http://realplain.com/php/microtime_5_4.diff
Hi!
I'm also not sure how important it is how have it for 5.4. Does the
problem that this patch fixes exist only in older versions of Windows or
on all versions? What are the actual effects of this problem - is it
just lower resolution of microtime or there can be something seriously
wrong
Hi!
I was wondering about that myself (back when it was changed last, March
2013) when a few members were removed from that structure, so I figured it
was OK to put one back. :-) No problem with binary compatibility then...?
Hi!
Instead of iterating through all objects and setting a flag, can't we
set a global flag that object dtors are not called after this point?
We could, but that would probably break some code that expects dtors to
be actually called. E.g. in the bug, the library there seems to do a lot
from
Hi!
I would like to propose a few changes to our heredoc / nowdoc scanner to make
it less awkward to use inside other constructs.
https://wiki.php.net/rfc/heredoc-scanner-loosening
Let me know your thoughts :)
With this proposal, you will not be able to use the delimiter inside the
text
Hi!
There’s no real objective measure with which I can answer such
questions :)
The closest I could come to a rebuttal is if there’s no real need to
make the syntax so restrictive, why not make it less restrictive?
Why not is usually not a very good reason for a change in the language
Hi!
This is just a thought; could we delay the call to
`zend_call_destructors` ONLY IF there’s output buffering taking place
(i.e. ob_get_level() 0)?
That wouldn't help - imagine this:
1. ob_start is set
2. shutdown is starting
3. ob functions shut down, call function foo
4. function foo
Hi!
5.6.0 has been released, and first thing I'd like to congratulate all
who participated in it with this great milestone.
Second thing, that means 5.4.33 would be the last release including
non-security fixes. With RC1 planned next Tuesday, this means if you've
got any non-security issues that
Hi!
If https://bugs.php.net/bug.php?id=67644 could be fixed in 5.4.33 (and
5.5 as well) it would be really great !
Thank you, I will take a look.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To
Hi!
Does anyone have any objections to this being included in 5.4?
Thanks, Chris
[1]
https://github.com/DaveRandom/php-src/commit/d4da5d8c1dae152f7aa5f0dd09b1f29b51f48c89
I think it's ok for 5.4.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP
Hi!
On a similar theme, could we also get rid of the generated Zend VM,
and wire up zend_vm_gen.php to make like we wire up bison and re2c?
That would make building PHP for non-internals person harder and the
list of dependencies they need to get right longer. While providing zero
added value.
Hi!
Why would a non-internals person want to build PHP from git? That’s
Why not? It's an open-source project, isn't it? People may prefer using
git, many integration systems (including PHP's own composer) rely on git.
just making things harder on themselves. Besides PHP itself (should
my
Hi!
I don't know if I will be implementing that ext myself. In any case, before
that can happen I will have to create another RFC for converting parse
errors into exceptions and making sure we don't leak memory on failed parse
If we're talking the plunge of putting exceptions into the core
Hi!
This is something that Nikita had originally proposed in an RFC
(https://wiki.php.net/rfc/engine_exceptions) but postponed until after 5.6.
I have a feeling we'll be hearing about its resurrection soon enough.
5.6 was not a good place for it, but PHP 7 very well may be. Some
cleanup to
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
Hi!
Committed and it works, the build done at travis finished OK.
Yes, I saw it, thanks. A number of tests on debug version have errors or
segfaults or glibc memory errors. Somebody probably should look into this.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi!
Can you post the list of failed tests
Can be seen here:
https://travis-ci.org/php/php-src/jobs/33142160
the list isn't full because it times out now (also shows multiple **
ERROR: process timed out ** messages).
If you look there for Segmentation fault or *** glibc detected ***
you'll see
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.
--
Stanislav Malyshev, Software Architect
SugarCRM:
Hi!
array of registered resources of particular type. See patch:
https://gist.github.com/dstogov/f96c04f5979e726909ab
It would be better as a pull, it's be easier to comment on it.
For the function get_resources, the proto says it has no arguments, but
it actually has one S argument that is
Hi!
Removed phpdbg build from configure, and master builds fine.
Removed its tests as well to have travis finish green.
Did you commit it? I see Travis CI build is still broken.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime
Hi!
There are some PRs for supports of PowerPC64
https://github.com/php/php-src/pull/734
https://github.com/php/php-src/pull/735
https://github.com/php/php-src/pull/736
https://github.com/php/php-src/pull/737
Anyone can review them?
or, I will commit the
Hi!
Quick test build (using fedora 5.6.0RC4 package on RHEL-7...)
(notice, report will be clean in a few days)
Thanks a lot, Remi! Looks like something is not right with these patches
Without the patches
https://kojipkgs.fedoraproject.org//work/tasks/9765/7399765/build.log
Number
Hi!
Since we've had phpng branch merged to master the build on Travis CI is
broken for master (as in, doesn't even build). Could it be fixed? It's
not a good thing that we have master branch that CI can not even run on.
I suspect it has to do with phpdbg but didn't look into it in depth.
--
Hi!
I opted for master-only on the grounds that while it's an improvement,
it's not really a bugfix, and released versions (or versions as near
to release as 5.6 is) should be bug-fix only. I know there's an
argument for this *being* a bug-fix, but...
If a consensus feels it should be
Hi!
Moving this out of other topics into its own: according to the release
RFC, we should have 5.4 have 2 years of bugfixes one year of security
fixes. Since 5.4 was released in March 2012, we're already past 2 year
mark. However, we're still have some bugfixes in 5.4, so I'd like to do
this:
-
Hi!
I have a small clarification question on the RFC: you are adding
another parameter to bindTo which defaults to false, but I didn't
quite understand the reasoning. Can you try explaining that to me in a
different way?
Interestingly enough, the RFC doesn't even mention this change.
--
Hi!
It does, but maybe you missed it. Under the Proposal section:
To solve this, we relax the current invariant of scoped closures
having to be bound, and add a new parameter to bind(To) to produce
an unbound, scoped closure, like so:
Indeed, I missed it - I was looking for bindTo. I think
Hi!
the release process rfc (https://wiki.php.net/rfc/releaseprocess) governs
the releases since 5.4: 2+1 year of support after the initial X.Y.0 release.
as pointed out, 5.4 is already past the 2 years of bugfix support, so we
should announce it that it is on security fixes only.
5.4.32 is
Hi!
The source of the problem is that the open_basedir will always leek
information about dirs that the user is not suppose to see (out of the
open_basedir restriction). The reason is that false value can indicate
that (more info in the PR or https://bugs.php.net/bug.php?id=65489 ).
However
Hi!
PHP 5.3 has reached the real end of life. Will the effect be that from
now on PHP 5.4 will only get security fixes?
There's no dependency between the two in the release RFC, but it would
probably make sense to move 5.4 into security only phase once 5.6 is
GA, and set EOL date for 1 year
Hi!
Sorry, I missed that one. I suspect it was the time where I
misconfigured git and branches did not get merged. Feel free to merge
it back/backport as I won't be able to do it before Monday.
OK, I have backported it (and following Anatol's patches for it).
--
Stanislav Malyshev, Software
Hi!
And this, which is completely undetectable at parse time:
$bar = 30;
// ... arbitrary amount of code
switch ( $foo ) {
case $bar:
case 30:
}
That's not all. You can also do:
switch (true) {
case foo($bar):
...
case baz($quz, $qux):
...
}
and this is a completely
Hi!
I've just been looking back at the history of this previous conversation...
http://marc.info/?l=php-internalsm=132673741606531w=2
as a mockist tester I'd really REALLY like to see this be possible but I
can see the problem with the original patch modifying the actual existing
class.
Hi!
Recently bug 47358 came to my attention, and there's something strange
with it. It is fixed only for 5.6, not listed in NEWS for even that
version, but the log contains these:
commit f566b4d32183032663ecb35895c0dafd8e051853
Merge: 7a13ce6 10a2c0d
Author: Pierre Joye pierre@gmail.com
refer to the NEWS file:
https://github.com/php/php-src/blob/php-5.4.32RC1/NEWS
Please test it carefully, and report any bugs in the bug system.
The release is planned in 2 weeks, August 21th, if no critical issues will
be discovered in the RC.
Regards,
Stas Malyshev
PHP 5.4 RM
--
PHP
Hi!
https://wiki.php.net/rfc/function_referencing
This syntax collides with by-ref assignment and by-ref arrays, which is
not good. Different things should not look the same.
I'm not sure also how exactly non-closures can function as closures - if
you take SplFixedArray::getSize and rebind it
Hi!
It doesn’t collide, there is no syntactical ambiguity at an engine
level, at least. It does unfortunately look similar, however. The
That's the collision. It looks exactly the same, but does entirely
different thing. This is not good.
choice of syntax is largely for a lack of better
Hi!
It doesn’t look exactly the same, you can’t reference a constant.
That's why it is bad - because it looks like you're referencing a
constant, but in fact it does something completely unrelated.
In C and C++ you get a function pointer. Here you get a closure. In
both cases you get
Hi!
Right, while FooBar::$methodname would conflict, $classname::foo
would not. I do neither for the sake of consistency, as having one
but not the other worse might cause confusion. This has the benefit,
I suppose, that is completely static. You can see at “compile-time”
whether it’s valid
Hi!
What I found *not safe*, throwing unwanted warnings hitting an
undesired behavior, or even segfaulting, and thus needing patch :
- Dom
- Mysqli
- sqlite3 (sqlite3stmt class segfaults)
I've fixed all the instances of problematic behavior with no ctor that I
could catch now. I could not
Hi!
It would be good to have a section in UPGRADING.INTERNALS explaining
in details what should be done, very important for non core extensions
(pecl or other repositories).
Probably a good idea but I'm not sure what exactly to write there,
besides initialize everything, check everything :)
Hi!
Yes, I agree that this is not correct behavior - and I don't really
understand why it was introduced and why it isn't trivial to fix.
PHP-5.5 had a check for this case in place
(http://lxr.php.net/xref/PHP_5_5/Zend/zend_compile.c#7071) and phpng
contains an AST-compatible variant of the
Hi!
nope, some mock frameworks do that (afair atoum for example) but
phpunit(phpunit-mock-objects to be more precise) was using the serialize
trick and newInstanceWithoutConstructor()
Hi!
Could somebody please clarify what issues are still open here? From what
I understand, both the opcache issue and the recursion issue are fixed
now. What's the discussion about?
As I understand, the issue is that if you define class constant like this:
class Foo { const Bar = [0]; }
Hi!
What I found *not safe*, throwing unwanted warnings hitting an
undesired behavior, or even segfaulting, and thus needing patch :
- Dom
- Mysqli
- sqlite3 (sqlite3stmt class segfaults)
I'm testing a patch for sqlite3 right now and will commit it shortly,
but I could not reproduce
Hi!
What I found *safe*, with checkers that check object is properly
initialized, so not needing patch, but throwing exceptions or warnings
when used bad constructed :
- SPL
SPL unfortunately is not safe at all - a lot of iterator classes
segfault on no-ctor initialization. I'll make a patch
101 - 200 of 1748 matches
Mail list logo
