Not to mention something that almost any static analyzer will catch on the first run...
Re:MathML in Chromium
by the_why_of_y on Saturday March 09, 2019 @01:12PM
(#19347506)
Can you recommend a static analyzer to Chromium developers? They appear to have problems with basic C++ programming; such a pity that Google cannot afford to hire competent developers like otabdeveloper2.
https://bugs.chromium.org/p/chromium/issues/list?can=2&q=%22...
That's supposed to be a witty retort? Did you bother to read those bug reports you've linked to?
They are already tied to static analyzers, which is how they were found. What do you think the: "Sanitizer: address (ASAN)" or "Issue 938699: AutotestPrivateApiTest.AutotestPrivate getPrinterList failing on ASAN/LSAN" in the bug reports means?
Re:MathML in Chromium
by the_why_of_y on Sunday March 10, 2019 @06:18AM
(#19351292)
I see, you are merely unfamiliar with terminology.
The word "static" refers to compile-time; a static analysis reports errors or warnings based only on the source code of the program.
Sanitizers are dynamic analysis based on instrumentation. https://github.com/google/sanitizers/wiki/AddressSanitizer
The tool consists of a compiler instrumentation module
(currently, an LLVM pass) and a run-time library which
replaces the malloc function.
In order to detect bugs with sanitizers, you have to find a test input that actually moves program execution towards UB. This is best done with a fuzzing setup like clusterfuzz, and lots and lots of CPUs, which Google fortunately has no shortage of.https://github.com/google/clusterfuzz
As Dijkstra said, Program testing can be used to show the presence of bugs, but never to show their absence.
Use-after-free is a C thing, not a C++ thing. Granted, C++ makes is super easy to code in C, but that's an organization problem that is already solved in any sane project.