Reasoning:
Analysis showed `bit_depths` is passed from `VP8LCreateHuffmanTree` (as
`huff_code->code_lengths`) to `GenerateOptimalTree` (as `bit_depths`
with size `histogram_size` = `huff_code->num_symbols`) and then to
`SetBitDepths`. The `HuffmanTreeCode` struct stores `code_lengths` and
`codes` pointers, both sized by `num_symbols`. These arrays are
allocated in `GetHuffBitLengthsAndCodes` (called by
`EncodeImageInternal`) based on `num_symbols`.
The fix involves:
- Annotating `HuffmanTreeCode::code_lengths` and
`HuffmanTreeCode::codes` with `__counted_by(num_symbols)` in
`src/utils/huffman_encode_utils.h`.
- Annotating the `bit_depths` parameter in `GenerateOptimalTree` with
`__counted_by(histogram_size)` in `src/utils/huffman_encode_utils.c`.
- Annotating the `bit_depths` parameter in `SetBitDepths` with
`__indexable` in `src/utils/huffman_encode_utils.c`, as the size
parameter (`histogram_size`) is not directly available but indexing is
known to be safe based on caller logic (indices `tree->value` are
within `[0, histogram_size - 1]`).
Bug: 432511821
Change-Id: Icfd32f15d0744983b5912d527e5bc59ac58343a5
SRWLOCK is faster than CRITICAL_SECTION. MSVC implements the C11 mtx_t
and C++ std::mutex using SRWLOCK.
Change-Id: I144d2f53aeaa135030ea8c057a2ae8543e6c91b8
Assume the CONDITION_VARIABLE added in Windows Vista is available.
Remove an unneeded WaitForSingleObject() macro that converts
WaitForSingleObject() calls to WaitForSingleObjectEx() calls with
bAlertable=FALSE. The WaitForSingleObject() function does not enter an
alertable wait state, so it is equivalent to WaitForSingleObjectEx()
with bAlertable=FALSE.
Remove code for Windows older than Vista in src/dsp/cpu.h.
Change-Id: I7df95557713923e05a7bfb62e095ec6172cfd708
Import bounds_safety.h across all of webputils, with one exception being
dsp.h, since it's imported by webputils.h in one place. Also prepend
WEBP_ASSUME_UNSAFE_INDEXABLE_ABI to every webputil file to indicate to
the compiler that every pointer should be treated as __unsafe_indexable.
We also need to replace memcpy/memset/memmove with the unsafe variants
WEBP_UNSAFE_*, as memcpy/memset/memmove require bounded/sized pointers.
With this change, all of libwebputils (and libwebp) should build with
-DWEBP_ENABLE_FBOUNDS_SAFETY=true
Change-Id: Iad87be0455182d534c074ef6dc1a30fa66b74b6c
(Debian clang-format version 19.1.7 (3+build4)) with `--style=Google`.
Manual changes:
* clang-format disabled around macros with stringification (mostly
assembly)
* some inline assembly strings were adjusted to avoid awkward line
breaks
* trailing commas, `//` or suffixes (`ull`) added to help array
formatting
* thread_utils.c: parameter comments were changed to the more common
/*...=*/ style to improve formatting
The automatically generated code under swig/ was skipped.
Bug: 433996651
Change-Id: Iea3f24160d78d2a2653971cdf13fa932e47ff1b3
The macros in src/utils/bounds_safety.h exist to ensure libwebp
stays portable. This also provides wrappers around common functions like
memcpy/memset/memmove, which are useful as part of the migration. Memcpy
(et al.) wrappers aren't expected to exist forever, and can be removed
after the codebase is fully annotated.
There's some complexity here due to the number of states we need to
support:
1) Off everywhere
2) Building libwebp (some or all) with -fbounds-safety
3) Linking against libwebp that was built with -fbounds-safety
4) Inter-operation with C++
Change-Id: I789f0a94f25b70cab172d5b3f5e6b12de3a34bb4
And provide a clear comment explaining why the index of offset[] is
always checked within bounds.
Bug:webp:622
Change-Id: Id9b973a804b74c53dfb291f1a9dae649c0daed9d
This is a refinement of
654bfb04 Avoid nullptr arithmetic in VP8BitReaderSetBuffer
and removes an unneeded/redundant check in 2 of the 3 calls to this
function:
* VP8InitBitReader: `start` is guaranteed to be non-NULL
* CopyParts0Data: `start` is allocated and checked
In `DoRemap()` `last_start` will be NULL before the partitions are
parsed. This is the only call that was missing a check. The offsetting
of a NULL pointer in `VP8BitReaderSetBuffer` was harmless in this case
as the bitreader will not be used meaningfully until there is enough
data to begin decoding partition 0. In that case the bitreader will be
initialized by `ParsePartitions()` and updated by `DoRemap()` when more
data is available.
Bug: 393104377
Change-Id: Ib44bc35e00e5129c592d742a2469420cd3d0e858
Semi-automatically taking the the misc-include-cleaner warnings
by clang-tidy and fixing files to be self-contained.
Change-Id: Iaaa2b2ec9d6dcce547fa5cb6b4f056dfc8c781ff
This is a follow up to:
ee8e8c62 Fix member naming for VP8LHistogram
This better matches Google style and clears some clang-tidy warnings.
This is the final change in this set. It is rather large due to the
shared dependencies between dec/enc.
Change-Id: I89de06b5653ae0bb627f904fa6060334831f7e3b
This is a follow up to:
ee8e8c62 Fix member naming for VP8LHistogram
This better matches Google style and clears some clang-tidy warnings.
Change-Id: Ie2f82401e1ba28bd0575b6bb82d12ed55c71718f
This is a follow up to:
ee8e8c62 Fix member naming for VP8LHistogram
This better matches Google style and clears some clang-tidy warnings.
Change-Id: Ib58d676fa79c5a4a95c676a98b62b548097f3c48
This is a follow up to:
ee8e8c62 Fix member naming for VP8LHistogram
This better matches Google style and clears some clang-tidy warnings.
Change-Id: Ia4ce0fd0095f76f7edbc0fc6fe7f625e0d8bc6df
This is a follow up to:
ee8e8c62 Fix member naming for VP8LHistogram
This better matches Google style and clears some clang-tidy warnings.
Change-Id: Ice1edbbd98172a916be6b6d3cdaff80fe05a6e37
When WebPSafeMalloc fails on VP8LHuffmanTablesAllocate,
next is not initialized to NULL.
VP8LHuffmanTablesDeallocate uses next to know the following nodes.
A patch fixes this issue.
Change-Id: I144ae84cd97e5bca227018ef1afa95361267902c
First, BuildHuffmanTable is called to check if the data is valid.
If it is and the table is not big enough, more memory is allocated.
This will make sure that valid (but unoptimized because of unbalanced
codes) streams are still decodable.
Bug: chromium:1479274
Change-Id: I31c36dbf3aa78d35ecf38706b50464fd3d375741
and define it to true for __aarch64__ and Win Arm64 + Visual Studio.
Microsoft's compiler (cl.exe) does not define __aarch64__, but relies on
_M_ARM64 & _M_ARM64EC
Bug: b/277254922
Change-Id: I20e4fa07a4031599db69e3d7ba9050345315ef51
clears a warning of the form:
implicit conversion from type 'int' of value -1 (32-bit, signed) to type
'uint32_t' (aka 'unsigned int') changed the value to 4294967295 (32-bit,
unsigned)
Bug: b/229626362
Change-Id: I397fbd59bd3e6d787fcec1344b6230958b28d22c
clears warnings of the form:
implicit conversion from type 'int32_t' (aka 'int') of value -1 (32-bit,
signed) to type 'unsigned int' changed the value to 4294967295 (32-bit,
unsigned)
Bug: b/229626362
Change-Id: I956671d4fee482c97c67bbe94032a97da49b0f6d
this fixes runtime warnings with clang -fsanitize=integer when using the
WEBP_ALIGN_CST constant in WEBP_ALIGN:
implicit conversion from type 'int' of value -32 (32-bit, signed) to
type 'unsigned int' changed the value to 4294967264 (32-bit, unsigned)
Bug: b/229626362
Change-Id: I524d80e620b9869de4e6d322b7de6ffa1ec8657f
and use it in calls containing _mm_cvtsi32_si128; this calls
WebPUint32ToMem, but corrects the type to avoid runtime warnings with
clang -fsanitize=integer of the form:
implicit conversion from type 'int' of value -1904123502 (32-bit,
signed) to type 'uint32_t' (aka 'unsigned int') changed the value to
2390843794 (32-bit, unsigned)
Bug: b/229626362
Change-Id: I20545e822d8045fa44f688241879206055a0a148
and use it with calls to _mm_cvtsi32_si128 and _mm_set_epi32; this calls
WebPMemToUint32, but corrects the type to avoid runtime warnings with
clang -fsanitize=integer of the form:
implicit conversion from type 'uint32_t' (aka 'unsigned int') of value
2155905152 (32-bit, unsigned) to type 'int' changed the value to
-2139062144 (32-bit, signed)
Bug: b/229626362
Change-Id: I50101ba2b46dfaa852f02d46830f3511c80b02d9
It's self contained apart from a dependency on src/webp/types.h and src/dsp/cpu.h
For now it's only set up as an internal library, not an installable one.
Webp doesn't depend on it yet, the code is only duplicated.
Change-Id: I752799894f9d4105d0d296ddebd9f9641181a1ec
- prefer https
- metadataworkinggroup.org/com seem to be offline; the web archive link
was obtained from exiftool: https://exiftool.org/TagNames/MWG.html
- fix kramdown link, rubyforge has been gone a long time
- fix png/zlib links
Bug: webp:544
Bug: b/202302177
Change-Id: Id69de4553e7baf00393f12a2c1acb262443a1a93
similar to '* const', __restrict needs to be included in the
declaration to avoid warnings like:
src\dsp\alpha_processing.c(429): warning C4028: formal parameter 1
different from declaration
this change also moves WEBP_RESTRICT to dsp.h to avoid a circular
dependency between it and utils.h which already includes dsp.h
Change-Id: Ib070d358a372e76fae4be5445ab288940b9baac0
this can help with some aliasing issues with some versions of clang/gcc,
similar to:
3e265136 Add WEBP_RESTRICT & use it in VP8BitReader
Change-Id: I863e53cc9d707c9a4b21373ca743c3089aed012e
Marking the `VP8BitReader` as `__restrict__` helps the compiler generate
better code avoiding issues related to aliasing (re-loads/stores).
Change-Id: Ib7178f57e27e5f40572efc3e567cdf994ea6d928
this will avoid the potential for some integer overflows in rescaler
calculations
Bug: chromium:1196850
Change-Id: Iaa09f5d6b888b39aaeb2154d470279620362d6eb
in addition to checking the environment for "MALLOC_LIMIT"; the
environment will still take precedence.
this is in preparation for adding extreme config value coverage to
advanced_api_fuzzer
Bug: chromium:1196850
Change-Id: Ibe22f5e39e030a422fd6e383269bde35252d3fae
large values of x_add and y_add may rollover an int causing a later
assertion to fail in WebPRescalerExportRow due to fxy_scale incorrectly
being set to 0.
fixes:
src/dsp/rescaler.c:178: void WebPRescalerExportRow(WebPRescaler *const):
Assertion `wrk->src_height == wrk->dst_height && wrk->x_add == 1'
failed.
Bug: chromium:1196480
Change-Id: I2c00f015d61a1257033d8edb1edd4d060d6878b7