On Tue, 2 Jul 2002, Aaron Bannert wrote: > Adding another apr_status_t code would be ok. Maybe APR_FAILURE to > complement APR_SUCCESS, or we could go all out and add APR_TRUE > and APR_FALSE...
I was thinking about that. But then APR_FALSE == APR_SUCCESS for the normal semantics to work out. Does APR_TRUE != APR_SUCCESS make sense? I'm not sure. With APR_FAILURE, it would seem to me as easy target for abuse in the same way that APR_EGENERAL has been since it was created. Originally it was very tightly scoped in meaning, but since then it's been used for all kinds of things other than what was originally intended. My suggestion was going to be to just add a parameter that is an int* and return true/false that way. If false is returned, you can check the apr_status_t to see what happened. Or maybe it should be the other way around, with int returned and an apr_status_t* in the parameter list. Whatever. --Cliff
