Fixed bug #70912 (Null ptr dereference instantiating class with inval…

[reeze]

The previous related fix is 2a1a8f9 for bug #70183
This check has to be done in compile time or it will be delayed to runtime and lead crash.

And ast->child[0] couldn't be null, so there is no need to check it.

@weltling since you pulled that patch.

[laruence]

it's a little awkward, I already fixed this in locally(25de928), and running tests, when I came back from dinner, you made this PR....

hmm, core bugs will always be take care carefully and immediately by us. you don't need to rush for them. and actually I think my fix is a little better.

anyway, thanks for looking into it.

[weltling]

Yeah, that's the leftover from #70183. 5.6 has probably similar logic, but it's compensated by the fact such code is a syntax error there (and the previous patch throws a compile error which is compatible with 5.6).

@laruence, yep, sparing those zend_eval_const_expr() calls is a little better, as that if statement is needed anyway.

But at the end it's important we have a fix for that, so many thanks everyone :)

[reeze]

thank you :) i am glad you made a have a better solution. anyway it is a
community project.i'd love to make my contribution to it.

On Saturday, 14 November 2015, Anatol Belski notifications@github.com
wrote:

Yeah, that's the leftover from #70183. 5.6 has probably similar logic, but
it's compensated by the fact such code is a syntax error there (and the
previous patch throws a compile error which is compatible with 5.6).

@laruence https://github.com/laruence, yep, sparing those
zend_eval_const_expr() calls is a little better, as that if statement is
needed anyway.

But at the end it's important we have a fix for that, so many thanks
everyone :)

—
Reply to this email directly or view it on GitHub
#1637 (comment).

Reeze Xia
http://reeze.cn