Add support for padding in the Snappy framed format.

This is specifically motivated by DICOM's demands that embedded data
must be of an even number of bytes, but could in principle be used for
any sort of padding/alignment needed.

R=sanjay


git-svn-id: https://snappy.googlecode.com/svn/trunk@82 03e5f5b5-db94-4691-08a0-1a8bf15f6143

framing_format.txt

@@ -1,5 +1,5 @@
 Snappy framing format description
-Last revised: 2013-01-05
+Last revised: 2013-10-25
 
 This format decribes a framing format for Snappy, allowing compressing to
 files or streams that can then more easily be decompressed without having
@@ -106,7 +106,18 @@ no more than 65536 data bytes, so the maximum legal chunk length with the
 checksum is 65540.
 
 
-4.4. Reserved unskippable chunks (chunk types 0x02-0x7f)
+4.4. Padding (chunk type 0xfe)
+
+Padding chunks allow a compressor to increase the size of the data stream
+so that it complies with external demands, e.g. that the total number of
+bytes is a multiple of some value.
+
+All bytes of the padding chunk, except the chunk byte itself and the length,
+should be zero, but decompressors must not try to interpret or verify the
+padding data in any way.
+
+
+4.5. Reserved unskippable chunks (chunk types 0x02-0x7f)
 
 These are reserved for future expansion. A decoder that sees such a chunk
 should immediately return an error, as it must assume it cannot decode the
@@ -115,10 +126,10 @@ stream correctly.
 Future versions of this specification may define meanings for these chunks.
 
 
-4.5. Reserved skippable chunks (chunk types 0x80-0xfe)
+4.6. Reserved skippable chunks (chunk types 0x80-0xfd)
 
 These are also reserved for future expansion, but unlike the chunks
-described in 4.4, a decoder seeing these must skip them and continue
+described in 4.5, a decoder seeing these must skip them and continue
 decoding.
 
 Future versions of this specification may define meanings for these chunks.