3 ms·
I've seen variations of the below in just about every codebase I've worked in. Just ran it through GCC, Clang and MSCV(W4) with no warnings ;). #include <vec
by vvanders 10y ago
I've seen variations of the below in just about every codebase I've worked in. Just ran it through GCC, Clang and MSCV(W4) with no warnings ;).
#include <vector>
int main()
{
struct Foo {
int bar;
};
Foo* bar;
{
std::vector<Foo> foos;
foos.emplace_back(Foo{1});
foos.emplace_back(Foo{2});
bar = &foos[1];
}
bar->bar = 2;
}
- Const-me 10y agoTrue, found similar bugs in my own C++ code, and I read and fix all warnings. However, I never spent more than 10 minutes fixing that. Debug version of MS C runtime fills freed heap memory with a magic number 0xFEEEFEEE. You’ll get exception in runtime, and you’ll immediately have the idea what’s wrong with the code.
- vvanders 10y agoYeah, this is a trivial example. It becomes trickier when you start dealing with things across library boundaries where you might not have source code. I've seen 5 minute fixes and things that took weeks to track down(yay for non deterministic repros).
- pjmlp 10y agoBack when I was doing C coding in the early 2000's I have spent around one week tracking down a server crash caused by a bad pointer. Technical support guys were not that happy with the customer regularly calling them to know when the fix would be delivered. Have other war stories about tracking down leaks as well.
- Const-me 10y agoIt’s hard to debug a library without the source code. This is irrelevant to what language was that source code in, C++ or Rust.
- vvanders 10y agoYeah but we're talking about lifetime bugs here. In the case of Rust they are encoded in the function signature so you don't have to rely on convention or documentation.
- Const-me 10y agoIn most cases you have the source code you’re building. Combined with some stuff in C runtime, this pinpoints the C++ problem nearly as accurately as Rust’s compiler would. Most commercial libraries are written in C or C++. The reasons include performance, smaller runtime, and ease of use (all OS kernels are written in C, so the majority of languages already feature decent C interop). Even if you code Rust, you won’t have that compile-time checks inside proprietary third-party libraries.
- vvanders 10y agoSo if I can summarize: If you don't use Rust you won't see the benefits of Rust? ;) FWIW it's getting pretty common in the Rust ecosystem to wrap 3rd party libs with proper lifetime annotations with opaque types when possible. Things like OpenGL, JNI bindings and whatnot can still benefit from lifetime annotations the compiler provides.
- Const-me 10y agoI’d summarize in a different way. Rust proponents often overestimate practical impart of those C++ safely problems fixed by Rust. At the same time, they often underestimate or ignore Rust’s problems caused by the same safety thing. The main of which is, it’s hard to implement some widely used data structures in Rust. Here’s my old thread where I discuss the topic in details: https://news.ycombinator.com/item?id=11977247 https://news.ycombinator.com/item?id=11977247
- pcwalton 10y agoAll the exploitable UAFs in shipping browser engines for years and years are a strong counterexample to the idea that UAF isn't a problem in modern C++.
- dman 10y agoOut of curiosity - do the codebases for modern browser engines routinely get subjected to static analysis tools and runtime tools like asan (Address sanitizer) / valgrind? Are there categories of UAF that would not be caught with valgrind / asan? Or is it the case that the test suites do not have sufficient coverage to exhibit the issues?