diff options
author | Ray Johnston <ray.johnston@artifex.com> | 2006-04-22 01:59:07 +0000 |
---|---|---|
committer | Ray Johnston <ray.johnston@artifex.com> | 2006-04-22 01:59:07 +0000 |
commit | e92d63ceaaac85514133bf678fbf2d666432a658 (patch) | |
tree | 7d44769a6bc74e38faacbd30313db176501eaae2 /gs/src/sa85d.c | |
parent | eb65dcef2ba488a07858dc1d9937feb220627a0d (diff) |
Change ASCII85Decode EOD handling to make sure that the EOD characters are
consumed before we provide the last bit of data to the caller. The ~> sequence
(actually could be <cr> <lf> ~ <cr> <lf> > ) left in the currentfile would
cause an /undefined error. Bug 688618.
DETAILS:
When the input is piped from %stdin the smaller buffers tripped over this
frequently with the test file simply because there were more buffer bounds
conditions.
Note that this area is _still_ not quite the way Adobe works, but without
major surgery and analysis of Adobe filter behaviour we aren't likely to
achieve 100% compatiblity.
Since we handle the case where the EOD sequence is in the part of the buffer
that we defer processing on (if last is false) we should be quite similar
as far as when we process the EOD since if a complete EOD wasn't in the
buffer previously, the '~' was left there. Now we avoid returning the last
word of data if the complete EOD isn't in the tail of the buffer.
If the EOD sequence seen in the tail is preceded by the 'real' EOD before
the tail in the current buffer, the "false positive" does no harm. Similarly
if there is a malformed EOD '~' not followed by '>' (possibly with intervening
<cr><lf>) the error condition will still be detected when the '~' is actually
parsed in the deocder.
EXPECTED DIFFRENCES:
None. The regression suite still runs fine for me, including FTS files that
use the ASCII85Decode filter such as 119-01.ps.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@6714 a1074d23-0009-0410-80fe-cf8c14f379e6
Diffstat (limited to 'gs/src/sa85d.c')
-rw-r--r-- | gs/src/sa85d.c | 20 |
1 files changed, 19 insertions, 1 deletions
diff --git a/gs/src/sa85d.c b/gs/src/sa85d.c index a63357f28..6efc52e42 100644 --- a/gs/src/sa85d.c +++ b/gs/src/sa85d.c @@ -40,12 +40,29 @@ s_A85D_process(stream_state * st, stream_cursor_read * pr, stream_A85D_state *const ss = (stream_A85D_state *) st; register const byte *p = pr->ptr; register byte *q = pw->ptr; - const byte *rlimit = pr->limit; + /* stop processing early unless the target is empty (last == true) */ + /* to make sure we consume the EOD marker correctly. The EOD marker */ + /* might be as many as 6 characters after the last valid data char */ + /* D <cr> <lf> '~' <cr> <lf> '>' where 'D' is a data character. */ + const byte *rlimit = pr->limit - (last ? 0 : 7); /* max EOD len + 1 */ + const byte *r = rlimit; byte *wlimit = pw->limit; int ccount = ss->odd; ulong word = ss->word; int status = 0; + /* scan to make sure that an EOD isn't fully contained in the */ + /* last part of the buffer (between rlimit and pr->limit). */ + while (r < pr->limit) { + if (*++r == '~') + while (r < pr->limit) + if (*++r == '>') { + /* we have both characters of a complete EOD. */ + rlimit = pr->limit; /* go ahead and process everything */ + r = rlimit; /* break out of the while loops */ + break; + } + } while (p < rlimit) { int ch = *++p; uint ccode = ch - '!'; @@ -91,6 +108,7 @@ s_A85D_process(stream_state * st, stream_cursor_read * pr, else if (ch == '~') { int i = 1; + rlimit = pr->limit; /* Here we use the real "limit" */ /* Handle odd bytes. */ if (p == rlimit) { if (last) |