Date: Mon, 14 Oct 2024 10:54:23 -0700
On Sunday 13 October 2024 13:06:06 GMT-7 Frederick Virchanza Gotham via Std-
Proposals wrote:
> Having a standard library function such as "std::deliberate_leak"
> would serve too functions:
> (1) Stop us wasting time chasing leaks that are benign
> (2) To reduce the clutter in the output from the debugger programs
Having standard suppression files for those libraries would be at least as
effective, if not more. Suppression files can also be used to mark "invalid"
memory accesses that are otherwise benign.
For example, if you write
auto str = new char16_t[7];
memcpy(str, u"Foobar", 7 * sizeof(char16_t)); // include NUL
QStringView v(sr);
that will call an out-of-line function called qustrlen() that will, 100% of
the time (for this string) access out-of-bounds memory and a tool like both
Valgrind and ASan have a right to complain because it is UB in C and C++.
But since I wrote that function with x86 intrinsics -- which is just a
portable way of writing assembly -- I've stepped outside of the language and
written machine code. I know that my code will never crash nor will it use the
data outside of the bounds of the string (before it or past the NUL).
It might have been nice to have a way to mark the function as "I know what I'm
doing" -- I have an __attribute__((no_sanitize_address) there -- but code is
not acceptable here. This is a hot path and I cannot have anything interfere
with codegen in this function.
A suppression file is much easier. And is already possible.
Proposals wrote:
> Having a standard library function such as "std::deliberate_leak"
> would serve too functions:
> (1) Stop us wasting time chasing leaks that are benign
> (2) To reduce the clutter in the output from the debugger programs
Having standard suppression files for those libraries would be at least as
effective, if not more. Suppression files can also be used to mark "invalid"
memory accesses that are otherwise benign.
For example, if you write
auto str = new char16_t[7];
memcpy(str, u"Foobar", 7 * sizeof(char16_t)); // include NUL
QStringView v(sr);
that will call an out-of-line function called qustrlen() that will, 100% of
the time (for this string) access out-of-bounds memory and a tool like both
Valgrind and ASan have a right to complain because it is UB in C and C++.
But since I wrote that function with x86 intrinsics -- which is just a
portable way of writing assembly -- I've stepped outside of the language and
written machine code. I know that my code will never crash nor will it use the
data outside of the bounds of the string (before it or past the NUL).
It might have been nice to have a way to mark the function as "I know what I'm
doing" -- I have an __attribute__((no_sanitize_address) there -- but code is
not acceptable here. This is a hot path and I cannot have anything interfere
with codegen in this function.
A suppression file is much easier. And is already possible.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Platform & System Engineering
Received on 2024-10-14 17:54:25