[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 1919 - trunk/subversion/clients/cmdline

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-05-10 22:42:23 CEST

Greg Stein <gstein@lyra.org> writes:
> > > Subversion currently has a mixture of APR_STATUS_IS_SUCCESS and
> > > explict tests. I much prefer consistency, would it be OK to change
> > > all Subversion's APR_STATUS_IS_SUCCESS() uses into explict tests?
> >
> > Yes. And +1 to doing so.
>
> Definitely. And another +1 from me.
>
> APR_SUCCESS is absolutely and always defined to be zero. Explicitly. And
> with the sole purpose being able to easily test for an error.

This issue keeps coming up, and every time I ask the same question.
Perhaps I'm just forgetting the answer each time? Anyway:

If APR_SUCCESS is absolutely and always defined to be zero, then why
does apr_errno.h define the APR_STATUS_IS_SUCCESS() macro like this
under WIN32

  #define APR_STATUS_IS_SUCCESS(s) ((s) == APR_SUCCESS \
                  || (s) == APR_OS_START_SYSERR + ERROR_SUCCESS)

and like this under OS2:

  #define APR_STATUS_IS_SUCCESS(s) ((s) == APR_SUCCESS \
                  || (s) == APR_OS_START_SYSERR + NO_ERROR)

That looks a bit more complex than just "== 0" to me... ?

Don't get me wrong: I too would like to test explicitly for it, but
the code above makes me think the macro is necessary (also, the
*existence* of the macro would make anyone think it's necessary to use
it -- if direct comparison is just as good, then is there any chance
of persuading the other APR developers to toss the macro?)

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 10 22:42:55 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.