Hi, Thanks for getting back to me quickly.
> > Was there some particular reason to remove those ()'s around the > macros? > > (usually they're there for a reason :) The reason for doing this is that in GC code "++(pz)->refcount;" becomes "++(pz)->refcount; (pz)->color__gc = GC_BLACK;". Those are two separate statements that cannot be comfortably folded into one that returns the resulting refcount of the operation (I thought that having inline functions for all of these macros would have been overkill). The purpose of the extra semicolon is to explicitly enforce treating these macros as statements rather than as value returning functions. If the semicolon was not there, code such as "refcount = (ZVAL_ADDREF(pz));" will work now, but will not work if GC code is implemented. Technically, only ADDREF macros needs this behavior, but the same thing is done to DELREF, MARKREF, UNMARKREF and SETISREF macros for consistency (and future-proofing... It's possible that extra statements may need to be added later). Basically, the semicolon is for future-proofing. Since all of these macros are "statements" and not "functions", there's no need to have the parentheses anymore (since they're there to protect the return value of the macro in case it was used). > Also, extra ; is not needed and doesn't conform to the style of other > PHP code. Macros usually don't need ; at the end. I was trying to adhere to the style for multi-statement macros, for example: ZEND_OBJECTS_STORE_ADD_TO_FREE_LIST(). > Also, these: > +#define ZVAL_ADDREF(pz) ++(pz)->refcount; > +#define OBJ_ADDREF(obj) ++(obj)->refcount; > look quite confusing. I'm not quite sure what you mean... > And, PHP usually doesn't have _NP macros. If you need pointer and > non-pointer macro, do non-pointer one and add _P's to it. There is a pre-existing macro in zend.h called ZVAL_ADDREF and it operates on zval pointers. My reasoning was that it would be best not to redefine what that macro operates on and just add _NP versions. However, this can be changed around fairly easily. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
