On Sun, Sep 13, 2015 at 12:44:14AM +0200, Bob Weinand wrote:
> > Am 08.09.2015 um 00:41 schrieb François Laupretre <francois@php.net>:
> >
> > Hi,
> >
> > I have written a follow-up to my previous 'zstrict' PR. It is now focused on a simple mechanism to detect API violations :
> >
> > https://github.com/php/php-src/pull/1508
> >
> > This version just implements the mechanism and applies it to the zend_string val/len/h elements. More details in the PR.
> >
> > Please comment first. Then, when we're OK on the feature, we may talk about the target version.
> >
> > Regards
> >
> > François
>
> While I don't disagree with the idea of making accidental direct access harder, I see a particular disadvantage for debugging.
>
> Nobody will like to write "p fbc->op_array.filename->zstrict_field_zend_string_val" (I hope I got it right?) just to figure out where the targeted op_array is located. [At least lldb only shows one character of the value when just printing the zend_string, due to the struct hack...]
> Now you may say macro? Well, honestly, I don't usually use macros (as .gdbinit isn't compatible with lldb and lldb is more stable than gdb on OS X)
>
> While it brings a minor guarantee that the ZSTR_*() API is really used, it makes debugging much harder; so I prefer to not merge this patch.
>
> Thanks for your efforts here though!
>
> Bob
> --
The concept of zstrict is huge, so many extensions when porting from
5 -> 7 made things work via duct-tape. If we had zstrict ~5 it would
have saved weeks of my life.
Bob has an excellent point though, it is really nice that I don't have
to depend on .gdbinit I find myself looking at coredumps on hosts that
don't have the latest and greatest GDB (FreeBSD's in-tree) or no GDB at all,
and I don't have root access (but have lldb) .
Has anyone brought up the idea of using something like lint? Maybe call
a tool maintained in tree maybe from the `test` target in the Makefile
spit out by phpize. That way extension maintainers will start getting test fails,
but no one else will see a change.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> > Am 08.09.2015 um 00:41 schrieb François Laupretre <francois@php.net>:
> >
> > Hi,
> >
> > I have written a follow-up to my previous 'zstrict' PR. It is now focused on a simple mechanism to detect API violations :
> >
> > https://github.com/php/php-src/pull/1508
> >
> > This version just implements the mechanism and applies it to the zend_string val/len/h elements. More details in the PR.
> >
> > Please comment first. Then, when we're OK on the feature, we may talk about the target version.
> >
> > Regards
> >
> > François
>
> While I don't disagree with the idea of making accidental direct access harder, I see a particular disadvantage for debugging.
>
> Nobody will like to write "p fbc->op_array.filename->zstrict_field_zend_string_val" (I hope I got it right?) just to figure out where the targeted op_array is located. [At least lldb only shows one character of the value when just printing the zend_string, due to the struct hack...]
> Now you may say macro? Well, honestly, I don't usually use macros (as .gdbinit isn't compatible with lldb and lldb is more stable than gdb on OS X)
>
> While it brings a minor guarantee that the ZSTR_*() API is really used, it makes debugging much harder; so I prefer to not merge this patch.
>
> Thanks for your efforts here though!
>
> Bob
> --
The concept of zstrict is huge, so many extensions when porting from
5 -> 7 made things work via duct-tape. If we had zstrict ~5 it would
have saved weeks of my life.
Bob has an excellent point though, it is really nice that I don't have
to depend on .gdbinit I find myself looking at coredumps on hosts that
don't have the latest and greatest GDB (FreeBSD's in-tree) or no GDB at all,
and I don't have root access (but have lldb) .
Has anyone brought up the idea of using something like lint? Maybe call
a tool maintained in tree maybe from the `test` target in the Makefile
spit out by phpize. That way extension maintainers will start getting test fails,
but no one else will see a change.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php