RE: [PHP-QA] RE: [PHP-CVS] cvs: php4(PHP_4_0_5) /ext/ircg config.m4 ircg.c php_ircg.h

Depending on the changes whether they are more enhancements or showing stopping bug fixes, could they not be withdrawn and put in as first changes for 4.0.6? > -----Original Message----- > From: James Moore [mailto:jmoore@php.net] > Sent: Sunday, April 22, 2001 5:01 PM > To: Sascha Schumann > Cc: php-cvs@lists.php.net; PHP Quality Assurance Team Mailing List; > h.radi@nme.at > Subject: RE: [PHP-QA] RE: [PHP-CVS] cvs: php4(PHP_4_0_5) /ext/ircg > config.m4 ircg.c php_ircg.h > > > > On Sun, 22 Apr 2001, James Moore wrote: > > > > > > > > > > sas Sun Apr 22 08:17:57 2001 EDT > > > > > > > > Modified files: (Branch: PHP_4_0_5) > > > > /php4/ext/ircg config.m4 ircg.c php_ircg.h > > > > Log: > > > > MFH allocation-related and thttpd-independence changes > > > > > > Sascha can you please STOP MFH'ding > > > > Well, that really surprises me. I commit minimal changes > > while other people commit _huge_ patches to the release > > branch and noone complains about that. > > > > Regardless, the changes I just committed are _all_ > > self-contained. They cannot affect anything else (beside the > > single config.m4 change which has been merged from the head > > branch). And hence, they are in good tradition with what has > > happened up to now to the 4.0.5 branch. > > Sorry Sascha, > I missed the com changes too, I just saw the thttpd and ircg changes.. > > Herald I trust you will be helping to test RC8 too please dont MFH this late > in the process and before you do so send a mail to PHP-DEV and PHP-QA > justifying your changes and why they are so urgent that they require the > delay of the release of PHP 4.0.5 is it really that necessary to fix the mem > leak?? > > TO both of you we have just tested RC7 please be realistic and if you > changes REALLY need to be in 4.0.5 then thats OK and we will test again but > if they are not critical then please revert the patches you are delaying > the release of 4.0.5 further by forcing another RC cycle. > > Sascha looking at your patch: > > +PHP_FUNCTION(ircg_ignore_add) > +{+#if defined(IRCG_API_VERSION) && IRCG_API_VERSION >= 20010402 > + zval **args[2]; > + php_irconn_t *conn; > + smart_str s; > + > + if (ZEND_NUM_ARGS() != 2 || zend_get_parameters_array_ex(2, args) == > FAILURE) > + WRONG_PARAM_COUNT; > + > + convert_to_long_ex(args[0]); > + convert_to_string_ex(args[1]); > + > + conn = lookup_irconn(Z_LVAL_PP(args[0])); > + if (!conn) RETURN_FALSE; > + > + smart_str_setl(&s, Z_STRVAL_PP(args[1]), Z_STRLEN_PP(args[1])); > + irc_ignore_add(&conn->conn, &s, 1); > +#endif > +} > > Would it not be better to have an else here the outputs a warning rather > than having the possibility of > > PHP_FUNCTION(ircg_ignore_add) > { > } > > The same is true of: > ircg_ignore_del > > and seemingly a lot of the IRCG functions.. > > - James > > > -- > PHP Quality Assurance Mailing List <http://www.php.net/> > To unsubscribe, e-mail: php-qa-unsubscribe@lists.php.net > For additional commands, e-mail: php-qa-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net >