You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@httpd.apache.org by Dean Gaudet <dg...@arctic.org> on 1999/10/13 23:28:29 UTC

Re: cvs commit: apache-2.0/src/lib/apr/lib apr_cpystrn.c

on win32, both / and \ are path separators... no?  (or is this only used
in situations where we've changed / to \ ?)

Dean

On 13 Oct 1999 rbb@hyperreal.org wrote:

>   +
>   +/* Filename_of_pathname returns the final element of the pathname.
>   + * Using the current platform's filename syntax.
>   + *   "/foo/bar/gum" -> "gum"
>   + *   "/foo/bar/gum/" -> ""
>   + *   "gum" -> "gum"
>   + *   "wi\\n32\\stuff" -> "stuff
>   + */
>   +
>   +const char *ap_filename_of_pathname(const char *pathname)
>   +{
>   +#ifdef WIN32
>   +    const char path_separator = '\\';
>   +#else
>   +    const char path_separator = '/';
>   +#endif
>   +    const char *s = strrchr(pathname, path_separator);
>   +
>   +    return s ? ++s : pathname;
>   +}
>   +
>   
>   
>   
>

Re: cvs commit: apache-2.0/src/lib/apr/lib apr_cpystrn.c

Posted by Greg Marr <gr...@alum.wpi.edu>.

At 09:31 PM 10/13/99 , you wrote:
>Dean Gaudet <dg...@arctic.org> writes:
> > on win32, both / and \ are path separators... no?  (or is this 
> only used
> > in situations where we've changed / to \ ?)
>
>I wrote that...
>
>This was distilled out of main, and it's used to get the
>program name off of what every pathname the user invoked
>it with.  Of course now that it's in APR it ought to be
>right.  "Right", presumably meaning, get the last term off
>of the pathname presuming that the pathname is in the
>syntax of the current platform.  VMS ports will suffer
>as they usually do.

const char *ap_filename_of_pathname(const char *pathname)
    {
    #ifdef WIN32
        const char path_separator = '\\';
    #else
        const char path_separator = '/';
    #endif
        const char *s = strrchr(pathname, path_separator);

    }

If you just want to get the filename (with or without extension), the 
windows API provides methods for you to do this.  They operate a 
little differently than this function in that you have to provide 
storage space.  If you're looking for a pointer to the position in 
the passed string where the filename starts, you need to use 
something like this:

    #ifdef WIN32
         const char *f = strrchr(pathname, '\\');
        const char *s = strrchr(pathname, '/');

        if((r == NULL) && (s == NULL))
            return(pathname);

        if(r > s)
            return(r + 1);
        else
            return(s + 1);
    #else
        const char path_separator = '/';
        const char *s = strrchr(pathname, path_separator);

        return s ? ++s : pathname;
    #endif

On the other hand, if the pointer doesn't have to be in the original 
string, (this version isn't thread safe as it uses a static buffer, 
making it so is left as an exercise to the reader) you can use

char szDrive[_MAX_DRIVE], szPath[_MAX_PATH], szFilename[_MAX_PATH], 
szExt[_MAX_EXT];
static char szName[_MAX_PATH];

/* You can pass NULL for any of the last four parameters you don't 
need */
splitpath(pathname, szDrive, szPath, szFilename, szExt);
makepath(szName, NULL, NULL, szFilename, szExt);

return(szName);

This method frees you from handling all the / vs \ problems.

--
Greg Marr
gregm@alum.wpi.edu
"We thought you were dead."
"I was, but I'm better now." - Sheridan, "The Summoning"

apache-2.0/src/lib/apr/lib apr_cpystrn.c

Posted by Henrik Vendelbo <hv...@bluprints.com>.

roll our own cpystrn, makes sense, but what about the inlined (inserted,no function call, expanded by compiler to specialized machinecode) standard string copy functions, they supposedly work much faster.

Do we have any assessment on what difference in apache performance there is. I'm sure that it does a lot of string juggling, but it might not matter.

\Henrik

Re: apr_cpystrn.c

Posted by Henrik Vendelbo <hv...@bluprints.com>.

>Ben wrote :
> The point is that ap_cpystrn doesn't implement anything a standard
> library function does.

Ok, my reminder is then general :

use the ap_cpystrn when you really need it otherwise use the standard
functions which will perform much better.

\Henrik

Re: Sv: apache-2.0/src/lib/apr/lib apr_cpystrn.c

Posted by Ben Laurie <be...@algroup.co.uk>.

Henrik Vendelbo wrote:
> 
> That was not my question, but then in a way it was. I was trying to assess the performance difference between a library string function written C (like ap_cpystrn) and the string copying functions generated by the compiler. The ones generated by the compiler uses (in the iAPX86 case) special string/array machinecode functions which are much faster.
> 
> Now this is of course irrelevant if all string manipulation in apache must use special functions.

The point is that ap_cpystrn doesn't implement anything a standard
library function does.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi

Sv: apache-2.0/src/lib/apr/lib apr_cpystrn.c

Posted by Henrik Vendelbo <hv...@bluprints.com>.

That was not my question, but then in a way it was. I was trying to assess the performance difference between a library string function written C (like ap_cpystrn) and the string copying functions generated by the compiler. The ones generated by the compiler uses (in the iAPX86 case) special string/array machinecode functions which are much faster. 

Now this is of course irrelevant if all string manipulation in apache must use special functions.

----- Original Message ----- 
From: Ryan Bloom <rb...@raleigh.ibm.com>
To: <ne...@apache.org>
Sent: Thursday, October 14, 1999 1:53 PM
Subject: Re: apache-2.0/src/lib/apr/lib apr_cpystrn.c


> 
> If you are asking why we have created our own ap_cpystrn function, please
> read the docs in the apr_cpystrn file.  They cover the reason for
> implementing it ourselves.  If this is not your question, please let me
> know, and I will try to answer what you are actually asking.
> 
> Ryan
> 
> On Thu, 14 Oct 1999, Henrik Vendelbo wrote:
> 
> > roll our own cpystrn, makes sense, but what about the inlined (inserted,no function call, expanded by compiler to specialized machinecode) standard string copy functions, they supposedly work much faster.
> > 
> > Do we have any assessment on what difference in apache performance there is. I'm sure that it does a lot of string juggling, but it might not matter.
> > 
> > \Henrik 
> > 
> 
> _______________________________________________________________________
> Ryan Bloom rbb@raleigh.ibm.com
> 4205 S Miami Blvd 
> RTP, NC 27709 It's a beautiful sight to see good dancers 
> doing simple steps.  It's a painful sight to
> see beginners doing complicated patterns. 
> 
>

Re: apache-2.0/src/lib/apr/lib apr_cpystrn.c

Posted by Ryan Bloom <rb...@raleigh.ibm.com>.

If you are asking why we have created our own ap_cpystrn function, please
read the docs in the apr_cpystrn file.  They cover the reason for
implementing it ourselves.  If this is not your question, please let me
know, and I will try to answer what you are actually asking.

Ryan

On Thu, 14 Oct 1999, Henrik Vendelbo wrote:

> roll our own cpystrn, makes sense, but what about the inlined (inserted,no function call, expanded by compiler to specialized machinecode) standard string copy functions, they supposedly work much faster.
> 
> Do we have any assessment on what difference in apache performance there is. I'm sure that it does a lot of string juggling, but it might not matter.
> 
> \Henrik 
> 

_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.

apache-2.0/src/lib/apr/lib apr_cpystrn.c

Posted by Henrik Vendelbo <hv...@bluprints.com>.

roll our own cpystrn, makes sense, but what about the inlined (inserted,no function call, expanded by compiler to specialized machinecode) standard string copy functions, they supposedly work much faster.

Do we have any assessment on what difference in apache performance there is. I'm sure that it does a lot of string juggling, but it might not matter.

\Henrik