On Wed, Nov 11, 2009 at 6:58 PM, Greg Stein <gst...@gmail.com> wrote:
> On Wed, Nov 11, 2009 at 17:11, Jeff Trawick <traw...@gmail.com> wrote:
>> At present, whatever was in errno at the time the dav_error {} was
>> created is treated as an apr_status_t by ap_log_rerror().
>>
>> http://mail-archives.apache.org/mod_mbox/httpd-dev/200211.mbox/%3c20021101033848.b29...@lyra.org%3e
>>
>> dav_error {} should have an apr_status_t field instead of an errno
>> field; functions which create a dav_error should have an apr_status_t
>> parameter.
>>
>> If there's no direct apr_status_t representation of the error, the
>> caller will have to decide what to do (no magic portable solution
>> AFAIK, but no worse than today).
>>
>> Concerns?
>
> dav_error was designed during the 1.3 series. APR wasn't even being
> discussed. So yeah... there is definitely a disconnect from "then" to
> "now".
>
> I'd be quite supportive of changing that, though (strictly speaking)
> that is probably an API change.
well, yes it is an API change ;) I think the issue is whether or not
you in the DAV community want to push it on your third-party
colleagues.
A third-party mod could define something like this for compatibility:
#if AP_MODULE_MAGIC_AT_LEAST(xxx,y)
#define foo_dav_new_error(p, stat, errid, rv, desc) \
dav_new_error(p, stat, errid, rv, desc)
#else
#define foo_dav_new_error(p, stat, errid, rv, desc) \
(errno = (rv), \
dav_new_error(p, stat, errid, desc))
#endif
and go ahead and change its code to pass in an apr_status_t.
If it is too ugly to force this on third-party modules, we'll need to
add new APIs and use those ourselves, as it is too ugly for us to keep
mismanaging the error codes.
