https://bz.apache.org/bugzilla/show_bug.cgi?id=63900
Christophe JAILLET <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Christophe JAILLET <[email protected]> --- (In reply to legendt from comment #2) > But I would suggest tp preserve APR_ENOTIMPL rather than to translate it to > APR_SUCCESS to represent the default behavior. If more error codes have been > implemented in the ap_run_mpm_query function, simply ignoring such errors > can be potentially harmful. There is no reason to have other error code returned by an 'ap_hook_mpm_query' hook function. These functions are just there to tell if something is supported by the MPM or not. If it is so puzzling, the 'status = APR_SUCCESS;' could be removed. 'status' is not used anywhere below, before it is overridden by another (real) error code. (In reply to legendt from comment #3) > Though they return in rv, but some do return APR_EGENERAL. > > For example, the ap_mpm_query does not preserve APR_ENOTIMP. It does return > APR_EGENERAL. So what you said cannot hold. 'ap_hook_mpm_query' hook functions never return DECLINED. So APR_EGENERAL will never be returned by 'ap_mpm_query()'. And even if one did, there would be much more trouble somewhere else. > if (status != APR_SUCCESS && status != APR_EGENERAL) { Your proposal is just over-engineering something that looks safe, just in order to please a static analyzer. As said, IMHO, the only thing that could go in your direction (and would align with what is done in 'http_post_config()') would be to remove the 'status = APR_SUCCESS;'. It is useless. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
