kc3-lang/libjpeg-turbo

---

Log

Author	Commit	Date	CI	Message
	d640a457	2022-02-11T14:12:25		AppVeyor: Test strict MSVC compiler warnings
	eb21c023	2022-02-22T14:01:07		Eliminate incompatible pointer type warnings (C4057 in MSVC and -Wincompatible-pointer-types in GCC/Clang)
	13377e6b	2022-02-11T13:58:31		MSVC: Eliminate int conversion warnings (C4244)
	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
	ab6cae6f	2022-02-22T10:23:19		BUILDING.md: Clarify that Ninja works with Windows
	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.
	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
	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.
	e1588a2a	2022-02-10T22:23:26		Build: Fix Neon capability detection w/ MSVC (broken by 57ba02a408a9a55ccff25aae8b164632a3a4f177) Refer to #547
	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.
	b579fc11	2022-02-07T15:27:50		Eliminate unnecessary JFREAD()/JFWRITE() macros
	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
	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
	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
	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.
	1f55ae7b	2022-01-06T12:08:46		Fix -Wpedantic compiler warnings ... and test for those warnings (and others) when performing CI builds.
	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.
	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)
	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.)
	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
	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
	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.
	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
	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
	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
	0f88060b	2021-11-19T13:36:42		cjpeg.c: Fix fuzzer build failure (caused by previous commit)
	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.
	4c5fa566	2021-11-17T16:09:50		CI: Halt immediately on all sanitizer errors
	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
	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.
	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
	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
	739ecbc5	2021-09-30T16:28:51		ChangeLog.md: List CVE ID fixed by 2849d86a
	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.
	173900b1	2021-09-02T12:48:50		tjTrans: Allow 8x8 crop alignmnt w/odd 4:4:4 JPEGs Fixes #549
	5d2430f4	2021-09-02T13:17:32		ChangeLog.md: Add missing sub-header for 2.1.2
	129f0cb7	2021-08-25T12:07:58		Neon/AArch64: Don't put GAS functions in .rodata Regression introduced by 240ba417aa4b3174850d05ea0d22dbe5f80553c1 Closes #546
	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
	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
	84d6306f	2021-07-27T11:02:23		Fix build w/CMake 3.14+ when CMAKE_SYSTEM_NAME=iOS Closes #539
	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
	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
	4d9f256b	2021-07-13T11:52:49		jpegtran: Add option to copy only ICC markers Closes #533
	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
	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
	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
	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
	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
	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
	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...
	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
	3932190c	2021-05-17T13:05:16		Fix build w/ non-GCC-compatible Un*x/Arm compilers Regression introduced by d2c407995992be1f128704ae2479adfd7906c158 Closes #519
	a219fd13	2021-05-12T10:58:59		GitHub bug-report.md: "master" branch --> "main"
	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.
	4f51f36e	2021-04-23T11:42:40		Bump version to 2.1.0 to prepare for final release
	e0606daf	2021-04-21T14:49:06		TurboJPEG: Update JPEG buf ptrs on comp/xform err When using the in-memory destination manager, it is necessary to explicitly call the destination manager's term_destination() method if an error occurs. That method is called by jpeg_finish_compress() but not by jpeg_abort_compress(). This fixes a potential double free() that could occur if tjCompress*() or tjTransform() returned an error and the calling application tried to clean up a JPEG buffer that was dynamically re-allocated by one of those functions.
	ffc1aa96	2021-04-21T11:06:22		Include TJ.FLAG_LIMITSCANS in JNI header (oversight from c81e91e8ca34f4e8b43cf48277c2becf3fe9447d) This is purely cosmetic, since the JNI wrapper doesn't actually use that flag.
	55ec9b3b	2021-04-21T11:04:42		OSS-Fuzz: Code comment tweaks for compr. targets (oversight from 171b875b272f47f1ae42a5009c64f424db22a95b)
	4de8f692	2021-04-16T16:34:12		jdhuff.h: Fix ASan regression caused by 8fa70367 The 0xFF is, in fact, necessary.
	785ec30e	2021-04-16T15:59:38		cjpeg_fuzzer: Add cov for h2v2 smooth downsampling
	d147be83	2021-04-15T23:31:51		Huff decs: Fix/suppress more innocuous UBSan errs - UBSan complained that entropy->restarts_to_go was underflowing an unsigned integer when it was decremented while cinfo->restart_interval == 0. That was, of course, completely innocuous behavior, since the result of the underflowing computation was never used. - d3a3a73f64041c6a6905faf6f9f9832e735fd880 and 7bc9fca4309563d66b0c5665a616285d0e9baeb4 silenced a UBSan signed integer overflow error, but unfortunately other malformed JPEG images have been discovered that cause unsigned integer overflow in the same computation. Since, to the best of our understanding, this behavior is innocuous, this commit reverts the commits listed above, suppresses the UBSan errors, and adds code comments to document the issue.
	8fa70367	2021-04-15T22:26:53		Huff dec: Fix non-deterministic output w/bad input Referring to https://bugzilla.mozilla.org/show_bug.cgi?id=1050342, there are certain very rare circumstances under which a malformed JPEG image can cause different Huffman decoder output to be produced, depending on the size of the source manager's I/O buffer. (More specifically, the fast Huffman decoder didn't handle invalid codes in the same manner as the slow decoder, and since the fast decoder requires all data to be memory-resident, the buffering strategy determines whether or not the fast decoder can be used on a particular MCU block.) After extensive experimentation, the Mozilla and Chrome developers and I determined that this truly was an innocuous issue. The patch that both browsers adopted as a workaround caused a performance regression with 32-bit code, which is why it was not accepted into libjpeg-turbo. This commit fixes the problem in a less disruptive way with no performance regression.
	171b875b	2021-04-15T19:03:53		OSS-Fuzz: Check img size b4 readers allocate mem After the completion of the start_input() method, it's too late to check the image size, because the image readers may have already tried to allocate memory for the image. If the width and height are excessively large, then attempting to allocate memory for the image could slow performance or lead to out-of-memory errors prior to the fuzz target checking the image size. NOTE: Specifically, the aforementioned OOM errors and slow units were observed with the compression fuzz targets when using MSan.
	3ab32348	2021-04-13T11:51:29		OSS-Fuzz: More code coverage improvements
	3e68a5ee	2021-04-12T14:37:43		jchuff.c: Fix MSan error Certain rare malformed input images can cause the Huffman encoder to generate a value for nbits that corresponds to an uninitialized member of the DC code table. The ramifications of this are minimal and would basically amount to a different bogus JPEG image being generated from a particular bogus input image.
	4e451616	2021-04-12T11:53:29		compress_yuv_fuzzer: Minor code coverage tweak
	629e96ee	2021-04-12T11:52:55		cjpeg.c: Code formatting tweak
	ebaa67ea	2021-04-12T10:38:52		rdbmp.c: Fix more innocuous UBSan errors - Referring to 3311fc00010c6cb305d87525c9ef60ebdf036cfc, we need to use unsigned intermediate math in order to make UBSan happy, even though (JDIMENSION)(A * B) is effectively the same as (JDIMENSION)A *(JDIMENSION)B, regardless of intermediate overflow. - Because of the previous commit, it is now possible for bfOffBits to be INT_MIN, which would cause the initial computation of bPad to underflow a signed integer. Thus, we need to check for that possibility as soon as we know the values of bfOffBits and headerSize. The worst case from this regression is that bPad could wrap around to a large positive value, which would cause a "Premature end of input file" error in the subsequent read_byte() loop. Thus, this issue was effectively innocuous as well, since it resulted in catching the same error later and in a different way. Also, the issue was very well-contained, since it was both introduced and fixed as part of the ongoing OSS-Fuzz integration project.
	dd830b3f	2021-04-09T17:36:41		rdbmp.c/rdppm.c: Fix more innocuous UBSan errors - rdbmp.c: Because of 8fb37b81713a0cdc14622dc08892ebd28a3233aa, bfOffBits, biClrUsed, and headerSize were made into unsigned ints. Thus, if bPad would eventually be negative due to a malformed header, UBSan complained about unsigned math being used in the intermediate computations. It was unnecessary to make those variables unsigned, since they are only meant to hold small values, so this commit makes them signed again. The UBSan error was innocuous, because it is effectively (if not officially) the case that (int)((unsigned int)a - (unsigned int)b) == (int)a - (int)b. - rdbmp.c: If (biWidth * source->bits_per_pixel / 8) would overflow an unsigned int, then UBSan complained at the point at which row_width was set in start_input_bmp(), even though the overflow would have been detected later in the function. This commit adds overflow checks prior to setting row_width. - rdppm.c: read_pbm_integer() now bounds-checks the intermediate value computations in order to catch integer overflow caused by a malformed text PPM. It's possible, though extremely unlikely, that the intermediate value computations could have wrapped around to a value smaller than maxval, but the worst case is that this would have generated a bogus pixel in the uncompressed image rather than throwing an error.
	4ede2ef5	2021-04-09T17:26:19		OSS-Fuzz: cjpeg fuzz target
	5cda8c5e	2021-04-09T13:12:32		compress_yuv_fuzzer: Use unique filename template
	47b66d1d	2021-04-09T11:26:34		OSS-Fuzz: Fix UBSan err caused by TJFLAG_FUZZING
	55ab0d39	2021-04-08T16:13:06		OSS-Fuzz: YUV encoding/compression fuzz target
	18bc4c61	2021-04-07T16:04:58		compress.cc: Code formatting tweak
	b1079002	2021-04-07T15:51:05		rdppm.c: Fix innocuous MSan error A fuzzing test case that was effectively a 1-pixel PGM file with a maximum value of 1 and an actual value of 8 caused an uninitialized member of the rescale[] array to be accessed in get_gray_rgb_row() or get_gray_cmyk_row(). Since, for performance reasons, those functions do not perform bounds checking on the PPM values, we need to ensure that unused members of the rescale[] array are initialized.
	3311fc00	2021-04-07T14:20:49		rdbmp.c: Fix innocuous UBSan error A fuzzing test case with an image width of 838860946 triggered a UBSan error: rdbmp.c:633:34: runtime error: signed integer overflow: 838860946 * 3 cannot be represented in type 'int' Because the result is cast to an unsigned int (JDIMENSION), this error is irrelevant, because (unsigned int)((int)838860946 * (int)3) == (unsigned int)838860946 * (unsigned int)3
	34d264d6	2021-04-07T12:44:50		OSS-Fuzz: Private TurboJPEG API flag for fuzzing This limits the tjLoadImage() behavioral changes to the scope of the compress_fuzzer target. Otherwise, TJBench in fuzzer builds would refuse to load images larger than 1 Mpixel.
	f35fd27e	2021-04-06T12:51:03		tjLoadImage: Fix issues w/loading 16-bit PPMs/PGMs - The PPM reader now throws an error rather than segfaulting (due to a buffer overrun) if an application attempts to load a 16-bit PPM file into a grayscale uncompressed image buffer. No known applications allowed that (not even the test applications in libjpeg-turbo), because that mode of operation was never expected to work and did not work under any circumstances. (In fact, it was necessary to modify TJBench in order to reproduce the issue outside of a fuzzing environment.) This was purely a matter of making the library bow out gracefully rather than crash if an application tries to do something really stupid. - The PPM reader now throws an error rather than generating incorrect pixels if an application attempts to load a 16-bit PGM file into an RGB uncompressed image buffer. - The PPM reader now correctly loads 16-bit PPM files into extended RGB uncompressed image buffers. (Previously it generated incorrect pixels unless the input colorspace was JCS_RGB or JCS_EXT_RGB.) The only way that users could have potentially encountered these issues was through the tjLoadImage() function. cjpeg and TJBench were unaffected.
	df17d398	2021-04-06T11:34:30		jcphuff.c: -Wjump-misses-init warning w/GCC 9 -m32 (verified that this commit does not change the generated 64-bit or 32-bit assembly code)
	cd9a3185	2021-04-05T22:20:52		Bump TurboJPEG C API version to 2.1 (because of TJFLAG_LIMITSCANS)
	d2d44655	2021-04-05T21:41:30		OSS-Fuzz: Compression fuzz target
	5536ace1	2021-04-05T21:12:29		OSS-Fuzz: Fix C++11 compiler warnings in targets
	5dd906be	2021-04-05T17:47:34		OSS-Fuzz: Test non-default opts w/ decompress_yuv The non-default options were not being tested because of a pixel format comparison buglet. This commit also changes the code in both decompression fuzz targets such that non-default options are tested based on the pixel format index rather than the pixel format value, which is a bit more idiot-proof.
	c81e91e8	2021-04-05T16:08:22		TurboJPEG: New flag for limiting prog JPEG scans This also fixes timeouts reported by OSS-Fuzz.
	bff7959e	2021-04-02T14:53:43		OSS-Fuzz: Require static libraries Refer to https://google.github.io/oss-fuzz/further-reading/fuzzer-environment/#runtime-dependencies for the reasons why this is necessary.
	6ad658be	2021-04-02T14:50:35		OSS-Fuzz: Build fuzz targets using C++ compiler Otherwise, the targets will require libstdc++, the i386 version of which is not available in the OSS-Fuzz runtime environment. The OSS-Fuzz build environment passes -stdlib:libc++ in the CXXFLAGS environment variable in order to mitigate this issue, since the runtime environment has the i386 version of libc++, but using that compiler flag requires using the C++ compiler.
	7b57cba6	2021-03-31T11:16:51		OSS-Fuzz: Fix uninitialized reads detected by MSan
	2f9e8a11	2021-03-29T18:54:12		OSS-Fuzz integration This commit integrates OSS-Fuzz targets directly into the libjpeg-turbo source tree, thus obsoleting and improving code coverage relative to Google's OSS-Fuzz target for libjpeg-turbo (previously available here: https://github.com/google/oss-fuzz). I hope to eventually create fuzz targets for the BMP, GIF, and PPM readers as well, which would allow for fuzz-testing compression, but since those readers all require an input file, it is unclear how to build an efficient fuzzer around them. It doesn't make sense to fuzz-test compression in isolation, because compression can't accept arbitrary input data.
	e4ec23d7	2021-02-10T16:45:50		Neon: Use byte-swap builtins instead of inline asm Define compiler-independent byte-swap macros and use them instead of executing 'rev' via inline assembly code with GCC-compatible compilers or a slow shift-store sequence with Visual C++. * This produces identical assembly code with: - 64-bit GCC 8.4.0 (Linux) - 64-bit GCC 9.3.0 (Linux) - 64-bit Clang 10.0.0 (Linux) - 64-bit Clang 10.0.0 (MinGW) - 64-bit Clang 12.0.0 (Xcode 12.2, macOS) - 64-bit Clang 12.0.0 (Xcode 12.2, iOS) * This produces different assembly code with: - 64-bit GCC 4.9.1 (Linux) - 32-bit GCC 4.8.2 (Linux) - 32-bit GCC 8.4.0 (Linux) - 32-bit GCC 9.3.0 (Linux) Since the intrinsics implementation of Huffman encoding is not used by default with these compilers, this is not a concern. - 32-bit Clang 10.0.0 (Linux) Verified performance neutrality Closes #507
	e795afc3	2021-03-25T22:36:15		SSE2: Fix prog Huff enc err if Sl%32==0 && Al!=0 (regression introduced by 16bd984557fa2c490be0b9665e2ea0d4274528a8) This implements the same fix for jsimd_encode_mcu_AC_refine_prepare_sse2() that a81a8c137b3f1c65082aa61f236aa88af61b3ad4 implemented for jsimd_encode_mcu_AC_first_prepare_sse2(). Based on: https://github.com/MegaByte/libjpeg-turbo/commit/1a59587397150c9ef9dffc5813cb3891db4bc0c8 https://github.com/MegaByte/libjpeg-turbo/commit/eb176a91d87a470bf8c987be786668aa944dd1dd Fixes #509 Closes #510
	2c01200c	2021-03-15T19:56:53		Build: Fix incorrect regexes w/ if(...MATCHES...) "arm*" as a regex means 'ar' followed by zero or more 'm' characters, which matches 'parisc' and 'sparc64' as well.
	ed70101d	2021-03-15T12:36:55		ChangeLog.md: List CVE ID fixed by 1719d12e Referring to https://bugzilla.redhat.com/show_bug.cgi?id=1937385#c2, it is my opinion that the severity of this bug was grossly overstated and that a CVE never should have been assigned to it, but since one was assigned, users need to know which version of libjpeg-turbo contains the fix. Dear security community, please learn what "DoS" actually means and stop misusing that term for dramatic effect. Thanks.
	8a2cad02	2021-01-21T10:51:49		Build: Handle CMAKE_OSX_ARCHITECTURES=(i386|ppc) We don't officially support i386 or PowerPC Mac builds of libjpeg-turbo anymore, but they still work (bearing in mind that PowerPC builds require GCC v4.0 in Xcode 3.2.6, and i386 builds require Xcode 9.x or earlier.) Referring to #495, apparently MacPorts needs this functionality.
	b6772910	2021-01-19T15:32:32		Add Sponsor button for GitHub repository
	399aa374	2021-01-19T12:25:11		Build: Support CMAKE_OSX_ARCHITECTURES ... as long as it contains only a singular value, which must equal "x86_64" or "arm64". Refer to #495
	1719d12e	2021-01-14T18:35:15		cjpeg: Fix FPE when compressing 0-width GIF Fixes #493
	486cdcfb	2021-01-12T17:45:55		Fix build with Visual C++ and /std:c11 or /std:c17 Fixes #481 Closes #482
	74e6ea45	2021-01-05T20:23:11		Neon: Fix Huffman enc. error w/Visual Studio+Clang The GNU builtin function __builtin_clzl() accepts an unsigned long argument, which is 8 bytes wide on LP64 systems (most Un*x systems, including Mac) but 4 bytes wide on LLP64 systems (Windows.) This caused the Neon intrinsics implementation of Huffman encoding to produce mathematically incorrect results when compiled using Visual Studio with Clang. This commit changes all invocations of __builtin_clzl() in the Neon SIMD extensions to __builtin_clzll(), which accepts an unsigned long long argument that is guaranteed to be 8 bytes wide on all systems. Fixes #480 Closes #490
	d2c40799	2020-12-17T16:02:47		Use CLZ compiler intrinsic for Windows/Arm builds The __builtin_clz() compiler intrinsic was already used in the C Huffman encoders when building libjpeg-turbo for Arm CPUs using a GCC-compatible compiler. This commit modifies the C Huffman encoders so that they also use__builtin_clz() when building for Arm CPUs using Visual Studio + Clang, as well as the equivalent _CountLeadingZeros() compiler intrinsic when building for Arm CPUs using Visual C++. In addition to making the C Huffman encoders faster on Windows/Arm, this also prevents jpeg_nbits_table from being included in Windows/Arm builds, thus saving 128 KB of memory.
	3e8911aa	2021-01-11T13:56:01		Build: Use correct SIMD exts w/VStudio IDE + Arm64 When configuring a Visual Studio IDE build and passing -A arm64 to CMake, CMAKE_SYSTEM_PROCESSOR will be amd64, so we should set CPU_TYPE based on the value of CMAKE_GENERATOR_PLATFORM rather than the value of CMAKE_SYSTEM_PROCESSOR.