Re: cvs: php4 /ext/curl curl.c /ext/imap php_imap.c /ext/java java.c /ext/muscat muscat_net.c /ext/oci8 oci8.c /ext/satellite class.c typecode.c
/ext/sybase php_sybase_db.c /ext/sybas

On Thu, 27 Sep 2001, Jeroen van Wolffelaar wrote: > On Wed, 26 Sep 2001, Sterling Hughes wrote: > > > On Wed, 26 Sep 2001, Jeroen van Wolffelaar wrote: > > > > > jeroen Wed Sep 26 04:35:47 2001 EDT > > > > > > Modified files: > > > /php4/ext/curl curl.c > > > /php4/ext/imap php_imap.c > > > /php4/ext/java java.c > > > /php4/ext/muscat muscat_net.c > > > /php4/ext/oci8 oci8.c > > > /php4/ext/satellite class.c typecode.c > > > /php4/ext/sybase php_sybase_db.c > > > /php4/ext/sybase_ct php_sybase_ct.c > > > /php4/ext/xmlrpc xmlrpc-epi-php.c > > > /php4/ext/xslt xslt.c > > > /php4/ext/yaz php_yaz.c > > > Log: > > > 3rd run in back-substitutin Z_* macro's. The val->Z_ cases are all solved > > > now. > > > > > > > you broke curl and xslt in this commit which were already 100% macro > > compliant. Just looking at the other extensions you broke them > > too... > > I see. Were they (curl&xslt) really broken? If I substitute that macro, > for example here: > > - return_value->result.type = XSLT_IS_DATA; > + Z_TYPE(return_value->result) = XSLT_IS_DATA; > > I get: > (return_value->result).type = XSLT_IS_DATA; > > Which is the same... Of course, there shouldn't be macro's here, because > the argument isn't a zval. > Tommorow andi changes the zval structure to rename type to z_type. The accessor macro's will still work on zval's however, they won't work on my structure. Accessor macro's for zval should only be used for zval's. IMHO, for the change to stay *all* places where these types of mistakes occur *must* be corrected, regardless of whether it compiles and "works", its better to not use these macro's at all, than to use them improperly... I see evidence throughout the modules that this is messing with things it really shouldn't, and therefore I'm -1 on the commit. -Sterling