Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 4477de733d5b3aa1244d05fd21146678c82041a0
https://github.com/WebKit/WebKit/commit/4477de733d5b3aa1244d05fd21146678c82041a0
Author: David Kilzer <[email protected]>
Date: 2026-07-25 (Sat, 25 Jul 2026)
Changed paths:
M Source/WTF/wtf/SegmentedVector.h
Log Message:
-----------
Avoid unix.MallocSizeof static analyzer false positive in
SegmentedVector::allocateSegment()
<https://bugs.webkit.org/show_bug.cgi?id=320260>
<rdar://183185724>
Reviewed by Zak Ridouh.
`SegmentedVector::Segment` is a flexible-array-member handle whose only
member is the trailing `T m_entries[0]`, so a segment is sized to hold
`segSize` elements of `T` and the buffer is reinterpreted as a
`Segment*`. The unix.MallocSizeof checker flags this deliberate
`sizeof(T)` versus `Segment*` mismatch. The checker has no
flexible-array-member exemption, and because it is an AST-based checker
its report is not silenced by `[[clang::suppress]]`, so the suppression
macros from `wtf/Compiler.h` do not apply here.
The checker only inspects a cast that syntactically wraps the
allocation call, so hold the result in its natural `void*` and cast at
the point of use instead. Typed Memory Operations infer the allocation
type from the cast wherever it appears, so this keeps the same
`malloc_type_id_t` the compiler infers today.
Add a `static_assert` that `Segment` adds no header. Nothing else ties
the allocation size to the overlay: were `Segment` to gain a member,
every element would shift past it and the last one would fall outside
the buffer.
No new tests since no change in behavior.
* Source/WTF/wtf/SegmentedVector.h:
(WTF::SegmentedVector::allocateSegment):
Canonical link: https://commits.webkit.org/317919@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
