> Am 13.09.2015 um 03:24 schrieb François Laupretre <franc...@php.net>: > > 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
Well, that either just makes workflow unnecessarily complex or many devs just won't care too much about it… and these who do may be annoyed to fix others code before it's useful for themselves... (Also, I don't think like some devs will be particularly eager to recompile before each push … it doesn't take just one minute on every machine) Additionally, extension devs… They'd have to switch target php install while coding, just to check against zstrict install and no zstrict. Well… that just begins to become insane. Sorry, but making zstrict optional is just plain annoying of developers... Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
