At 03:37 PM 5/10/2002, Aaron Bannert wrote:
> > OTOH, I don't think we should be encouraging non-zero checks on status
> > values.
>
> if (my_apr_err != APR_SUCCESS) {
> ..uh-oh...
> }
this one good. :)
Not really.
Consider that it encourages authors to use (my_app_err == APR_EAGAIN).
That is semantically -very-bad-.
Further, can we envision that there is more than one case of success?
For example, many have whined about APR_EINCOMPLETE, which is
truly a success case. The apr_file_stat() worked, the platform just didn't
get you everything you wanted (and never will, no matter how many calls
you make.)
Now, with apr_fileinfo_t->ctime split between apr_fileinfo_t->itime (supported
on Unix for inode/metadata change time) and apr_fileinfo_t->ftime (supported
on all non-unix platforms as the file creation time), which I intend to commit
this weekend, almost any request could become EINCOMPLETE if you ask
for all APR_FINFO_TIMES. {ick.}
I've also argued that charset conversion where some bytes are transformed
and the conversion ended due to buffer full or an incomplete multibyte sequence
are flavors of success, not failure. Results were returned; they just didn't
finish up in a single call.
Well, that's my 2c. I'm not suggesting we roll in APR_EINCOMPLETE just
now for APR_STATUS_IS_SUCCESS(). I am suggesting that many bugs
so far have been directly testing the apr_status_t rv, rather than using the
macros. Removing the macro leaves me wondering how soon it might
need to return.
