mirror of https://github.com/google/snappy.git
Fix public issue #46: Format description said "3-byte offset"
instead of "4-byte offset" for the longest copies. Also fix an inconsistency in the heading for section 2.2.3. Both patches by Patrick Pelletier. R=csilvers git-svn-id: https://snappy.googlecode.com/svn/trunk@45 03e5f5b5-db94-4691-08a0-1a8bf15f6143
This commit is contained in:
parent
57e7cd7255
commit
59aeffa604
|
@ -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.
|
||||
|
||||
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue