fuzz

Branch :

Log

Commit	Date	Message
f74989d8	2025-09-25 11:32:45	Clean up #include directives This is subtle, but #include <header.h> searches directories specified with -I, then system include directories. #include "header.h" searches the current source directory, then directories specified with -I, then system include directories. Using bracketed #include directives for jpeglib.h, jinclude.h, jerror.h, cdjpeg.h, and turbojpeg.h only worked because the build system explicitly passed -I{source_directory}/src/ to the compiler. Referring to 51cee0362998ec6f1eabac1e795f3b6e3ee639ea, it's better for the source code to have as few dependencies on our specific build system as possible. Since jpeglib.h, jinclude.h, jerror.h, and turbojpeg.h can be installed in system include directories, it's also better for internal references to those headers to resolve internally first, to avoid potential conflicts between the system-installed version of libjpeg-turbo and the version being built. (Such conflicts would never have occurred with our build system, but they might have occurred due to misintegration with a downstream build system.)
bf2c1efb	2025-09-25 11:11:01	Build: Use correct compress12_lossless fuzzer src (oops)
2a0c8627	2025-04-03 13:05:01	Fuzz: Fix -Wsign-compare warnings
6bace81b	2024-10-31 11:54:32	Fix OSS-Fuzz decompress_yuv fuzzer MSan failure
9b01f5a0	2024-09-14 11:56:14	TJ: Add func/method for computing xformed buf size
437a4993	2024-09-12 21:11:00	Merge branch 'main' into dev
bcbca8b9	2024-09-12 20:55:39	Fuzz: Calc. xformed buf size based on dst. subsamp (oversight from b3f0abe377f2dd83396c9d0d4176f684c122af3f)
c519d7b6	2024-09-05 11:10:44	Don't ignore JPEG buf size with TJPARAM_NOREALLOC Since the introduction of TJFLAG_NOREALLOC in libjpeg-turbo 1.2.x, the TurboJPEG C API documentation has (confusingly) stated that: - if the JPEG buffer pointer points to a pre-allocated buffer, then the JPEG buffer size must be specified, and - the JPEG buffer size should be specified if the JPEG buffer is pre-allocated to an arbitrary size. The documentation never explicitly stated that the JPEG buffer size should be specified if the JPEG buffer is pre-allocated to a worst-case size, but since focus does not imply exclusion, it also never explicitly stated the reverse. Furthermore, the documentation never stated that this was contingent upon TJPARAM_NOREALLOC/TJFLAG_NOREALLOC. However, effectively the compression and lossless transformation functions ignored the JPEG buffer size(s) passed to them, and assumed that the JPEG buffer(s) had been allocated to a worst-case size, if TJPARAM_NOREALLOC/TJFLAG_NOREALLOC was set. This behavior was an accidental and undocumented throwback to libjpeg-turbo 1.1.x, in which the tjCompress() function provided no way to specify the JPEG buffer size. It was always a bad idea for applications to rely upon that behavior (although our own TJBench application unfortunately did.) However, if such applications exist in the wild, the new behavior would constitute a breaking change, so it has been introduced only into libjpeg-turbo 3.1.x and only into TurboJPEG 3 API functions. The previous behavior has been retained when calling functions from the TurboJPEG 2.1.x API and prior versions. Did I mention that APIs are hard?
5f05c75a	2024-09-06 19:55:20	Merge branch 'main' into dev
b3f0abe3	2024-09-06 10:23:02	TJ: Calc. xformed buf sizes based on dst. subsamp With respect to tj3Transform(), this addresses an oversight from bb1d540a807783a3db8b85bab2993d70b1330287. Note to self: A convenience function/method for computing the worst-case transformed JPEG size for a particular transform would be nice.