kc3-lang/libjpeg-turbo

Log

Author Commit Date CI Message
DRC 7bb5cb56 2022-12-07T09:39:03 ChangeLog.md: List CVE ID fixed by f35fd27e
DRC 7f2eb09d 2022-11-30T18:16:14 BUILDING.md: Add Arm64 iOS sim build instructions Unfortunately, iOS builds cannot be used with the iOS simulator on Macs with Apple silicon CPUs. Even more unfortunately, universal binaries can only have one slice for each CPU architecture, so it would not be possible to add a dedicated Arm64 iOS simulator slice to the existing libjpeg-turbo iOS binaries. (It would be necessary to release a separate package solely for the iOS simulator.) Because the Arm Neon SIMD extensions for libjpeg-turbo now use compiler intrinsics when building with Xcode, it is easy to build libjpeg-turbo from source when targeting Arm64-based Apple platforms. Thus, for the moment, I have chosen to document how to avoid the pothole rather than to fill it in.
DRC 403cfad6 2022-11-30T10:43:29 djpeg.c: Fix build if !SAVE_MARKERS_SUPPORTED
DRC c4105ba7 2022-11-30T10:40:48 turbojpeg.c: Fix build if !C_PROGRESSIVE_SUPPORTED
DRC 45cd2ded 2022-11-28T21:02:42 12-bit: Prevent RGB-to-YCC table overrun/underrun cjpeg relies on the various file I/O modules to range-limit the input samples, but no range limiting is performed by the jpeg_write_scanlines() function itself. With 8-bit samples, that isn't a problem, because sample values > MAXJSAMPLE will overflow the data type and wrap around to 0. With 12-bit samples, however, it is possible to pass sample values < 0 or > 4095 to jpeg_write_scanlines(), which would cause the RGB-to-YCbCr color converter to underflow or overflow the RGB-to-YCbCr conversion tables. That issue has existed in libjpeg all along. This commit mitigates the issue by masking off all but the lowest 12 bits of each 12-bit input sample prior to using the input sample value to index the RGB-to-YCbCr conversion tables. Fixes #633
DRC 74d5b168 2022-11-21T22:41:46 Build: Update tjtest target dependencies
DRC eb1fd4ad 2022-11-15T23:38:19 Build: Fix typo in tjtest target
Erin Melucci 37dd973b 2022-11-02T09:33:55 Win: Use wchar_t for copyright string in RC files llvm-rc doesn't like the copyright symbol in the LegalCopyright string. Possible solutions: 1. Replace the copyright symbol with "(C)". 2. Prefix the string literal with L, thus making it a wide character string. 3. Pass -c65001 to the resource compiler to enable the UTF-8 code page. Option 2 is the least disruptive, since it doesn't change the behavior of the official builds or require any build system modifications. Closes #627
DRC 78a36f6d 2022-11-15T17:01:17 Fix buffer overrun in 12-bit prog Huffman encoder Regression introduced by 16bd984557fa2c490be0b9665e2ea0d4274528a8 and 5b177b3cab5cfb661256c1e74df160158ec6c34e The pre-computed absolute values used in encode_mcu_AC_first() and encode_mcu_AC_refine() were stored in a JCOEF (signed short) array. When attempting to losslessly transform a specially-crafted malformed 12-bit JPEG image with a coefficient value of -32768 into a progressive 12-bit JPEG image, the progressive Huffman encoder attempted to store the absolute value of -32768 in the JCOEF array, thus overflowing the 16-bit signed data type. Therefore, at this point in the code: https://github.com/libjpeg-turbo/libjpeg-turbo/blob/8c5e78ce292c1642057102eac42f12ab57964293/jcphuff.c#L889 the absolute value was read as -32768, which caused the test at https://github.com/libjpeg-turbo/libjpeg-turbo/blob/8c5e78ce292c1642057102eac42f12ab57964293/jcphuff.c#L896 to fail, falling through to https://github.com/libjpeg-turbo/libjpeg-turbo/blob/8c5e78ce292c1642057102eac42f12ab57964293/jcphuff.c#L908 with an overly large value of r (46) that, when shifted left four places, incremented, and passed to emit_symbol(), exceeded the maximum index (255) for the derived code tables. Fortunately, the buffer overrun was fully contained within phuff_entropy_encoder, so the issue did not generate a segfault or other user-visible errant behavior, but it did cause a UBSan failure that was detected by OSS-Fuzz. This commit introduces an unsigned JCOEF (UJCOEF) data type and uses it to store the absolute values of DCT coefficients computed by the AC_first_prepare() and AC_refine_prepare() methods. Note that the changes to the Arm Neon progressive Huffman encoder extensions cause signed 16-bit instructions to be replaced with equivalent unsigned 16-bit instructions, so the changes should be performance-neutral. Based on: https://github.com/mayeut/libjpeg-turbo/commit/bbf61c0382c4f8bd1f1cfc666467581496c2fb7c Closes #628
DRC aa3dd0bd 2022-11-15T15:41:07 TurboJPEG: Nix unneeded setDecodeDefaults ret val The return value was inherited from setDecompDefaults() in 34dca052271f4a75b3c0f7b11a2c5024159628d4, but it was never needed.
DRC 4f7a8afb 2022-11-03T13:37:55 Build: Fix issues w/ Ninja Multi-Config generator - Fix an issue whereby a build with ENABLE_SHARED=0 could not be installed when using the Ninja Multi-Config CMake generator. - Fix an issue whereby a Windows installer could not be built when using the Ninja Multi-Config CMake generator. - Fix an issue whereby the Java regression tests failed when using the Ninja Multi-Config CMake generator. Based on: https://github.com/stilllman/libjpeg-turbo/commit/4f169deeb092a0513472b04f05f57bfe42b31ceb Closes #626
DRC 8c5e78ce 2022-11-03T11:22:50 Build: Document SO_AGE and TURBOJPEG_SO_AGE vars
DRC 8917c548 2022-11-03T14:20:22 ChangeLog.md: Add colons to sub-headers For some reason, I failed to add a colon to the "Significant changes relative to 2.1 beta1" sub-header, and the mistake propagated from there.
DRC cb3642cb 2022-11-03T12:22:51 Bump version to 2.1.5 to prepare for new commits
DRC 51f1924e 2022-10-21T11:36:29 wizard.txt: Clarify scan script restrictions The Wallace paper is not entirely clear on these restrictions, and the spec itself requires some digging. Closes #624
DRC eb0a024a 2022-10-04T12:51:38 Remove redundant jconfigint.h #includes Because of 607b668ff96e40fdc749de9b1bb98e7f40c86d93, jconfigint.h is included by jinclude.h.
DRC f579cc11 2022-10-03T19:46:09 Make SIMD capability variables thread-local ... ... on platforms that support TLS, which should include all currently-supported platforms (https://libjpeg-turbo.org/Documentation/OfficialBinaries) Addresses a concern raised in #87 Although it is still my opinion that the data race in init_simd() was innocuous, we can now fix it for free thanks to ae87a958613b69628b92088b313ded0d4f59a716, so why not?
DRC 2cad2169 2022-09-12T21:54:35 BUILDING.md: Acknowledge RHEL 9
DRC c5db99e1 2022-09-02T14:48:58 GitHub Actions: Specify Big Sur for macOS build The Catalina hosted runner is now fully deprecated.
DRC 8162eddf 2022-08-08T16:02:34 Fix issues w/ partial img decompr + buf img mode Fixes #611
DRC 2e136a71 2022-08-08T14:17:51 Re-fix buf img mode decompr err w/short prog JPEGs This commit reverts 4dbc293125b417f97e5b1ca9e7260c82ff199a06 and 9f8f683e745972720433406cff4b31e95bd6a33e (the previous two commits) and fixes #613 the correct way. The crux of the issue wasn't the size of the whole_image virtual array but rather that, since last_iMCU_row is unsigned, (last_iMCU_row - 1) wrapped around to 0xFFFFFFFF when last_iMCU_row was 0. This caused the interblock smoothing algorithm introduced in 6d91e950c871103a11bac2f10c63bf998796c719 to erroneously try to access the next two iMCU rows, neither of which existed. The first attempt at a fix (4dbc293125b417f97e5b1ca9e7260c82ff199a06) exposed a NULL dereference, detected by OSS-Fuzz, that occurred when attempting to decompress a specially-crafted malformed JPEG image to a YUV buffer using tjDecompressToYUV*() with 1/4 IDCT scaling. Fixes #613 (again) Also fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=49898
DRC 9f8f683e 2022-08-07T14:15:03 jdcoefct.c: Fix signed/unsigned mismatch VC++ wrng (introduced by previous commit)
DRC 4dbc2931 2022-08-07T09:24:57 Fix buf image mode decompr err w/ short prog JPEGs Regression introduced by 6d91e950c871103a11bac2f10c63bf998796c719 Because we're now using a 5x5 smoothing window when decompressing progressive JPEG images, we need to ensure that the whole_image virtual array contains at least five rows. Previously that was not always the case unless the progressive JPEG image being decompressed had at least five iMCU rows. Since an iMCU has a height of (8 * the vertical sampling factor), attempting to decompress 4:2:2 and 4:4:4 images <= 32 pixels in height or 4:2:0 images <= 64 pixels in height triggered a JERR_BAD_VIRTUAL_ACCESS error in decompress_smooth_data(), because access_rows exceeded the number of rows in the virtual array. Fixes #613
Donovan Watteau 59337a67 2022-07-06T12:11:50 PowerPC: Detect AltiVec support on OS X libjpeg-turbo's AltiVec SIMD extensions previously assumed that AltiVec instructions were available on all Power Macs that supported OS X 10.4 "Tiger" (the earliest version of OS X that libjpeg-turbo has ever supported), but Tiger can actually run on PowerPC G3 processors, which lack AltiVec instructions. This commit enables run-time detection of AltiVec instructions on OS X/PowerPC systems if AltiVec instructions are not force-enabled at compile time (using -maltivec). This allows the same build of libjpeg-turbo to support G3, G4, and G5 Power Macs. Closes #609
DRC ba22c0f7 2022-06-24T14:03:03 tjDecompressHeader3(): Accept tables-only streams Inspired by: https://github.com/amyspark/libjpeg-turbo/commit/b3b15cfe74cf07914122e26cf1e408a9a9cf3135 Closes #604 Closes #605
DRC a405519e 2022-05-27T11:59:56 Fix build if UPSAMPLE_MERGING_SUPPORTED undefined Although it is uncommon, some downstream implementations undefine one or more of the *_SUPPORTED macros in jmorecfg.h in order to reduce the size of the library. In the interest of maintaining backward compatibility with libjpeg, this is still a supported use case. Regression introduced by 9120a247436e84c0b4eea828cb11e8f665fcde30 Based on: https://github.com/fhanau/libjpeg-turbo/commit/74c4d032f0448edb0c8898b6e096123ae1aa093f Closes #601
Jiaxun Yang fac83814 2022-05-14T14:34:43 Build: Don't enable Loongson MMI with MIPS R6+ MIPS R6 removed some instructions, so Loongson MMI cannot be built with MIPS R6+ toolchains. Closes #598
modbw 290ddbf7 2022-04-22T08:30:21 MinGW: Fix str*casecmp() macro redef. warning MinGW defines strcasecmp() and strncasecmp() as macros in string.h if __CRT__NO_INLINE is defined, which will be the case when including any of the Win32 API headers. Closes #594
DRC 9171fd4b 2022-04-26T10:42:35 OSS-Fuzz: '.' --> '_' in fuzzer suffix Referring to https://github.com/google/oss-fuzz/issues/7575, if the fuzzer suffix contains periods, it can cause ClusterFuzz to misinterpret the file extension of the fuzzer executables and thus misidentify them.
DRC d0e7c454 2022-04-18T11:34:07 Don't install libturbojpeg.pc if WITH_TURBOJPEG=0 Fixes #593
Alex Richardson dfc63d42 2022-03-28T22:30:54 Fix non-SIMD alignment if void* bigger than double When building without the SIMD extensions, memory allocations are currently aligned to sizeof(double). However, this may be insufficient on architectures such as Arm Morello or 64-bit CHERI-RISC-V where pointers require 16-byte rather than 8-byte alignment. This patch causes memory allocations to be aligned to MAX(sizeof(void *), sizeof(double)) when building without the SIMD extensions. (NOTE: With C11 we could instead use alignof(max_align_t), but C89 compatibility is still necessary in libjpeg-turbo.) Closes #587
DRC 67cb0590 2022-04-06T10:50:33 OSS-Fuzz: Allow fuzzer suffix to be specified This facilitates fuzzing multiple branches of the code.
DRC 5c8cac97 2022-04-06T10:51:58 CI: Un-integrate CIFuzz Referring to the conversation in https://github.com/google/oss-fuzz/issues/7479 and #559, there was a misunderstanding regarding how CIFuzz works. It cannot be used to fuzz arbitrary PRs or code branches, and it has a 90-day delay in downloading corpora from OSS-Fuzz. That makes it unsuitable for libjpeg-turbo.
DRC df3c3dcb 2022-03-31T10:22:06 BUILDING.md: Generify PowerTools repo advice This advice applies to CentOS Stream as well as to popular CentOS 8 replacements, such as Rocky Linux and AlmaLinux.
DRC 2ee7264d 2022-03-11T17:28:36 Build: Don't set DEFAULT_FLOATTEST for x86 MSVC Newer versions of the 32-bit x86 Visual Studio compiler produce results compatible with FLOATTEST=no-fp-contract, so we can no longer intelligently set a default FLOATTEST value for that platform.
DRC 30cba2a2 2022-03-11T11:49:34 Build/Win: Fix CMake warning when WITH_TURBOJPEG=0 When 12-bit-per-component JPEG support is enabled (WITH_12BIT=1) or the TurboJPEG API library and associated test programs are disabled (WITH_TURBOJPEG=0), the Windows installer target should not depend on the turbojpeg, turbojpeg-static, and tjbench targets.
DRC a0148454 2022-03-11T10:50:47 Win: Fix build with Visual Studio 2010 (broken by 607b668ff96e40fdc749de9b1bb98e7f40c86d93) - Visual Studio 2010 apparently doesn't have the snprintf() inline function, so restore the macro that emulates that function using _snprintf_s(). - Explicitly include errno.h in strtest.c, since jinclude.h doesn't include it when building with Visual Studio.
DRC f3c716a2 2022-03-10T22:31:20 Link Sponsor button to GitHub Sponsors ... ... instead of PayPal.
DRC 6f1534d6 2022-03-09T12:58:17 example.txt: Fix a typo
DRC 9abeff46 2022-03-09T11:48:30 Remove extraneous #include directives jinclude.h already includes stdio.h, stdlib.h, and string.h.
DRC 932b5bb0 2022-03-09T10:50:51 IJG dox: Wordsmithing and formatting tweaks - Remove the section in libjpeg.txt that advised against building libjpeg as a shared library. We obviously do not follow that advice, and libjpeg-turbo does guarantee backward ABI compatibility in our libjpeg API library, even though libjpeg did not and does not. (Future expansion of our libjpeg API library, if necessary, will be accomplished using get/set functions that store the new parameters in the opaque master structs. Refer to https://github.com/mozilla/mozjpeg/commit/db2986c96fcebe10c8700081578e5305fd7bc7dc.) - Unmention install.txt, which was never relevant to libjpeg-turbo and was removed in v1.3 (6f96153c67e9a88775b457f998fc7fdd64c62cee). - Remove extraneous spaces. - Document the fact that TWO_FILE_COMMANDLINE must be defined in order to use the two-file interface with cjpeg, djpeg, jpegtran, and wrjpgcom. libjpeg-turbo never enables that interface by default.
DRC fdab4a7a 2022-03-08T17:25:57 Progs: Eliminate obsolete Mac ccommand() interface ccommand() was a 1990s-vintage hack for running console applications without a console. It doesn't exist in any modern macOS compiler.
DRC 05655481 2022-02-28T20:41:56 BUILDING.md: Mention sub-project best practices People keep trying to include libjpeg-turbo into downstream CMake-based build systems by way of the add_subdirectory() function and requesting upstream support when something inevitably breaks. (Refer to: #122, #173, #176, #202, #241, #349, #353, #412, #504, https://github.com/libjpeg-turbo/libjpeg-turbo/commit/a3d4aadd0d1597ad46edcbe3b964499ec785d40c#commitcomment-67575889). libjpeg-turbo has never supported that method of sub-project integration, because doing so would require that we (minimally): 1. avoid using certain CMake variables, such as CMAKE_SOURCE_DIR, CMAKE_BINARY_DIR, and CMAKE_PROJECT_NAME; 2. avoid using implicit include directories and relative paths; 3. provide a way to optionally skip the installation of libjpeg-turbo components in response to 'make install'; 4. provide a way to optionally postfix target names, to avoid namespace conflicts; 5. restructure the top-level CMakeLists.txt so that it properly sets the PROJECT_VERSION variable; and 6. design automated CI tests to ensure that new commits don't break any of the above. Even if we did all of that, issues would still arise, because it is impossible for one upstream build system to anticipate the widely varying needs of every downstream build system. That's why the CMake ExternalProject_Add() function exists, and it is my sincere hope that adding a blurb to BUILDING.md mentioning the need to use that function will head off future GitHub issues on this topic. If not, then I can at least post a link to this commit and the blurb and avoid doing the same song and dance over and over again.
Jonathan Wright c5f269eb 2021-09-03T11:52:40 Neon/AArch64: Explicitly unroll quant loop w/Clang The loop in jsimd_quantize_neon() is only executed twice and should be unrolled for AArch64 targets. GCC does that by default, but Clang 11 and later versions available at the time of this writing do not. This patch adds an unroll pragma when targetting AArch64 with Clang. We do not use the unroll pragma for AArch32 targets, because it causes the Clang-generated assembly code to exhaust the available Neon registers (32 x 64-bit) and spill to the stack. (DRC: Referring to the discussion in #570, this is likely due to compiler confusion that results in poor register allocation. It is possible to eliminate the spillage and reduce the instruction count by loading the data on a just-in-time basis, thus explicitly interleaving compute and I/O, but the performance implications of that are currently unknown.) The effects of unrolling the quantization loop are: 1) elimination of the loop control flow overhead and 2) enabling the use of LDP/STP instructions that work from a single base pointer, instead of using double the number of LDR/STR instructions, each requiring an address calculation. Closes #570
DRC 98bc3eeb 2022-02-24T23:09:58 Neon/AArch64: Fix/suppress UBSan warnings - Suppress a UBSan warning regarding storing a 64-bit value to a non-64-bit-aligned address. That behavior is technically undefined per the C spec but is supported in the context of the AArch64 architecture and compilers. - Explicitly promote block_diff[i] to unsigned int prior to left shifting it, in order to avoid a UBSan warning. This warning also described behavior that is technically undefined per the C spec but is supported in the context of the AArch64 architecture and compilers. Changing the type cast order eliminated the warning without changing the generated assembly code. Closes #582
Jonathan Wright 147548c0 2021-09-06T11:31:37 Neon/AArch64: Accelerate Huffman encoding - Make better use of 128-bit vector registers, thus reducing the number of Neon instructions required to construct the AC coefficient bitmap. - Refactor the Neon computations of 'nbits' and 'diff' to use shorter and higher-throughput instruction sequences. DRC's notes: This commit partially integrates #570. Arm reported a 1-4% speedup on Cortex-A55 and Neoverse-N1 cores when using recent compilers but little or no speedup with Clang 10. I observed no speedup with Clang 10 on my Cortex-A53 and Cortex-A72 cores. Thus, referring to #582, the primary purpose of this commit is to fix UBSan warnings regarding the shift operations previously located at Line 253: https://github.com/libjpeg-turbo/libjpeg-turbo/blob/d640a457305164417a60f30c6457d316f0b44a9d/simd/arm/aarch64/jchuff-neon.c#L253
DRC d640a457 2022-02-11T14:12:25 AppVeyor: Test strict MSVC compiler warnings
DRC eb21c023 2022-02-22T14:01:07 Eliminate incompatible pointer type warnings (C4057 in MSVC and -Wincompatible-pointer-types in GCC/Clang)
DRC 13377e6b 2022-02-11T13:58:31 MSVC: Eliminate int conversion warnings (C4244)
DRC 607b668f 2022-02-10T11:33:49 MSVC: Eliminate C4996 warnings in API libs The primary purpose of this is to encourage adoption of libjpeg-turbo in downstream Windows projects that forbid the use of "deprecated" functions. libjpeg-turbo's usage of those functions was not actually unsafe, because: - libjpeg-turbo always checks the return value of fopen() and ensures that a NULL filename can never be passed to it. - libjpeg-turbo always checks the return value of getenv() and never passes a NULL argument to it. - The sprintf() calls in format_message() (jerror.c) could never overflow the destination string buffer or leave it unterminated as long as the buffer was at least JMSG_LENGTH_MAX bytes in length, as instructed. (Regardless, this commit replaces those calls with snprintf() calls.) - libjpeg-turbo never uses sscanf() to read strings or multi-byte character arrays. - Because of b7d6e84d6a9283dc2bc50ef9fcaadc0cdeb25c9f, wrjpgcom explicitly checks the bounds of the source and destination strings before calling strcat() and strcpy(). - libjpeg-turbo always ensures that the destination string is terminated when using strncpy(). (548490fe5e2aa31cb00f6602d5a478b068b99682 made this explicit.) Regarding thread safety: Technically speaking, getenv() is not thread-safe, because the returned pointer may be invalidated if another thread sets the same environment variable between the time that the first thread calls getenv() and the time that that thread uses the return value. In practice, however, this could only occur with libjpeg-turbo if: (1) A multithreaded calling application used the deprecated and undocumented TJFLAG_FORCEMMX/TJFLAG_FORCESSE/TJFLAG_FORCESSE2 flags in the TurboJPEG API or set one of the corresponding environment variables (which are only intended for testing purposes.) Since the TurboJPEG API library only ever passed string constants to putenv(), the only inherent risk (i.e. the only risk introduced by the library and not the calling application) was that the SIMD extensions may have read an incorrect value from one of the aforementioned environment variables. or (2) A multithreaded calling application modified the value of the JPEGMEM environment variable in one thread while another thread was reading the value of that environment variable (in the body of jpeg_create_compress() or jpeg_create_decompress().) Given that the libjpeg API provides a thread-safe way for applications to modify the default memory limit without using the JPEGMEM environment variable, direct modification of that environment variable by calling applications is not supported. Microsoft's implementation of getenv_s() does not claim to be thread-safe either, so this commit uses getenv_s() solely to mollify Visual Studio. New inline functions and macros (GETENV_S() and PUTENV_S) wrap getenv_s()/_putenv_s() when building for Visual Studio and getenv()/setenv() otherwise, but GETENV_S()/PUTENV_S() provide no advantages over getenv()/setenv() other than parameter validation. They are implemented solely for convenience. Technically speaking, strerror() is not thread-safe, because the returned pointer may be invalidated if another thread changes the locale and/or calls strerror() between the time that the first thread calls strerror() and the time that that thread uses the return value. In practice, however, this could only occur with libjpeg-turbo if a multithreaded calling application encountered a file I/O error in tjLoadImage() or tjSaveImage(). Since both of those functions immediately copy the string returned from strerror() into a thread-local buffer, the risk is minimal, and the worst case would involve an incorrect error string being reported to the calling application. Regardless, this commit uses strerror_s() in the TurboJPEG API library when building for Visual Studio. Note that strerror_r() could have been used on Un*x systems, but it would have been necessary to handle both the POSIX and GNU implementations of that function and perform widespread compatibility testing. Such is left as an exercise for another day. Fixes #568
DRC ab6cae6f 2022-02-22T10:23:19 BUILDING.md: Clarify that Ninja works with Windows
DRC 3ccb6ead 2022-02-11T10:05:18 BUILDING.md: Remove NASM RPM rebuild instructions All currently supported Linux platforms now provide a recent enough version of either NASM or Yasm.
DRC 6441ad0f 2022-02-11T09:56:41 BUILDING.md: Document NASM/Yasm path variables This was an oversight from the CMake build system overhaul in libjpeg-turbo 2.0 (6abd39160c5a3762e9ebe024e75407665093e715). Closes #580
DRC 6d2d6d3b 2022-02-11T09:34:01 "YASM" = "Yasm" The assembler name was initially spelled "YASM", but it has been "Yasm" for the entirety of libjpeg-turbo's existence.
DRC e1588a2a 2022-02-10T22:23:26 Build: Fix Neon capability detection w/ MSVC (broken by 57ba02a408a9a55ccff25aae8b164632a3a4f177) Refer to #547
DRC 548490fe 2022-02-10T11:37:06 Ensure that strncpy() dest strings are terminated - Since the ERREXITS() and TRACEMSS() macros are never used internally (they are a relic of the legacy memory managers that libjpeg provided), the only risk was that an external program might have invoked one of those macros with a string longer than 79 characters (JMSG_STR_PARM_MAX - 1). - TJBench never invokes the THROW_TJ() macro with a string longer than 199 (JMSG_LENGTH_MAX - 1) characters, so there was no risk. However, it's a good idea to explicitly terminate the destination strings so that anyone looking at the code can immediately tell that it is safe.
DRC b579fc11 2022-02-07T15:27:50 Eliminate unnecessary JFREAD()/JFWRITE() macros
DRC a3d4aadd 2022-02-01T12:53:28 Build: Embed version/API/(C) info in MSVC DLLs Based on: https://github.com/TheDorkKnight/libjpeg-turbo/commit/da7a18801a5c305d3f8a71b065f179f1e22b73ae Closes #576
DRC d7d16df6 2022-02-01T09:11:19 Fix segv w/ h2v2 merged upsamp, jpeg_crop_scanline The h2v2 (4:2:0) merged upsampler uses a spare row buffer so that it can upsample two rows at a time but return only one row to the application, if necessary. merged_2v_upsample() copies from this spare row buffer into the application-supplied output buffer, using the out_row_width field in the my_merged_upsampler struct to determine how many samples to copy. out_row_width is set in jinit_merged_upsampler(), which is called within the body of jpeg_start_decompress(). Since jpeg_crop_scanline() must be called after jpeg_start_decompress(), jpeg_crop_scanline() must modify the value of out_row_width if the h2v2 merged upsampler will be used. Otherwise, merged_2v_upsample() can overflow the output buffer if the number of bytes between the current output buffer position and the end of the buffer is less than the number of bytes required to represent an uncropped scanline of the output image. All of the destination managers used by djpeg allocate either a whole image buffer or a scanline buffer based on the uncropped output image width, so this issue is not reproducible using djpeg. Fixes #574
DRC 14ce28a9 2022-01-29T12:33:40 TJBench: Remove innocuous always-true condition This was accidentally introduced into tjbench.c in 890f1e0413b54c40b663208779d4ea9dae20eaef and ported into the Java version from there. Based on https://github.com/libjpeg-turbo/libjpeg-turbo/pull/571/commits/4be6d4e7bdd09a73ee8456aa07693afa31ef2148 Refer to #571
DRC da41ab94 2022-01-06T12:57:26 GitHub Actions: Specify Catalina for macOS build macos-latest now maps to the Big Sur image, which doesn't have Xcode 12.2 installed.
DRC 1f55ae7b 2022-01-06T12:08:46 Fix -Wpedantic compiler warnings ... and test for those warnings (and others) when performing CI builds.
DRC 17297239 2022-01-06T09:17:30 Eliminate non-ANSI C compatibility macros libjpeg-turbo has never supported non-ANSI C compilers. Per the spec, ANSI C compilers must have locale.h, stddef.h, stdlib.h, memset(), memcpy(), unsigned char, and unsigned short. They must also handle undefined structures.
Dmitry Tsarevich a7f0244e 2022-01-06T02:21:10 turbojpeg.h: Parenthesize TJSCALED() dimension arg This ensures that, for example, TJSCALED(dim0 + dim1, sf) will evaluate to (((dim0 + dim1) * sf.num + sf.denom - 1) / sf.denom) rather than ((dim0 + (dim1 * sf.num) + sf.denom - 1) / sf.denom)
DRC a01857cf 2021-12-01T17:08:29 Build: Disallow NEON_INTRINSICS=0 if GAS is broken If NEON_INTRINSICS=0, then run the GAS sanity check from libjpeg-turbo 2.0.x and force-enable NEON_INTRINSICS if the test fails. This fixes the AArch32 build when using Clang 6.0 on Linux or the Clang toolchain in the Android NDK r15*-r16*. It also prevents users from manually disabling NEON_INTRINSICS if doing so would break the build (such as with Xcode 5.)
DRC 57ba02a4 2021-10-01T16:28:54 Build: Improve Neon capability detection - Use check_c_source_compiles() rather than check_symbol_exists() to detect the presence of vld1_s16_x3(), vld1_u16_x2(), and vld1q_u8_x4(). check_symbol_exists() is unreliable for detecting intrinsics, and in practice, it did not detect the presence of the aforementioned intrinsics in versions of GCC that support them. - Set DEFAULT_NEON_INTRINSICS=0 for GCC < 12, even if the aforementioned intrinsics are available. The AArch64 back end in GCC 10 and 11 supports the necessary intrinsics, but the GAS implementation is still faster when using those compilers. Fixes #547
DRC 8a9a6dd1 2021-12-01T09:02:36 Make incompatible feature errs more user-friendly - Use JERR_NOTIMPL ("Not implemented yet") rather than JERR_NOT_COMPILED ("Requested feature was omitted at compile time") to indicate that arithmetic coding is incompatible with Huffman table optimization. This is more consistent with other parts of the libjpeg API code. JERR_NOT_COMPILED is typically used to indicate that a major feature was not compiled in, whereas JERR_NOTIMPL is typically used to indicate that two features were compiled in but are incompatible with each other (such as, for instance, two-pass color quantization and partial image decompression.) - Change the text of JERR_NOTIMPL to "Requested features are incompatible". This is a more accurate description of the situation. "Not implemented yet" implies that it may be possible to support the requested combination of features in the future, but that is not true in most of the cases where JERR_NOTIMPL is used. Fixes #567
DRC 73eff6ef 2021-11-30T15:06:54 cjpeg: auto. compr. gray BMP/GIF-->grayscale JPEG aa7459050d7a50e1d8a99488902d41fbc118a50f was supposed to enable this for BMP input images but didn't, due to a similar oversight to the one fixed in the previous commit.
DRC 2ce32e0f 2021-11-30T10:54:24 cjpeg: automatically compress PGM-->grayscale JPEG (regression introduced by aa7459050d7a50e1d8a99488902d41fbc118a50f) cjpeg sets cinfo.in_color_space to JCS_RGB as an "arbitrary guess." Since tjLoadImage() never uses JCS_RGB, the PGM reader should treat JCS_RGB the same as JCS_UNKNOWN. Fixes #566
DRC e869a81a 2021-11-23T09:54:23 jdarith.c: Require cinfo->Se == DCTSIZE2 - 1 This fixes an oversight from the integration of the arithmetic entropy codec from libjpeg (66f97e6820e2cc9ef7429ea36285c80ffda87c8f). I chose to integrate the latest implementation available at the time, which was from jpeg-8b. However, I naively replaced cinfo->lim_Se with DCTSIZE2 - 1, not realizing that-- because of SmartScale-- jpeg-8b contains additional code (https://github.com/libjpeg-turbo/libjpeg-turbo/blob/jpeg-8b/jdinput.c#L249-L334) that guards against illegal values of cinfo->Se >= DCTSIZE2. Thus, libjpeg-turbo's implementation of arithmetic decoding has never guarded against such illegal values. This commit restores the relevant check from the original jpeg-6b arithmetic entropy codec patch ("jpeg-ari", 1e247ac854f8e33682bcfea475f6bccc42377208). Fixes #564
DRC 5446ff88 2021-11-19T13:43:36 CI: CIFuzz integration CIFuzz runs the project's fuzzers for a limited period of time any time a commit is pushed or a PR is submitted. This is not intended to replace OSS-Fuzz but rather to allow us to more quickly catch some fuzzing failures, including fuzzer build regressions like the one introduced in ecf021bc0d6f435daacff7c35ccaeef0145df1b9. Closes #559
DRC 0f88060b 2021-11-19T13:36:42 cjpeg.c: Fix fuzzer build failure (caused by previous commit)
DRC ecf021bc 2021-11-18T21:04:35 cjpeg: Add -strict arg to treat warnings as fatal This adds fault tolerance to the LZW-compressed GIF reader, which is the only compression-side code that can throw warnings.
DRC 4c5fa566 2021-11-17T16:09:50 CI: Halt immediately on all sanitizer errors
Piotr Kubaj d401d625 2021-10-27T03:39:09 PowerPC: Detect AltiVec support on FreeBSD Recent FreeBSD/PowerPC compilers, such as Clang 11.0.x on FreeBSD 13, do the equivalent of passing -maltivec to the compiler by default, so run-time AltiVec detection is unnecessary. However, it becomes necessary when using other compilers or when passing -mno-altivec to the compiler. Closes #552
DRC 2fd4ae7b 2021-10-27T14:00:15 JNI: Fix warnings/errors reported by -Xcheck:jni - Don't check for exceptions immediately after invoking the GetPrimitiveArrayCritical() method. That method does not throw exceptions, and checking for them caused -Xcheck:jni to warn about calling other JNI functions in the scope of Get/ReleasePrimitiveArrayCritical(). - Check for exceptions immediately after invoking the CallStaticObjectMethod() method in the PROP2ENV() macro. - Don't use the Get/ReleasePrimitiveArrayCritical() methods for small arrays. -Xcheck:jni didn't complain about that, but there is no performance advantage to using those methods rather than the Get*ArrayRegion() methods for small arrays, and using Get*ArrayRegion() makes the code less error-prone. - Don't release the source/destination planes arrays in the YUV methods until after the corresponding C TurboJPEG functions have returned.
Alex Xu (Hello71) 18edeff4 2021-10-02T14:26:57 Build: Set CMP0065 NEW (respect ENABLE_EXPORTS) Referring to https://cmake.org/cmake/help/latest/policy/CMP0065.html, CMake 3.3 and earlier automatically added compiler/linker flags such as -rdynamic/-export-dynamic, which caused symbols to be exported from executables. The primary purpose of this is to allow plugins loaded via dlopen() to access symbols from the calling program. libjpeg-turbo does not need this functionality, and enabling it needlessly increases the size of the libjpeg-turbo executables. Setting CMP0065 to NEW when using CMake 3.4 and later prevents CMake from automatically adding the aforementioned compiler/linker flags unless the ENABLE_EXPORTS property is set for a target (or the CMAKE_ENABLE_EXPORTS variable is set, which causes ENABLE_EXPORTS to be set for all targets.) Closes #554
DRC a9c41fbc 2021-10-03T12:43:15 Build: Don't enable Neon SIMD exts with Armv6- When building for 32-bit Arm platforms, test whether basic Neon intrinsics will compile with the specified compiler and C flags. This prevents the build system from enabling the Neon SIMD extensions when targetting Armv6 and other legacy architectures that do not support Neon instructions. Regression introduced by bbd8089297862efb6c39a22b5623f04567ff6443. (Checking whether gas-preprocessor.pl was needed for 32-bit Arm builds had the effect of checking whether Neon instructions were supported.) Fixes #553
DRC 739ecbc5 2021-09-30T16:28:51 ChangeLog.md: List CVE ID fixed by 2849d86a
DRC 4c313544 2021-09-20T16:31:11 AppVeyor: Deploy artifacts to Amazon S3 We would have been perfectly happy for AppVeyor to delete all artifacts other than those from the latest builds in each branch. Instead, they chose to change the global artifact retention policy to 1 month. In addition to being unworkable, that new policy uses more storage than the policy we requested. Lose/lose, so we'll just deploy to S3 like we do with other platforms.
DRC 173900b1 2021-09-02T12:48:50 tjTrans: Allow 8x8 crop alignmnt w/odd 4:4:4 JPEGs Fixes #549
DRC 5d2430f4 2021-09-02T13:17:32 ChangeLog.md: Add missing sub-header for 2.1.2
DRC 129f0cb7 2021-08-25T12:07:58 Neon/AArch64: Don't put GAS functions in .rodata Regression introduced by 240ba417aa4b3174850d05ea0d22dbe5f80553c1 Closes #546
DRC 0a9b9721 2021-08-09T17:25:36 jmemmgr.c: Pass correct size arg to jpeg_free_*() This issue was introduced in 5557fd22173ea9ab4c02c81e1dcec9bd6927814f due to an oversight, so it has existed in libjpeg-turbo since the project's inception. However, the issue is effectively a non-issue. Although #325 proposes allowing programs to override jpeg_get_*() and jpeg_free_*() externally, there is currently no way to override those functions without modifying the libjpeg-turbo source code. libjpeg-turbo only includes the malloc()/free() memory manager from libjpeg, and the implementation of jpeg_free_*() in that memory manager ignores the size argument. libjpeg had several additional memory managers for legacy systems (MS-DOS, System 7, etc.), but those memory managers ignored the size argument to jpeg_free_*() as well. Thus, this issue would have only potentially affected custom memory managers in downstream libjpeg-turbo forks, and since no one has complained until now, apparently those are rare. Fixes #542
DRC 2849d86a 2021-08-06T13:41:15 SSE2/64-bit: Fix trans. segfault w/ malformed JPEG Attempting to losslessly transform certain malformed JPEG images can cause the nbits table index in the Huffman encoder to exceed 32768, so we need to pad the SSE2 implementation of that table to 65536 entries as we do with the C implementation. Regression introduced by 087c29e07f7533ec82fd7eb1dafc84c29e7870ec Fixes #543
DRC 84d6306f 2021-07-27T11:02:23 Fix build w/CMake 3.14+ when CMAKE_SYSTEM_NAME=iOS Closes #539
y-guyon e6e952d5 2021-07-15T17:33:24 Suppress UBSan error in decode_mcu_fast() This is the same error that d147be83e9a9f904918ba7f834b0fb28e09de9b5 suppressed in decode_mcu_slow(). The image that reproduces this error in decode_mcu_fast() has been added to the libjpeg-turbo seed corpora. Closes #537
Alex Richardson a72816ed 2021-07-16T09:37:06 Use uintptr_t, if avail, for pointer-to-int casts Although sizeof(void *) == sizeof(size_t) for all architectures that are currently supported by libjpeg-turbo, such is not guaranteed by the C standard. Specifically, CHERI-enabled architectures (e.g. CHERI-RISC-V or Arm's Morello) use capability pointers that are twice the size of size_t (128 bits for Morello and RV64), so casting to size_t strips the upper bits of the pointer (including the validity bit) and makes it non-deferenceable, as indicated by the following compiler warning: warning: cast from provenance-free integer type to pointer type will give pointer that can not be dereferenced [-Werror,-Wcheri-capability-misuse] cvalue = values = (JCOEF *)PAD((size_t)values_unaligned, 16); Ignoring this warning results in a run-time crash. Casting pointers to uintptr_t, if it is available, avoids this problem, since uintptr_t is defined as an unsigned integer type that can hold a pointer value. Since C89 compatibility is still necessary in libjpeg-turbo, this commit introduces a new typedef for pointer-to-integer casts that uses a GNU-specific extension available in GCC 4.6+ and Clang 3.0+ and falls back to using size_t if the extension is unavailable. The only other options would require C99 or Clang-specific builtins. Closes #538
DRC 4d9f256b 2021-07-13T11:52:49 jpegtran: Add option to copy only ICC markers Closes #533
Peter Kasting b201838d 2021-07-10T16:07:05 Neon: Silence -Wimplicit-fallthrough warnings Refer to https://bugs.chromium.org/p/chromium/issues/detail?id=995993 Closes #534
DRC a1bfc058 2021-07-12T13:52:38 Neon/AArch32: Mark inline asm output as read/write 'buffer' is both passed into the inline assembly code and modified by it. See https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html, 6.47.2.3. With GCC 4, this commit does not change the generated assembly code at all. With GCC 8, this commit fixes an assembly error: /tmp/{foo}.s: Assembler messages: /tmp/{foo}.s:775: Error: registers may not be the same -- `str r9,[r9],#4' I'm not sure why that error went unnoticed, since I definitely benchmarked the previous commit with GCC 8. Anyhow, this commit changes the generated assembly code slightly but does not alter performance. With Clang 10, this commit changes the generated assembly code slightly but does not alter performance. Refer to #529
DRC 2a2970af 2021-07-09T15:35:56 Neon/AArch32: Work around Clang T32 miscompilation Referring to the C standard (http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf, J.2 Undefined behavior), the behavior of the compiler is undefined if "conversion between two pointer types produces a result that is incorrectly aligned." Thus, the behavior of this code *((uint32_t *)buffer) = BUILTIN_BSWAP32(put_buffer); in the AArch32 version of the FLUSH() macro is undefined unless 'buffer' is 32-bit-aligned. Referring to https://bugs.llvm.org/show_bug.cgi?id=50785, certain versions of Clang, when generating Thumb (T32) instructions, miscompile that code into an assembly instruction (stm) that requires the destination to be 32-bit-aligned. Since such alignment cannot be guaranteed within the Huffman encoder, this reportedly led to crashes (SIGBUS: illegal alignment) with AArch32/Thumb builds of libjpeg-turbo running on Android devices, although thus far I have been unable to reproduce those crashes with a plain Linux/Arm system. The miscompilation is visible with the Compiler Explorer: https://godbolt.org/z/rv1ccx1Pb However, it goes away when removing the return statement from the function. Thus, it seems that Clang's behavior in this regard is somewhat variable, which may explain why the crashes are only reproducible on certain platforms. The suggested workaround is to use memcpy(), but whereas Clang and recent GCC releases are smart enough to compile a 4-byte memcpy() call into a str instruction, GCC < 6 is not. Referring to https://godbolt.org/z/ae7Wje3P6, the only way to consistently produce the desired str instruction across all supported compilers is to use inline assembly. Visual C++ presumably does not miscompile the code in question, since no issues have been reported with it, but since the code relies on undefined compiler behavior, prudence dictates that e4ec23d7ae051c1c73947f889818900362fdc52d should be reverted for Visual C++, which this commit does. The performance impact of e4ec23d7ae051c1c73947f889818900362fdc52d for Visual C++/Arm builds is unknown (I have no ability to test such builds), but regardless, this commit reverts the Visual C++/Arm performance to that of libjpeg-turbo 2.1 beta1. Closes #529
DRC 97a1575c 2021-07-07T14:38:17 RPM: Don't include system lib dir in file list This resolves a conflict between the RPM generated by the libjpeg-turbo build system and the Red Hat 'filesystem' RPM if CMAKE_INSTALL_LIBDIR=/usr/lib[64]. This code was largely borrowed from the VirtualGL RPM spec. (I can legally do that because I hold the copyright on VirtualGL's implementation.) Fixes #532
DRC 0081c2de 2021-07-07T10:12:46 Neon/AArch32: Fix build if 'soft' float ABI used Arm compilers have three floating point ABI options: 'soft' compiles floating point operations as function calls into a software floating point library, which emulates floating point operations using integer operations. Floating point function arguments are passed using integer registers. 'softfp' also compiles floating point operations as function calls into a floating point library and passes floating point function arguments using integer registers, but the floating point library functions can use FPU instructions if the CPU supports them. 'hard' compiles floating point operations into inline FPU instructions, similarly to x86 and other architectures, and passes floating point function arguments using FPU registers. Not all AArch32 CPUs have FPUs or support Neon instructions, so on Linux and Android platforms, the AArch32 SIMD dispatcher in libjpeg-turbo only enables the Neon SIMD extensions at run time if /proc/cpuinfo indicates that the CPU supports Neon instructions or if Neon instructions are explicitly enabled (e.g. by passing -mfpu=neon to the compiler.) In order to support all AArch32 CPUs using the same code base, i.e. to support run-time FPU and Neon auto-detection, it is necessary to compile the scalar C source code using -mfloat-abi=soft. However, the 'soft' floating point ABI cannot be used when compiling Neon intrinsics, so the intrinsics implementation of the Neon SIMD extensions must be compiled using -mfloat-abi=softfp if the scalar C source code is compiled using -mfloat-abi=soft. This commit modifies the build system so that it detects whether -mfloat-abi=softfp must be explicitly added to the compiler flags when building the intrinsics implementation of the Neon SIMD extensions. This will be necessary if the build is using the 'soft' floating point ABI along with run-time auto-detection of Neon instructions. Fixes #523
Peter Kasting 9df5786f 2021-06-26T16:22:21 Fix -Wimplicit-fallthrough warnings with Clang The existing /*FALLTHROUGH*/ comments work with GCC but not Clang, so this commit adds a FALLTHROUGH macro that uses the 'fallthrough' attribute if the compiler supports it. Refer to https://bugs.chromium.org/p/chromium/issues/detail?id=995993 NOTE: All versions of GCC that support -Wimplicit-fallthrough also support the 'fallthrough' attribute, but certain other compilers (Oracle Solaris Studio, for instance) support /*FALLTHROUGH*/ but not the 'fallthrough' attribute. Thus, this commit retains the /*FALLTHROUGH*/ comments, which have existed in the libjpeg code base in some form since 1994 (libjpeg v5.) Closes #531
DRC 1a1fb615 2021-06-18T09:46:03 ChangeLog.md: List CVE ID fixed by c76f4a08 Referring to #527, the security community did not assign this CVE ID until more than 8 months after the fix for the issue was released. By the time they assigned the ID, libjpeg-turbo already had two production releases containing the fix. This calls into question the usefulness of assigning a CVE ID to the issue, particularly given that the buffer overrun in question was fully contained in the stack, not detectable with valgrind, and confined to lossless transformation (it did not affect JPEG compression or decompression.) https://vuldb.com/?id.176175 says that "the exploitability is told to be easy" but provides no clarification, and given that the author of that page does not seem to be aware that a fix for the issue has been available since early December of 2019, it calls into question the accuracy of everything else on the page. It would really be nice if the security community approached me about these things before wasting my time, but I guess it's my lot in life to modify a change log entry from 2019 to include a CVE ID from 2020. So it goes...
DRC 5135c2e2 2021-05-28T12:51:53 Build: Use PIC for jsimd_none.o in shared libs In theory, all objects that will be included in a Un*x shared library must be built using PIC. In practice, most compilers don't require PIC to be explicitly specified for jsimd_none.o, either because the compiler automatically enables PIC in all cases (Ubuntu) or because the size of the generated object is too small. But some rare compilers do require PIC to be explicitly specified for jsimd_none.o. Fixes #520
DRC 3932190c 2021-05-17T13:05:16 Fix build w/ non-GCC-compatible Un*x/Arm compilers Regression introduced by d2c407995992be1f128704ae2479adfd7906c158 Closes #519
DRC a219fd13 2021-05-12T10:58:59 GitHub bug-report.md: "master" branch --> "main"
DRC c23672ce 2021-04-23T13:05:25 GitHub Actions: Don't build tags Our workflow script does not currently work with tags, and there is no point to building tags anyhow, since we do not use the CI system to spin official builds.
kmx.io     mail     discord kmxgit v0.4.0