Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Finding Bugs with AddressSanitizer: Patterns from Open Source Projects

16 views
Skip to first unread message

Real Troll

unread,
May 11, 2021, 8:08:03 PM5/11/21
to
Some of you might be interested in this Microsoft blog:

<https://devblogs.microsoft.com/cppblog/finding-bugs-with-addresssanitizer-patterns-from-open-source-projects/>

I have copied this to C newsgroup as well just in case they are
interested in this.


David Brown

unread,
May 12, 2021, 4:18:46 AM5/12/21
to
An "Address sanitizer" (or related tool) is great for finding run-time
pointer issues. But when problems can be found at compile time, that is
always better.

Looking at the examples, at least some of them /can/ be found at compile
time, and could be avoided by better programming practice.

For example, in their "IoT C SDK" (which is apparently C++, not C), the
mistake in CopyGlobalBuffer is found as a static error by gcc. It could
also be avoided by using sizeof(GLOBAL_BUFFER) instead of BUF_SIZE, or
defining GLOBAL_BUFFER with the right size, or using a static assertion
to confirm the size, or by using a std::array rather than a C array.

The next example with the string and non-matching length should have had
the string defined as a "const char[]" rather than a "const unsigned
char*" pointer, then the length constant should be got by "constexpr
const int twin_len = std::strlen(twin_props)". If they need to check
the size matches a numeric constant, that's what static assertions are for.


Instrumentation and debugging tools are great - but they are not an
alternative to writing decent code in the first place!




0 new messages