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!