Re: strict-api - Proposing a tool to check and enforce encapsulation

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.