summaryrefslogtreecommitdiff
path: root/core/fpdfapi/parser
diff options
context:
space:
mode:
authorNicolas Pena <npm@chromium.org>2017-10-25 16:51:20 -0400
committerChromium commit bot <commit-bot@chromium.org>2017-10-25 21:16:37 +0000
commit5614d119e91264c428396f9eb84afea866011fca (patch)
tree88e45227c892170ccde55088960b1575e505f092 /core/fpdfapi/parser
parent96ef1dd84d1d288f7eeb05ce97d19871e912bf64 (diff)
downloadpdfium-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 'core/fpdfapi/parser')
0 files changed, 0 insertions, 0 deletions