Re: com php-src: Fix spl_directory cast_object, reenable error: Zend/zend_execute.h ext/spl/spl_directory.c

I restored comments above this warning. you may add your explanation there to be not forgotten. We'll have to decide about it later. I see two disadvantages: 1) it changes behavior in som cases 2) it addes code in inline function that is going to be duplicated all around the code (later it;s going to be JIT-ed). anyway, it may wait until the cleanup process. Thanks. Dmitry. On Tue, May 13, 2014 at 8:44 PM, Nikita Popov <nikita.ppv@gmail.com> wrote: > On Mon, May 12, 2014 at 10:01 PM, Dmitry Stogov <dmitry@zend.com> wrote: > >> got it. but it mean that any internal class might need be changed to >> avoid this warning. >> May be you can think about a better place for this warning? >> >> Thanks. Dmitry. >> > > I'm not sure what else this error can go. This error that is triggered by > all our casts (zendi_convert_to_*, convert_to_*, convert_to_*_ex, > zval_get_*, zend_make_printable_zval). It was only missing from > zend_is_true in particular. Why should be make an exception for it? > > If a cast_object handler didn't handle IS_BOOL correctly, then it was just > luck that an error was never encountered - it means that it was only used > in if($obj) or similar, but never as (bool)$obj etc. However, the fact that > nobody encountered the issue, because convert_to_boolean codepaths are used > more rarely, does not mean that the issue didn't exist. So the cast_object > handler would have to be fixed anyway - now it's just more likely that the > issue will be actually found. > > Anyway, I just checked the code for all exts overwriting cast_objects > (gmp, sxe, com, tidy, spl_directory) and it looks correctly handled > everywhere now :) > > Nikita > >