apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [patch] apr_pathinfo()
Date Thu, 02 Aug 2001 00:23:35 GMT
I'd be happy to take a look at this, thank you.  The implementation as it were
is already in need of some refactoring for 'real life' uses, and Apache's own
directory_walk and a few remaining ap_foo functions needed to be depricated.
This should help.

----- Original Message ----- 
From: "Sterling Hughes" <sterling@designmultimedia.com>
To: <dev@apr.apache.org>
Sent: Wednesday, August 01, 2001 6:00 AM
Subject: [patch] apr_pathinfo()


>     Hi,
> 
>     I've recently needed functionality to portably analyze the different
>     parts of an OS path (ie, /home/foo.com/www/test.xml), therefore,
>     I've written the following function, loosely based on
>     apr_filename_from_pathname() which returns the information on a OS path
>     into a structure (the name of the file, the directory path, and the
>     file ending).
> 
>     Attached is a patch which removes the apr_filename_from_pathname()
>     function, and adds the apr_pathinfo() function.  I've split the
>     apr_pathinfo() function into a seperate file (apr_path.c) simply
>     because apr_cpystrn.c (where apr_filename_from_pathname() was
>     implemented) just didn't seem to be the proper place to put the
>     function.  Actually, not to start another thread, but.. there
>     doesn't really seem to be a standard file to put some assorted
>     string functions in (like apr_strlib.c or something).
> 
>     Another note is that these functions take a pool to allocate memory,
>     historically these type of functions don't behave like this (dirname()
>     and basename() for example).  But, I've found (personally) that it
>     leads to some annoying errors, therefore each portion of the string
>     that is extracted is duplicated.  I don't anticipate this being a
>     huge deal, mainly because at most you're copying a couple of characters
>     (*duck*).
> 
>     -Sterling
> 
>     Ps: The path splitting functionality is not at all equivalent to
>     dirname() or basename(), I think it makes sense this way, however,
>     if people really want, I can make it dirname() and basename()
>     compliant.
> 
>     Pps: Again sorry the patch is a bit big ;)
> 


Mime
View raw message