openjpeg/src/lib/openjp2/j2k.c, branch masterFork of openjpeg library for JPEG2000 encoding and decodinghttps://git.carlh.net/cgit/openjpeg/atom?h=master2023-12-08T15:47:34ZMerge pull request #1490 from headshog/fix-j2k2023-12-08T15:47:34ZEven Rouaulteven.rouault@spatialys.com2023-12-08T15:47:34Zurn:sha1:49c4ef56129b85cce8aaad85e9f22f0f3bc16f2e
Integer Overflow at j2k.c:3962Merge pull request #1491 from headshog/fix-j2k-header2023-12-08T15:47:27ZEven Rouaulteven.rouault@spatialys.com2023-12-08T15:47:27Zurn:sha1:00e0bdc14f3feed681de19d46abb2cd8155f3f66
Integer Overflow at j2k.c:11114fix j2k.c:111142023-12-08T14:17:53Zheadshogcraaaaaachind@gmail.com2023-12-06T14:47:02Zurn:sha1:67e6a79bcf6b2ea5503f47954537d14ed37e4a72opj_j2k_merge_ppm(): avoid unsigned-integer-overflow at j2k.c:3962 (#1490)2023-12-08T14:03:54Zheadshogcraaaaaachind@gmail.com2023-12-06T14:30:29Zurn:sha1:a817136f7edbd0e9d9ce46d1faf15506ed9478a0suppress warning during build using clang2023-12-08T11:56:37ZTomoaki Teshimatomoaki.teshima@gmail.com2023-12-08T11:56:37Zurn:sha1:597389a45f63a7cd872859eacb267ea1bda64e9efix: use `opj_uint_ceildiv` instead of `opj_int_ceildiv` when necessary2023-09-23T10:50:57Zmayeutmayeut@users.noreply.github.com2023-09-23T09:02:54Zurn:sha1:d23e0284c9be174cc6daaa594c1139076771e16b
There are a bunch of loc where we can see a usage of `opj_int_ceildiv`:
```
(OPJ_UINT32)opj_int_ceildiv((OPJ_INT32)a, (OPJ_INT32)b);
```
where a & b are `OPJ_UINT32`.
This can lead to overflow/underflow for some a/b combinations.
Replace those calls by `opj_uint_ceildiv` instead to always get a correct result.
This also allows some valid single tile images with huge tile size to be decoded properly.
Fix #1438
Merge pull request #1462 from sebras/master2023-03-09T20:15:39ZEven Rouaulteven.rouault@spatialys.com2023-03-09T20:15:39Zurn:sha1:15c0dca5206d0101de2ce73b97138a2b26949011
CMake: error out on warnings for strict/missing prototypes.CMake: error out on warnings for strict/missing prototypes.2023-03-09T19:09:27ZSebastian Rasmussensebras@gmail.com2023-03-09T18:20:58Zurn:sha1:eb8a7e44279415fdefda6d980b99bd7e00c41da0
And fix strict-prototypes/missing-prototypes warnings.
openjp2/j2k: replace sprintf calls with snprintf2023-03-07T15:47:10ZMark Mentovaimark@chromium.org2022-11-07T14:32:02Zurn:sha1:032b6e93cb38b42c365ebd5296ac08ccf5163feb
This makes it possible to build j2k.c without warnings using the macOS
13 SDK. Calls to sprintf are replaced with snprintf, passing appropriate
buffer sizes.
It doesn’t appear that any of the changed uses of sprintf were actually
unsafe, so no behavior change is expected aside from SDK compatibility.
The macOS 13 SDK deprecates sprintf as it’s difficult to use safely. The
deprecation warning message is visible when building C++, but it is not
normally visible when building plain C code due to a quirk in how
sprintf is declared in the SDK. However, the deprecation message is
visible when building plain C under Address Sanitizer
(-fsanitize=address). This discrepancy was discovered at
https://crbug.com/1381706 and reported to Apple with a copy at
https://openradar.appspot.com/FB11761475.
The macOS 13 SDK is packaged in Xcode 14.1, released on 2022-11-01. This
also affects the iOS 16 SDK and other 2022-era Apple OS SDKs packaged in
Xcode 14.0, released on 2022-09-12.
j2k.c is visible to the Chromium build via PDFium, and this change is
needed to allow Chromium to move forward to the macOS 13 SDK.
This change is limited to src/lib/openjp2. Other uses of sprintf were
found throughout openjpeg.
Cleanup code related to quality layer allocation, and add a few safety checks2022-08-11T16:12:07ZEven Rouaulteven.rouault@spatialys.com2022-08-11T16:06:21Zurn:sha1:c06632c6f6d0a3e106374fe462869b131366c2d0