This was changed some time ago (https://google.github.io/oss-fuzz/getting-started/new-project-guide/) but the build didn't fail as there is a fallback mechanism. The main advantage of the new approach is that for libFuzzer this produces more performant binaries (as `$LIB_FUZZING_ENGINE` expands into `-fsanitize=fuzzer`, which links libFuzzer from the compiler-rt, allowing better optimization tricks).
I'm also experimenting with dataflow (https://github.com/google/oss-fuzz/issues/1632) on your project, and the dataflow config doesn't have a fallback (as it's a new configuration), therefore I'm proposing a change to migrate from `-lFuzzingEngine` to `$LIB_FUZZING_ENGINE`.
This adds a opj_set_decoded_components(opj_codec_t *p_codec,
OPJ_UINT32 numcomps, const OPJ_UINT32* comps_indices) function,
and equivalent "opj_decompress -c compno[,compno]*" option.
When specified, neither the MCT transform nor JP2 channel transformations
will be applied.
Tests added for various combinations of whole image vs tiled-based decoding,
full or reduced resolution, use of decode area or not.
* Only works for single-tiled images --> will error out cleanly, as currently
in other cases
* Save re-reading the codestream for the tile, and re-use code-blocks of the
previous decoding pass.
* Future improvements might involve improving opj_decompress, and the image writing logic,
to use this strategy.
PR #975 introduced a check that rejects images that have different bit depth/sign
per compoment in SIZ marker if the JP2 IHDR box has BPC != 255
This didn't work properly if decoding a .j2k file since the new bit added in
opj_cp_t wasn't initialized to the right value.
For clarity, tThis new bit has also been renamed to allow_different_bit_depth_sign
But looking closer at the code, it seems we were already tolerant to inconsistencies.
For example we parsed a JP2 BPCC box even if BPC != 255 (just a warning is emitted)
So failing hard in opj_j2k_read_siz() wouldn't be very inconsistent, and that
alone cannot protect against other issues, so just emit a warning if BPC != 255
and the SIZ marker contains different bit depth/sign per component.
Note: we could also check that the content of JP2 BPCC box is consistant with the one
of the SIZ marker.
There are situations where, given a tile size, at a resolution level,
there are sub-bands with x0==x1 or y0==y1, that consequently don't have any
valid codeblocks, but the other sub-bands may be non-empty.
Given that we recycle the memory from one tile to another one, those
ghost codeblocks might be non-0 and thus candidate for packet inclusion.
* test_tile_decoder: Fix potential buffer overflow (coverity)
CID 1190155 (#1 of 1): Unbounded source buffer (STRING_SIZE)
Using a pointer instead of buffer of fixed size avoids the limit
for the length of the input file name.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
* test_tile_encoder: Fix potential buffer overflow (coverity)
CID 1190154 (#1 of 1): Unbounded source buffer (STRING_SIZE)
Using a pointer instead of buffer of fixed size avoids the limit
for the length of the output file name. This implies that the length
can exceed 255, so the data type for variable len had to be fixed, too.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
* openjpip: Initialize data before returning it
This fixes an error reported by Coverity:
CID 1190143 (#1 of 1): Uninitialized scalar variable (UNINIT)
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Fix issue 135
The fix is legal regarding the standard but I did not manage to find out if it covers a bug in opj_t2_read_packet_data or if the file is corrupted
Even Rouault
Max Moroz
Matthieu Darbois
Stefan Weil
Julien Malik
Antonin Descampe