> +#define ZVAL_ADDREF(pz) ++(pz)->refcount; > +#define ZVAL_ADDREF_M(pz, count) (pz)->refcount += (count); > > "_M"? Doesn't seem to be self-descriptive..
It was supposed to stand for "multiple', but you're right that it's not very clear. > +#define ZVAL_ADDREF_NP(pz) ++(pz).refcount; > > "_NP" ? "not pointer" ? > Most of the macros in the engine are called this way: > <macro>() - operates on zval struct > <macro>_P() - operates on pointer to zval > <macro>_PP() - operates on pointer to pointer > > It would be good to conform this de-facto standard. As I wrote in a previous e-mail, there was already a ZVAL_ADDREF which was being used that operated on zval pointers. However, I think I agree that the name should be changed. Would anyone object to having all the macros suitably renamed? In addition, ZVAL_ADDREF_M would be changed to ZVAL_ADDREF_MULTIPLE_P, etc. unless someone can think of a better name. > > +#define ZVAL_MARKREF(pz) (pz)->is_ref = 1; > +#define ZVAL_UNMARKREF(pz) (pz)->is_ref = 0; > +#define ZVAL_SETISREF(pz, isrefv) (pz)->is_ref = (isrefv); > > So do they MARK or SET? > We should choose one of them to be consistent. > I personally prefer SET. I use "MARK" as the terminology for setting is_ref to true, "UNMARK" for setting the is_ref to false. And SETISREF to set the state of the IS_REF bit to the macro parameter. I'm not really sure what you're proposing. ZVAL_SETREF, ZVAL_UNSETREF and ZVAL_SETISREF? I thought it would be more confusing because there would be a ZVAL_SETREF and a ZVAL_SETISREF. Separate macros for marking, unmarking and setting the boolean to an argument are necessary because one of the possible optimizations for gc is to use the unused bits of the is_ref uchar to store gc information and there would be certain optimizations for using three macros instead of just the last one. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
