On Sun, Sep 13, 2015 at 12:44:14AM +0200, Bob Weinand wrote: > > Am 08.09.2015 um 00:41 schrieb François Laupretre <franc...@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
