[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: CVS update: subversion/subversion/libsvn_string svn_string.c

From: Greg Stein <gstein_at_lyra.org>
Date: 2000-10-04 00:28:33 CEST

This one probably doesn't make sense. Right after the alloc, we copy over
the oldsize data. I'm not sure that we need the unused portion to be zeroed.
IMO, the add'l space in an svn_string really "shouldn't" need to be zeroed,
but figured it best to ask for other opinions here.

Cheers,
-g

On Tue, Oct 03, 2000 at 09:08:46PM -0000, kfogel@tigris.org wrote:
> User: kfogel
> Date: 00/10/03 14:08:46
>
> Modified: subversion/libsvn_string svn_string.c
> Log:
> Change some calls to apr_palloc() to apr_pcalloc() instead, to get
> zeroed memory. Did this mainly where a structure is being allocated
> and it wasn't clear that all the structure's fields were being
> initialized by the caller, and in a few other places. Obviously, this
> can't break anything, but please feel free to revert in places where
> you know you don't need zeroed memory.
>
> Did not change the NEW(P,T) and NEWARRAY(P,T,N) macros in fs.h, but
> wonder if that might be a good idea...?
>
> Revision Changes Path
> 1.48 +1 -1 subversion/subversion/libsvn_string/svn_string.c
>
> Index: svn_string.c
> ===================================================================
> RCS file: /cvs/subversion/subversion/libsvn_string/svn_string.c,v
> retrieving revision 1.47
> retrieving revision 1.48
> diff -u -r1.47 -r1.48
> --- svn_string.c 2000/10/02 18:29:04 1.47
> +++ svn_string.c 2000/10/03 21:08:46 1.48
> @@ -70,7 +70,7 @@
> already. */
>
> /* malloc new area */
> - new_area = apr_palloc (pool, request);
> + new_area = apr_pcalloc (pool, request);
>
> /* copy data to new area */
> memcpy (new_area, data, oldsize);
>
>
>

-- 
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:10 2006

This is an archived mail posted to the Subversion Dev mailing list.