MaxEncodedLen returns the maximum length of a snappy block, given its uncompressed length. It will return a negative value if srcLen is too large to encode.
(srcLen int)
| 76 | // |
| 77 | // It will return a negative value if srcLen is too large to encode. |
| 78 | func MaxEncodedLen(srcLen int) int { |
| 79 | n := uint64(srcLen) |
| 80 | if n > 0xffffffff { |
| 81 | return -1 |
| 82 | } |
| 83 | // Compressed data can be defined as: |
| 84 | // compressed := item* literal* |
| 85 | // item := literal* copy |
| 86 | // |
| 87 | // The trailing literal sequence has a space blowup of at most 62/60 |
| 88 | // since a literal of length 60 needs one tag byte + one extra byte |
| 89 | // for length information. |
| 90 | // |
| 91 | // Item blowup is trickier to measure. Suppose the "copy" op copies |
| 92 | // 4 bytes of data. Because of a special check in the encoding code, |
| 93 | // we produce a 4-byte copy only if the offset is < 65536. Therefore |
| 94 | // the copy op takes 3 bytes to encode, and this type of item leads |
| 95 | // to at most the 62/60 blowup for representing literals. |
| 96 | // |
| 97 | // Suppose the "copy" op copies 5 bytes of data. If the offset is big |
| 98 | // enough, it will take 5 bytes to encode the copy op. Therefore the |
| 99 | // worst case here is a one-byte literal followed by a five-byte copy. |
| 100 | // That is, 6 bytes of input turn into 7 bytes of "compressed" data. |
| 101 | // |
| 102 | // This last factor dominates the blowup, so the final estimate is: |
| 103 | n = 32 + n + n/6 |
| 104 | if n > 0xffffffff { |
| 105 | return -1 |
| 106 | } |
| 107 | return int(n) |
| 108 | } |
| 109 | |
| 110 | var errClosed = errors.New("snappy: Writer is closed") |
| 111 |
no outgoing calls
searching dependent graphs…