| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When cross-compiling jbig2dec like so:
./configure --host=i686-w64-mingw32 --disable-static && make clean && make
... you get linker errors about multiple definintions of llabs, lltoa, etc.
The reason for this is that the inline keyword has been redfined to the empty
string. After that has been done in jbig2.h it includes jbig2_priv.h which
includes memento.h which includes stdlib.h. The inline redefinition causes
all declarations in stdlib.h to then be done without inline causing the
functions to be present at least twice in in the set of object files.
The redefine was introduced in commit cb456c92a550e1af70a4e268b2f5b02f2df5b8c6
Since jbig2.h is jbig2dec's public header this would affect any program that
includes jbig2.h and then includes system-wide headers after that.
This commit circumvents the issue by moving the inline redefine from the end
of the public jbig2.h header to later in the internal jbig2_priv.h header,
immediately after memento.h has been included. This way the redefine still
affects any jbig2dec internal source code, but not any users of jbig2dec.
|
| | |
|
| |
|
|
|
|
|
|
| |
When jbig2_image_compose() errors out, remember to release all allocated
pattern images. Previously the most recently allocated image would not
be release.
Finally remember to free the array of images itself.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When searching for markers in a stream buffer, we were "seeking" to the point
in the buffer, and casting to either a byte, ushort or a uint to make the
value comparison. But we cannot do that on SPARC because of the strict
alignment on that hardware.
So, we have to "unpack" the individual bytes from the stream to do the value
comparison.
Note: there are slightly confusing comments in the code that mention being
"on a 16 bit boundary" and "on a 32 bit boundary" - that's referring to the
offset into the buffer, *not* the actual memory address alignment.
Found in testing on Solaris/SPARC
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
context.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before commit 2b2dcf4ccf401ed210f03c858b304994749fd2b3 there was
a debug message when attempting to parse a a segment header and
the data supplied to jbig2dec was not enough. Commit 2b2dcf4
incorrectly changed the debug message into a fatal error message,
due misinterpreting the message text as something that warranted
a fatal error.
When data was supplied in chunks to jbig2_data_in() in repeated
calls such that a segment header's referred-to segment numbers
field straddled a chunk boundary then jbig2dec would indicate a
fatal error. The file in bug 702335 caused this to happen.
Instead jbig2dec should be asking the caller for more data so
that the entire segment header can be parsed during a single call
to jbig2_data_in().
By convering the fatal error back to a a debug message the problem
is resolved. The message itself is also rewored to clearly
indicate that the situation is non-fatal and that the caller will
be asked to provide more data.
|
| | |
|
| |
|
|
|
|
|
| |
Fixes OSS-fuzz issue 21571.
Also fixes Coverity CID 355467.
Thanks to OSS-fuzz for reporting.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MMR decoder pre-buffers up to 32 bits of encoded input data in a word
buffer before they are consumed by the MMR decoder. Once bits are consumed, the
pre-buffer will be filled up with more input data. When filling up the buffer
the decoder would previously stay clear of reading data belonging to succeeding
segments, but still indicated that it consumed those bytes it never read. Once
finished the MMR decoder lied to the caller by propagating the incorrect number
of consumed bytes. The caller subtracted the consumed number of bytes from the
size and end up in underflow causing the next MMR decoding to first read input
data at the wrong location, later ending up attempting to read outside the MMR
encoded input buffer.
Now, the MMR decoder keeps track of how many bits it has consumed and
accurately rounds this number up to a whole number of bytes to the caller.
Fixes OSS-fuzz issue 17855.
Thanks to OSS-fuzz for reporting.
|
| |
|
|
|
|
| |
Fixes OSS-Fuzz issue 17513.
Thanks to OSS-fuzz for reporting.
|
| | |
|
| |
|
|
| |
Fixes Coverity CID 355175.
|
| |
|
|
|
|
|
|
|
|
| |
Previously the number of remaining bytes in a read word (>= 0) and the error
state (< 0) was stored in the same int field. Fixing signedness conversion
warnings changed the type of the field to an unsigned field. The error state
should have been stored separately at that time but it was overlooked. In this
commit the error state is separated out into its own field.
Fixes Coverity CID 355176.
|
| |
|
|
| |
Fixes Coverity CID 355177.
|
| |
|
|
|
|
|
|
|
| |
While working to fix all warnings seen when -Wsign-conversion is
enabled, these two warnings were accidentally introduced by commit
ff53af0d4ff9291aa5039522f5553a2850dd569d and not noticed in the
avalanche of warnings emitted due to -Wsign-conversion. This commit
changes the indicies to the type of the limit variable, fixing the
warnings.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
According to the JBIG2 specification segments numbers are 32 bit unsigned
integer. Previously any segment numbers larger than INT32_MAX would be passed
as negative numbers.
Some parts of the decoder do not yet know, or do not have access to the
currently decoded segment number, and this needs to be specially indicated.
Therefore jbig2dec appropriates the unlikely segment number 0xffffffff to
indicate an unknown segment number.
This is a change of the public API.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The previous detection logic caused GCC's -Wlogical-op to trip.
Not only that, but the detection logic never took into account
that underflow is not possible (the worst case is V == INT32_MIN,
but offset is always > 0, so underflow cannot happen), nor take
varying offset values into account (hardcoded limits meant that
the offset was ignored even if it could not cause an overflow),
but instead could cause non-clamped values to be emitted.
This corrected logic adheres to the Annex A. Table A.1 in the specification.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 7366747076f3b75def52079bd4d5021539a16394 fixes bug 694949 by
adding an artificial limit (that does not come from the JBIG2
specification) to the sizes of generic regions compared with the image
they will be composed onto. A problem with such artificial limits is
that they are arbitrary. This is exemplified by the changes in
0d21a58ab12b9584faa54baa48ce0dab350af53e to make jbig2dec not error
out on commonly occurring images. It is impossible to know whether
this updated limit is enough, or whether an even large generic region
in a JBIG2 image will be found in the future.
Instead of imposing these kinds of limits, jbig2dec should attempt to
decode any JBIG2 image given to it. If the user wants to limit the
amount of memory jbig2dec may use for decoding any JBIG2 image, this
is a better way of implicitly limiting image sizes.
|
| |
|
|
|
|
|
|
| |
* Treat reading beyond end of stream in arithmetic decoder as a fatal error.
* Remember previously encountered stream errors in arithmetic decoder.
* Ignore trailing bytes after terminating marker code in stream.
|
| | |
|
| |
|
|
|
|
| |
When a called function indicates an error, the caller should print warnings.
Since the arithmetic decoder now uses the normal way of reporting errors,
the callers of the decoder are changed to report warnings.
|
| |
|
|
|
|
|
|
|
| |
Previously SYMWIDTH was capped too early in order to prevent underflow
Moreover TOTWIDTH was allowed to overflow.
Now the value DW is checked compared to SYMWIDTH, preventing over
underflow and overflow at the correct limits, and an overflow
check has been added for TOTWIDTH.
|
| |
|
|
|
| |
Also move UINT32_MAX/INT32_MAX to internal header so they are defined
(the same) in every jbig2 source code file.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
