Upgrade bundled snappy to version 1.0.4.

[apitrace] / thirdparty / snappy / format_description.txt

diff --git a/thirdparty/snappy/format_description.txt b/thirdparty/snappy/format_description.txt
index 943bfc212f8d9b53b58c7665fa715727d9cc2740..43d7a98238c4b3518fd63c6fc9291a4d41493e16 100644 (file)
--- a/thirdparty/snappy/format_description.txt
+++ b/thirdparty/snappy/format_description.txt
@@ -1,5 +1,5 @@
 Snappy compressed format description
-Last revised: 2011-05-16
+Last revised: 2011-08-09
 
 
 This is not a formal specification, but should suffice to explain most
@@ -38,7 +38,7 @@ follow:
   00: Literal
   01: Copy with 1-byte offset
   10: Copy with 2-byte offset
-  11: Copy with 3-byte offset
+  11: Copy with 4-byte offset
 
 The interpretation of the upper six bits are element-dependent.
 
@@ -52,7 +52,7 @@ of the literal:
  - For literals up to and including 60 bytes in length, the upper
    six bits of the tag byte contain (len-1). The literal follows
    immediately thereafter in the bytestream.
- - For longer literals, the length is stored after the tag byte,
+ - For longer literals, the (len-1) value is stored after the tag byte,
    little-endian. The upper six bits of the tag byte describe how
    many bytes are used for the length; 60, 61, 62 or 63 for
    1-4 bytes, respectively. The literal itself follows after the
@@ -103,7 +103,7 @@ six bits ([2..7]) of the tag byte. The offset is stored as a
 little-endian 16-bit integer in the two bytes following the tag byte.
 
 
-2.2.3. Copy with 4-byte offsets (11)
+2.2.3. Copy with 4-byte offset (11)
 
 These are like the copies with 2-byte offsets (see previous subsection),
 except that the offset is stored as a 32-bit integer instead of a