On Friday, February 26, 2016 at 10:04:57 PM UTC+1, Bryan Matsuo wrote:

On Friday, February 26, 2016 at 12:56:35 PM UTC-8, Ian Lance Taylor wrote:

The copy function will handle overlapping slices correctly. It's
equivalent to memmove, not memcpy.
The memmove semantics are not correct *for this case*. The manpage for
memmove says "copying takes place as though the bytes in src are first
copied into a temporary array that does not overlap src or dest, and the
bytes are copied from the temporary array to dest." I understand that is
typically desirable. But that is exactly what you do *not* want to happen
during snappy decoding. Forgive my ignorance not really knowing the
technical terms, but the following is lifted from the snappy specification
(section 2.2).

As in most LZ77-based compressors, the length can be larger than the
yielding a form of run-length encoding (RLE). For instance,
"xababab" could be encoded as
<literal: "xab"> <copy: offset=2 length=4>
Thanks, I was aware of how LZ-based pattern matching works and this
specific trick as well, but I got confused thinking that copy() (aka
memmove) could handle that. Your quote from the manpage is very clear.

I prepared a version that calls copy() in a loop, using the longest
available sequence each time:

I guess it's the best you can do in pure Go.


You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 8 of 23 | next ›
Discussion Overview
groupgolang-dev @
postedFeb 26, '16 at 7:36a
activeApr 24, '16 at 12:39a



site design / logo © 2021 Grokbase