diff options
author | Nicolas Pena <npm@chromium.org> | 2017-10-25 16:51:20 -0400 |
---|---|---|
committer | Chromium commit bot <commit-bot@chromium.org> | 2017-10-25 21:16:37 +0000 |
commit | 5614d119e91264c428396f9eb84afea866011fca (patch) | |
tree | 88e45227c892170ccde55088960b1575e505f092 /BUILD.gn | |
parent | 96ef1dd84d1d288f7eeb05ce97d19871e912bf64 (diff) | |
download | pdfium-5614d119e91264c428396f9eb84afea866011fca.tar.xz |
Enforce end of data in CJBig2_ArithDecoder
Quoting the JBIG2 spec: "If B is a 0xFF byte, then B1 (the byte pointed
to by BP+1) is tested. If B1 exceeds 0x8F, then B1 must be one of the
marker codes. The marker code is interpreted as required, and the buffer
pointer remains pointed to the 0xFF prefix of the marker code which
terminates the arithmetically compressed data. 1-bits are then fed to
the decoder until the decoding is complete. This is shown by adding
0xFF00 to the C-register and setting the bit counter CT to 8."
Our implementation is the alternative (faster for software according to
the spec), where only CT is changed to 8.
Reaching this part of the code means we will never read from stream
again so we should be wrapping up the decoding. To ensure this, the
|m_Complete| attribute is set to true if we reach this code again,
which will result in bailing out next time DECODE is called.
Bug: 767156
Change-Id: I434d46bc7914713a065f0e4da079bbc9b5dd216c
Reviewed-on: https://pdfium-review.googlesource.com/16791
Reviewed-by: dsinclair <dsinclair@chromium.org>
Commit-Queue: Nicolás Peña Moreno <npm@chromium.org>
Diffstat (limited to 'BUILD.gn')
0 files changed, 0 insertions, 0 deletions