[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 2586 - trunk trunk/subversion/libsvn_subr

From: Nuutti Kotivuori <naked_at_iki.fi>
Date: 2002-07-21 14:20:35 CEST

Karl Fogel wrote:
> Justin Erenkrantz <jerenkrantz@apache.org> writes:
>> > I wish. However, currently the functions return EINVAL, not
>> > APR_EINVAL. The APR_STATUS_IS_EINVAL macro only tests for the
>> > latter, I thought.
>>
>> On systems where EINVAL is defined (i.e. where the old code
>> compiled), APR_EINVAL is just #define'd to EINVAL.
>>
>> APR is full of neato-tricks like that. -- justin
>
> So on other systems, the APR_STATUS_IS_EINVAL(apr_status) macro can
> return true not only when
>
> apr_status == APR_EINVAL (but not necessarily equal to EINVAL)
>
> ...but also when it matches certain other conditions.
>
> In other words, it's fine for apr_xlate_open function to return
> APR_EINVAL instead of EINVAL, but if that precise value is to signal
> a specific condition, then callers should use a direct equality test
> instead of the APR_STATUS_IS_EINVAL() macro. Or so I would think?

Ouchie. Hey, I'm not the APR guru here, you guys are. But I still
think this is not the way to go here.

First the couple facts:

- APR_EINVAL can either be equal to EINVAL, or not.

- APR_STATUS_IS_EINVAL(s) checks whether s is EINVAL or APR_EINVAL,
but does check for other values as well.

So, the first conclusion to come from this is:

- Hey, if I return APR_EINVAL explicitly and check for APR_EINVAL
explicitly, I will detect my precise condition for returning it!

But the obvious counter-conclusion that comes a bit later:

- APR_EINVAL can be EINVAL for real, so I might assume a system
returned error as my precise condition on one platform and not on the
other. And even if APR_EINVAL and EINVAL are different, some APR
function might explicitly return APR_EINVAL.

So, even if no APR functions are called in this case, using APR_EINVAL
as an explicit test is just going to obfuscate things further if that
happens to be the case some day.

And, if there is a explicit condition to be returned by the function,
that should be returned as a new error/status code, that is guaranteed
not to have any double meanings.

But, I might be talking out of my ass, since I don't really know how
these are supposed to be used.

-- Naked

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 21 14:22:30 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.