On 30.10.2010 15:40, Daniel Shahaf wrote:
Daniel Shahaf wrote on Sat, Oct 30, 2010 at 15:09:03 +0200:
[email protected] wrote on Sat, Oct 30, 2010 at 12:09:49 -0000:
Modified:
subversion/branches/performance/subversion/libsvn_subr/svn_string.c
Modified: subversion/branches/performance/subversion/libsvn_subr/svn_string.c
URL:
http://svn.apache.org/viewvc/subversion/branches/performance/subversion/libsvn_subr/svn_string.c?rev=1029038&r1=1029037&r2=1029038&view=diff
==============================================================================
--- subversion/branches/performance/subversion/libsvn_subr/svn_string.c
(original)
+++ subversion/branches/performance/subversion/libsvn_subr/svn_string.c Sat Oct
30 12:09:49 2010
@@ -255,7 +255,13 @@ svn_stringbuf_create_empty(apr_pool_t *p
svn_stringbuf_t *
svn_stringbuf_create_ensure(apr_size_t blocksize, apr_pool_t *pool)
{
- char *data = apr_palloc(pool, ++blocksize); /* + space for '\0' */
+ /* apr_palloc will allocate multiples of 8.
+ * Thus, we would waste some of that memory if we stuck to the
+ * smaller size. Note that this is safe even if apr_palloc would
+ * use some other aligment or none at all. */
+
+ blocksize = APR_ALIGN_DEFAULT(++blocksize); /* + space for '\0' */
+ char *data = apr_palloc(pool, blocksize);
Two issues:
gcc says it more concisely than I did:
subversion/libsvn_subr/svn_string.c: In function
‘svn_stringbuf_create_ensure’:
subversion/libsvn_subr/svn_string.c:263: warning: operation on ‘blocksize’
may be undefined
subversion/libsvn_subr/svn_string.c:264: warning: ISO C90 forbids mixed
declarations and code
Stefan, I don't know if you're doing this already, but could you please
ensure that your changes don't introduce new compiler warnings?
Thanks,
Daniel
(e.g., make -s; svn diff | lsdiff | xargs touch; make -s)
o.k. I now wrote my own filter to cope with the 618 "standard warnings":
#!/bin/sh
(make -j > /dev/null) 2>&1 | grep -v " In function " | grep -v " in
statically " | grep -v " is deprecated " | grep -v "/string3.h:82" |
grep -v "/sem_open.c:330"
Not a beauty but it does its job (grep -E did not).
-- Stefan^2.
