data corruption in on Linux/glibc-based systems.

[GoogleCodeExporter]

While trying to decompress and extract files from an apple installer manually 
on linux, I encountered inconsistent behaviors and data corruptions for the 
downstream LZMA decompression. After spending almost a day on it, I found the 
answer with valgrind. Here is the patch:

==========
diff --git a/xar/lib/io.c b/xar/lib/io.c
index 8d2f56e..37d0276 100644
--- a/xar/lib/io.c
+++ b/xar/lib/io.c
@@ -608,7 +608,7 @@ static int32_t flush_stream(xar_stream *stream) {
                        state->pending_buf = NULL;
                } else if( state->pending_buf_size > len ) {
                        state->pending_buf_size -= len;
-                       memcpy(state->pending_buf, state->pending_buf + len, 
state->pending_buf_size);
+                       memmove(state->pending_buf, state->pending_buf + len, 
state->pending_buf_size);
                }
        }

==========

The original code is obviously wrong as memcpy should not be used to copy 
overlapping regions. It is
possible in the above code path if "state->pending_buf_size > len" even after 
-=len .
This depends on the memcpy implementation, and does not seem to affect mac os 
X, but certainly affect Linux/glibc.

Original issue reported on code.google.com by HinTak.L...@gmail.com on 24 Nov 2014 at 7:01