Doug MacEachern wrote:
>ap_os_escape_path currently requires a pool argument to allocate the
>string and does a strlen on it. wondering if we could do something like
>the concept patch below, adding ap_os_escape_pathn which does not require
>a pool and the path arg would be assumed to be allocated to the correct
>size. would be a nice optimzation for perl land where string lengths are
>always known and where the current ap_os_escape_path requires two copies,
>the pool alloc and perl dup of the returned string. with something like
>ap_os_escape_pathn we can avoid the strlen and the additional pool alloc.
>could be useful elsewhere too i'm sure.
>
>Index: server/util.c
>===================================================================
>RCS file: /home/cvs/httpd-2.0/server/util.c,v
>retrieving revision 1.128
>diff -u -r1.128 util.c
>--- server/util.c 17 May 2002 11:11:37 -0000 1.128
>+++ server/util.c 24 May 2002 16:33:40 -0000
>@@ -1632,6 +1632,12 @@
> AP_DECLARE(char *) ap_os_escape_path(apr_pool_t *p, const char *path, int partial)
> {
> char *copy = apr_palloc(p, 3 * strlen(path) + 3);
>+ return ap_os_escape_pathn(copy, partial);
>
Shouldn't that apr_palloc() now be an apr_pstrdup(), so that
apr_os_escape_pathn
doesn't have to work on an uninitialized buffer?
Other than that, +1 on the concept.
--Brian
