You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Arsen Chaloyan <ac...@yahoo.com> on 2010/03/30 10:37:02 UTC

Uninitialized 1 byte copy in apr_filepath_merge()

Hi,

One small and pretty harmless, but still issue in the implementation of apr_filepath_merge() for win32.

Wouldn't it be better to use apr_pstrmemdup() instead of apr_pmemdup() to avoid initialized 1 byte copy. At least, this allows to silence UMC errors memory profilers complain about.

Index: file_io/win32/filepath.c
===================================================================
--- file_io/win32/filepath.c    (revision 929036)
+++ file_io/win32/filepath.c    (working copy)
@@ -949,8 +949,7 @@
         }
     }
 
-    *newpath = apr_pmemdup(p, path, pathlen + 1);
-    (*newpath)[pathlen] = '\0';
+    *newpath = apr_pstrmemdup(p, path, pathlen);
     return APR_SUCCESS;
 }
 
Regards,
Arsen

Re: Uninitialized 1 byte copy in apr_filepath_merge()

Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Mar 30, 2010 at 4:37 AM, Arsen Chaloyan <ac...@yahoo.com> wrote:
> Hi,
>
> One small and pretty harmless, but still issue in the implementation of
> apr_filepath_merge() for win32.
>
> Wouldn't it be better to use apr_pstrmemdup() instead of apr_pmemdup() to
> avoid initialized 1 byte copy. At least, this allows to silence UMC errors
> memory profilers complain about.
>
> Index: file_io/win32/filepath.c
> ===================================================================

committed to trunk as r932067; I'll commit to 1.5.x and 1.4.x branches
if there are no complaints

thanks!