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

Re: svn commit: r13063 - trunk/subversion/libsvn_fs_base

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2005-02-26 00:22:41 CET

Branko ÄŒibej <brane@xbc.nu> writes:

> kfogel@collab.net wrote:
>
>>brane@tigris.org writes:
>>
>>
>>>Log:
>>>Expand self-compressed deltas in BDB before combining. This is similar
>>>to the r13016 change in FSFS. It doesn't improve performance much by
>>>itself now that we use xdelta instead of vdelta in most cases, but
>>>opens the door for storing self-compressed deltas instead of fulltexts
>>>in BDB in the future.
>>>
>>>* subversion/libsvn_fs_base/reps-strings.c (compose_handler_baton):
>>> New member source_buf.
>>> (compose_handler): Expand self-compressed windows into source_buf.
>>> (rep_undeltify_range): Use the expanded fulltext provided by the
>>> combiner if available.
>>>
>>>
>>>--- trunk/subversion/libsvn_fs_base/reps-strings.c (original)
>>>+++ trunk/subversion/libsvn_fs_base/reps-strings.c Sat Feb 19 06:06:16 2005
>>>@@ -150,6 +150,11 @@
>>> svn_txdelta_window_t *window;
>>> apr_pool_t *window_pool;
>>> + /* If the incoming window was self-compressed, and the combined
>>> WINDOW
>>>+ exists from previous iterations, SOURCE_BUF will point to the
>>>+ expanded self-compressed window. */
>>>+ char *source_buf;
>>>+
>>> /* The trail for this operation. WINDOW_POOL will be a child of
>>> TRAIL->pool. No allocations will be made from TRAIL->pool itself. */
>>> trail_t *trail;
>>>
>>>
>>
>>Here source_buf is declared as 'char *', but...
>>
>>
>>
>>>@@ -331,8 +364,7 @@
>>> }
>>> else
>>> {
>>>- static char empty_buf[] = "";
>>>- source_buf = empty_buf; /* Won't read anything from here. */
>>>+ source_buf = ""; /* Won't read anything from here. */
>>> }
>>> if (offset > 0)
>>>
>>>
>>
>>...here it is the assignee of a 'const char *' value, thus causing a
>>compiler warning.
>>
>>
> String literals have type "char*" in C, not "const char*". The warning
> (turned on by -Wwrite-strings, IIRC) is possibly too much of a good
> think in this case.

However the "char*" type is a wart for backwards compatibility; string
literals should be treated as const, modifying one through a "char*"
pointer invokes undefined behaviour.

>>Ordinarily, I wouldn't just cast over the situation, because of
>>writeable string concerns. But in this case, I cast it in 13159 in
>>the obvious way
>>
>> source_buf = (char *) "";
>>
>>because it looks like source_buf[0] would never be overwritten after
>>that point. If this was wrong, please let me know.
>>
>>
> This cast is safe. But I'd rather put in the original code instead.

How about something like this, no cast and no warnings:

Index: subversion/libsvn_fs_base/reps-strings.c
===================================================================
--- subversion/libsvn_fs_base/reps-strings.c (revision 13157)
+++ subversion/libsvn_fs_base/reps-strings.c (working copy)
@@ -324,7 +324,8 @@
   do
     {
       struct compose_handler_baton cb = { 0 };
- char *source_buf, *target_buf;
+ const char *source_buf;
+ char *target_buf;
       apr_size_t target_len;
       int cur_rep;
 
@@ -356,11 +357,13 @@
       else if (fulltext && cb.window->sview_len > 0 && cb.window->src_ops > 0)
         {
           apr_size_t source_len = cb.window->sview_len;
- source_buf = apr_palloc (cb.window_pool, source_len);
+ char *source_buf_tmp = apr_palloc (cb.window_pool, source_len);
           SVN_ERR (svn_fs_bdb__string_read
                    (fs, fulltext->contents.fulltext.string_key,
- source_buf, cb.window->sview_offset, &source_len, trail));
+ source_buf_tmp, cb.window->sview_offset, &source_len,
+ trail));
           assert (source_len == cb.window->sview_len);
+ source_buf = source_buf_tmp;
         }
       else
         {

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 26 00:24:06 2005

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.