3 ms·

Boehm GC's checking mode works fine in C and C++. The reason why nobody uses it has nothing to do with the fact that it's conservative and everything to do with

Boehm GC's checking mode works fine in C and C++. The reason why nobody uses it has nothing to do with the fact that it's conservative and everything to do with the fact that Address Sanitizer is just plain better at solving programmers' needs. ASan is about as good as you can do as far as developer tools that find use-after-free problems in memory-unsafe languages like C/C++/Zig go. It would not be a better tool if it were precise at identifying pointers, because of the inevitable false positives that come with trying to scan the whole object graph for dangling pointers in memory-unsafe languages. ASan got so popular precisely because it tries very hard to avoid false positives. Zig does seem to have some properties that make precise pointer identification possible. But the right conclusion to draw from this is that Zig should use a tracing garbage collector. It's well-known how to use the pointer provenance properties you're talking about to achieve UAF protection: just implement a GC! Trying to get by with things like quarantining memory forever is not going to work in production, and the reasons why Zig programs will supposedly not be vulnerable to UAF problems are unconvincing. It is going to want a GC eventually.

pron 5y ago
> It would not be a better tool if it were precise at identifying pointers, because of the inevitable false positives that come with trying to scan the whole object graph for dangling pointers in memory-unsafe languages. I've repeated several times that I was merely demonstrating why Zig and C are fundamentally different when it comes to pointers. You're trying to poke holes at a straw man, and worse, you're doing that while drawing on the very premise which I'm refuting, i.e. that Zig programs and C programs are essentially the same. You could just as likely have assumed that Zig programs behave more like Rust programs (or Go programs), and at the time of deallocation there is just one pointer to the object, and voila, zero false positives. I am not saying that a Zig program should behave like a Rust/Go/Java program, just that your arguments are begging the question. You start with the assumption that Zig and C are essentially the same and then use the resulting conclusions to shore up that very assumption. But Zig programs are about as different from C as they are from Rust. You insist that if you're not Java or Rust then you must be C. Zig is so revolutionary precisely because it works like none of those. Now, I don't know if Zig's revolutionary design is revolutionarily good. It's far too early to tell. But basing your criticism on a false premise completely misses the mark. Of course, it's okay to be skeptical of a new idea, just as I'm skeptical that a type-level shrine for accidental complexity is the way to go. > But the right conclusion to draw from this is that Zig should use a tracing garbage collector. I disagree, but that's a whole other discussion. But since you seem to claim that such a thing could exist and effectively work for Zig and not for C, it seems you accept both of my points: 1. that pointers in both languages are fundamentally different, and 2. that this can be exploited for analyses that are completely different in their effectiveness than those feasible for C or C++.

pron 5y ago

> It would not be a better tool if it were precise at identifying pointers, because of the inevitable false positives that come with trying to scan the whole object graph for dangling pointers in memory-unsafe languages. I've repeated several times that I was merely demonstrating why Zig and C are fundamentally different when it comes to pointers. You're trying to poke holes at a straw man, and worse, you're doing that while drawing on the very premise which I'm refuting, i.e. that Zig programs and C programs are essentially the same. You could just as likely have assumed that Zig programs behave more like Rust programs (or Go programs), and at the time of deallocation there is just one pointer to the object, and voila, zero false positives. I am not saying that a Zig program should behave like a Rust/Go/Java program, just that your arguments are begging the question. You start with the assumption that Zig and C are essentially the same and then use the resulting conclusions to shore up that very assumption. But Zig programs are about as different from C as they are from Rust. You insist that if you're not Java or Rust then you must be C. Zig is so revolutionary precisely because it works like none of those. Now, I don't know if Zig's revolutionary design is revolutionarily good. It's far too early to tell. But basing your criticism on a false premise completely misses the mark. Of course, it's okay to be skeptical of a new idea, just as I'm skeptical that a type-level shrine for accidental complexity is the way to go. > But the right conclusion to draw from this is that Zig should use a tracing garbage collector. I disagree, but that's a whole other discussion. But since you seem to claim that such a thing could exist and effectively work for Zig and not for C, it seems you accept both of my points: 1. that pointers in both languages are fundamentally different, and 2. that this can be exploited for analyses that are completely different in their effectiveness than those feasible for C or C++.