Hi Bob,
Le 13/09/2015 00:44, Bob Weinand a écrit :
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.
I was probably not clear enough : you will *never* debug code
configured/compiled in zstrict mode. This mode is reserved for
compile-time checks only. Once you have checked that everything compiles
fine in zstrict mode, the next step is to 'make clean' and throw the
compilation result away. You can 'make test' before, if you want, but
you will never distribute nor debug code compiled in zstrict mode.
The same with travis: the zstrict flag can be set only because the
resulting code will never be distributed nor used for debugging.
So, there's no question of debug macro nor .gdbinit. When debugging your
code, you'll keep using the usual field names
(fbc->op_array.filename->val for instance).
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
