Earlier quoted context omitted.
I see your UAF and raise you a bleed! As you know, buffer bleeds like Heartbleed and Cloudbleed can happen even in a memory safe language, they're hard to defend against (padding is everywhere in most formats!), easier to pull off than a UAF, often remotely accessible, difficult to detect, remain latent for a long time, and the impact is devastating. All your RAM are belong to us. For me, this can of worms is the one…
Has an exploitable buffer bleed (I'm happy with this coinage!) happened in any recent memory safe codebase?
How safe is Zig?
171–180 of 259 posts
Re: How safe is Zig?
#172Earlier quoted context omitted.
That's just a logic error, and not memory unsafety which might risk UB or vulnerabilities. The type system enforces that if we use-after-"free" (remember, we're not free'ing or malloc'ing), we just get a different instance of the same type, which is memory-safe. You do bring up a valid broader concern. Ironically, this is a reason that GC'd systems can sometimes be better for privacy than Ada or Rust which uses a lot…
If you are holding indexes to a collection and plan to delete elements you will never use Vec. There are dedicated data structures for this [1] that will not let you access another item by mistake. [1] https://crates.io/crates/slotmap
You should never use Vec in that situation, but we see it all the time. People love indexing into Vecs and reusing elements.
One of my favorite alternatives is generational_arena [0] which also happens to be the library that inspired Vale's generational references!
[0] https://docs.rs/generational-arena/latest/generational_arena...
Re: How safe is Zig?
#173Earlier quoted context omitted.
In Java, you can hold onto a reference to the UserAccount directly, for as long as you want. The borrow checker, however, forces you to hold onto an index instead.
Right, it sounds like you are circumventing the borrow checker and then experiencing some of the classes of bugs it was supposed to prevent. And this seems common: https://www.youtube.com/watch?v=4t1K66dMhWk
> Circumventing the borrow checker
Programs often require inherent state with data that refers to other data. In these cases, one must circumvent the borrow checker, whether it be with indices, IDs, Rc, or whatever. The borrow checker simply does not allow changing data when someone has a reference to it (except for the rare case where we can use Cell).
It's a myth that we can rewrite any program to not circumvent the borrow checker.
Re: How safe is Zig?
#174Earlier quoted context omitted.
Thanks! I'd love to see a Dlang BetterC column too
Here's a version with D included: https://gist.github.com/pbackus/0e9c9d0c83cd7d3a46365c054129... The only difference in BetterC is that you lose access to the GC, so you have to use RC if you want safe heap allocation.
I guess rust should say "wraps" for integer overflow as well, as that's what it does in default release compile.
Re: How safe is Zig?
#175A meta point to make here but I don’t quite understand the pushback that Rust has gotten. How often does a language come around that flat out eliminates certain errors statically, and at the same time manages to stay in that low-level-capable pocket? And doesn’t require a PhD (or heck, a scholarly stipend) to use? Honestly that might be a once in a lifetime kind of thing. But not requiring a PhD (hyperbole) is not en…
The premise of eliminating entire classes of errors in the abstract is nice and all, and definitely something we should do, but it isn’t the sole deciding factor in choosing an implementation. language:
- If the language is not well known, that’s bad. It will be harder to hire a proficient team. More time will be spent on learning the language. - If the syntax is needlessly verbose, that’s bad. It increases the chance for typos and time spent fixing typos to get things to compile. Eventually it leads to ide completion based programming which results in the degradation of the skill set of the pool of programmers that know that language. - If the concepts the language uses are difficult to manipulate and remember, it takes more time to engage with any given piece of code - If you often need to drop into unsafe modes that’s also not great because now you effectively are using two languages not just one. The safe language and the unsafe language. they interact but play by totally different rules. yikes.
I think rust is a great language and the borrow checker is an amazing innovation. However I think rust has a lot of warts that will harm its success in the long run. I think the next language that leverages the borrow checker idea but does so with a bit better ergonomics will really take off.
Re: How safe is Zig?
#176Earlier quoted context omitted.
> Even in this environment, you can still have dangling pointers to freed stack frames. How frequently does this happen in real software? I learned not to return pointers to stack allocated variables when I was 12 years old. > There's no way around having a proper lifetime system, or a GC, if you want memory safety. If you're building an HTTP caching program where you know the expiration times of objects, a Rust-styl…
>I learned not to return pointers to stack allocated variables when I was 12 years old. So, if you slip while walking today, does that mean you didn't learn to walk when you were one year old?
Your analogy doesn't answer the question. How frequently does this happens in real software?
Re: How safe is Zig?
#177Do compilers really can never call `free()`? Simple compiler probably can. Most complex probably cannot (I don't want to imagine a Rust compiler without freeing memory: it has 7 layers of lowering (source code->tokens->ast->HIR->THIR->MIR->monomorphized MIR, excluding the final LLVM IR) and also allocates a lot while type-checking or borrow-checking). What is most interesting to me is the average compiler. Does someb…
> Do compilers really can never call `free()`? I worked on, one of the many, Microsoft compiler teams, though as a software engineer in test not directly on the compiler itself, and I believe the lead dev told me they don't free any memory, though I could be misremembering since it was my first job out of college. Remember C compilers are often one file at a time (and a LOLWTF # of includes), and the majority of work…
>Related, I miss the insane dedication to quality that team had. Every single bug had a regression test created for it.
Compilers in particular are usually easy to have rigorous regression testing for. Investigating any issue usually forces you to produce a minimal repro because of how complicated a compiler is. Also, all the inputs and outputs are known. Then it's just a one tiny extra step of putting that all together into a checked-in test.
Re: How safe is Zig?
#178So zig has runtime integer overflow protection by default? That's interesting considering Rust lost that battle
Re: How safe is Zig?
#179Earlier quoted context omitted.
> But if Option A has 20 defects and takes a lot of effort to go down to 15 defects, yet Option B has 25 defects and offers a quick path to go down to 10 defects, then which option is superior? Yes. If you change the entire premise of my example then things are indeed different. Rust eliminates some defects entirely. Most other low-level languages do not. You would have to use a language like ATS to even compete. Tha…
I'm not strongly opinionated on Rust specifically but I'm not sure: > Rust eliminates some defects entirely. Is really a true premise, and to the extent it is true, is not a clear to me that it makes Rust better or safer than languages who don't eliminate this class of bugs. Unsafe exists, is widely used, and importantly is used in places where the hairiest versions of these bugs tend to live anyways. For safe code,…
Another dimension to remember here is velocity.
I've worked in heavily monadic Scala codebases where changes in object structure require minor refactors due to strict typing in the codebase. Changes that could be small in other languages would necessitate changes in our monad transformer stacks and have us changing types throughout the project. This eventually lead to engineer anxiety ("small changes take forever so I'm not willing to work on this codebase and explain to my manager why a schema change is taking so long") and aversion to project ownership.
This codebase did materially have fewer defects than other, looser, codebases my team worked with. We got paged fewer times for this codebase than others. Unfortunately, other than a handful of engineers who loved working with monadic FP and were also busy, nobody wanted to touch the code and once the original authors left the team, the codebase went untouched. You could make the case that management should have let these engineers take more time to make these changes but in the meantime, other teams at the company built up high reliability ways of working in other languages and paradigms with higher velocity and similarly low defect rate.
Defects alone aren't everything. You need to look at the big picture.
Re: How safe is Zig?
#180Earlier quoted context omitted.
With Zig and Rust you have to explicitly opt-out with `ReleaseFast` and `unsafe` respectively, that makes a big difference. Rust has the added safety that you cannot (to my knowledge at least) gain performance by opting out with a flag at compile-time, it has to be done with optimized `unsafe` blocks directly in the code. Lazy C++ is unsafe, lazy Zig is safe-ish, lazy Rust is safe. Given how lazy most programmers are…
[dead]
Sure, but unlike C/C++, in Rust my entire codebase is not enclosed in a gigantic unsafe block