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:
snappy.mirrorbot@gmail.com 2011-08-10 01:14:43 +00:00
parent 57e7cd7255
commit 59aeffa604
1 changed files with 3 additions and 3 deletions

View File

@ -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