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

Re: [PATCH] docstrings on apr_filepath_merge() flags?

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-07-18 22:18:42 CEST

Ben Collins-Sussman <sussman@collab.net> writes:

> I've got a path as a command-line argument, and I'm trying to convert
> it to canonical case using apr_filepath_merge:
>
> apr_err = apr_filepath_merge (&truenamed_target, NULL, raw_target,
> APR_FILEPATH_TRUENAME, pool);
>
> Unfortunately, this had the side-effect of converting a relative path
> into an absolute path.
>
> After some experimentation, I discovered that adding the
> APR_FILEPATH_NOTABSOLUTE flag prevented this behavior.
>
> What annoys me is that I *deliberately* ignored this flag, because of
> its cryptic docstring:
>
> /** Fail apr_filepath_merge if the merged path is absolute */
> #define APR_FILEPATH_NOTABSOLUTE 0x08
>
> I read this docstring, and thought it was talking about somehow
> restricting the *inputs* to the function... like forcing the function
> to only accept absolute paths, or something. It doesn't make a lot of
> sense.

[Crossposting to svn and apr lists. svn people, read my original mail
to apr above.]

Argh, it seems that this flag doesn't do exactly what I thought.

The flag definitely prevents apr_filepath_merge from absolutizing
everything; but now it actually *errors* if you pass an absolute path
into it!

I need a simple behavior: "accept either relative or absolute input;
and don't change the output at all." That is, relative input produces
relative output, and absolute input produces absolute output. I
*just* want the case canonicalized, no other side-effects. :-)

Does this mean it's time to add another flag?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 18 22:20:25 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.