How Safe Is Zig?

https://scattered-thoughts.net/writing/how-safe-is-zig/

by bshanks • 5 years ago

192 274 5 years ago

oblio2• 5 years ago

Interesting comparison. Long term we badly need something to replace C (or at least minimize its usage drastically), so perfect should not be the enemy of good.

I hope something like Zig gets widespread adoption, including in embedded/IoT/automotive environments. Especially automotive. We're moving more and more life-and-death scenario-type tools into software.

the_duke3• 5 years ago

Considering that Rust exists, I really don't hope that Zig gets much adoption, at least until the language improves a lot in some key aspects.

There definitely is a design space for a simpler language than Rust that is easier to write, but Zig is too far on the side of C and has lots of trivially introducable unsafety. It's an improvement over C , but imo not enough.

fwsgonzo2• 5 years ago

One thing I noticed is that Zig is not 1.0 yet, so perhaps it will still improve in those aspects you are thinking about?

1_player4• 5 years ago

Rust instead is too far on the side of C++

I have tried to like the language, but sadly having to think about types and lifetimes robs precious energy which should be devoted to thinking about business rules and what am I actually trying to achieve.

In some niches Rust is perfect, but in every language thread on HN there's often someone that suggests to use Rust whatever the use case. C, in that respect, is more flexible and gets out of the way much more, of course while being unsafer, but it's easier to keep your mind on the goal and not figuring out the best memory safe approach for this piece of logic.

Which is why I'm very excited for Zig. I don't want another C++. Give me safer C, thanks.

orthoxerox2• 5 years ago

Right. It's a better C, but it has to compete with C's ubiquity: there's make and cc on most *nix boxes.

JetBrains went out of their way to make migrating to Kotlin as easy as possible: you can literally upgrade your Java project file by file.

ttt0• 5 years ago

I personally don't care about Rust at all, I already have C++ for that. But I'm very interested in Zig.

roca• 5 years ago

We are, and I hope for life-and-death situations people are willing to work a little bit harder to get the extra protections Rust provides ... or much harder, and formally verify their code in which the language you use no longer matters as much.

10000truths• 5 years ago

Previous thread: https://news.ycombinator.com/item?id=26527848

childintime• 5 years ago

https://news.ycombinator.com/item?id=26521539

quietbritishjim9• 5 years ago

From the table:

null pointer dereference ... [C] none; [Zig] runtime; [Rust] runtime

Assuming this is talking normal "safe" Rust, I think I disagree with this. The Rust analogue of a pointer in safe code is a reference, not a Rust pointer, and these can't null at all. You could use an Option<> of a reference, and Rust will internally use null to represent the None (empty) case, but an attept to use the option without checking for None will result in an error at compile time, not runtime. Yes you could convert that into a runtime error, but if it was an error condition for that variable to be None then (depending on the context) you could choose not to use an Option at all and then it would be a compile-time error at the call site to attempt to put None into it.

I don't think I understand what is meant by "type confusion". Surely this would also cause compile-time errors? Even C++ would give compile time errors for this unless you use a cast! (C, unlike C++, lets you implicitly convert from void* to any other pointer type so you don't need a cast to get pointer confusion.) Could someone think of an example of what might be meant here, and how it would cause a runtime error?

the_duke3• 5 years ago

Zig has a nullable pointer type, which will have null checks. But only in ReleaseSafe build mode, and it's trivial to construct a non nullable pointer that is null or uninitialised.

So I agree with your disagreement.

quietbritishjim9• 5 years ago

I'm not familiar with Zig, and I'm afraid I didn't quite follow your comment. Are you saying that "runtime" should instead be "none" for Zig?

jamii8• 5 years ago

it's trivial to construct a non nullable pointer that is null or uninitialised

This is checked at runtime in ReleaseSafe.

    jamie@machine:~$ cat test.zig
    pub fn main() void {
        var x: usize = 3;
        _ = @intToPtr(*u32, x - 3).*;
    }
    jamie@machine:~$ zig run test.zig -OReleaseSafe
    cast causes pointer to be null
    Aborted (core dumped)

(The x-3 is because if you use a literal 0 it gets caught at compile time)

creata2• 5 years ago

Another (much smaller) detail is that signed overflow in C is undefined (and iirc GCC takes advantage of that when optimizing) but signed overflow in Rust is precisely defined to error in debug mode and wrap in release mode.

edflsafoiewq3• 5 years ago

And unsigned overflow is also error-in-debug, overflow-in-release with Rust. If you want wrapping arithmetic, you have to ask for it. In C, unsigned overflow always wraps, so even though you can compile with overflow checks, there's no way to distinguish unsigned arithmetic that is supposed to vs not supposed to wrap.

dgellow5• 5 years ago

So, how do professional C programmers deal with this in general? Do they manually check for `x > MAX_INT || x < MIN_INT` every time they want to do some arithmetic? Do they manually check the CPU overflow flag after an operation? Or something else?

(I only have limited C experience, and only for hobby projects)

tsimionescu2• 5 years ago

I don't think I understand what is meant by "type confusion". Surely this would also cause compile-time errors? Even C++ would give compile time errors for this unless you use a cast! (C, unlike C++, lets you implicitly convert from void* to any other pointer type so you don't need a cast to get pointer confusion.) Could someone think of an example of what might be meant here, and how it would cause a runtime error?

Given the foot-notes, I think they are referring to unions - probably writing to one union member but reading through another (e.g. uni.intVariant = 19; float a = uni.floatVariant).

I don't personally know how Rust and Zig handle this,I believe it is UB in C.

saagarjha9• 5 years ago

It's actually defined as doing a type pun on the bit representation, interestingly. (The history of this specific behavior is somewhat complicated–it wasn't always clear-cut what this did.)

quietbritishjim9• 5 years ago

I think they are referring to unions - probably writing to one union member but reading through another

Thanks, you could be right. In that case, I think it ought to be listed as a compile-time rather than a runtime error too (just as I already argued for null pointer dereference).

It depends a bit on use of course: if you have a function that takes an enum and considers all cases using pattern matching, then the compiler will stop you from accessing the wrong member within a given case. If you pass an enum to a function that expects one particular case to be active, then yes you can convert the compile time error into a run time one, but this is your own choice, not something that is naturally a run time error.

The_rationalist5• 5 years ago

I think it's fairly common in rust code to abuse unwrap and such behaving exactly like an unchecked access to a nullable type.

Ygg22• 5 years ago

That's the opposite of true. Unwrap is heavily discouraged. I know for Result there is `?` operator, but I don't remember if that worked on Option.

staticassertion2• 5 years ago

They're definitely not the same at all. Dereferencing a null pointer in C and C++ is undefined behavior. You can read more about it here: https://rootkits.xyz/blog/2018/01/kernel-null-pointer-derefe...

In rust an unwrap of a None is defined and memory safe.

Ar-Curunir2• 5 years ago

There's a difference between a value being null, and a pointer being null. While Rust disallows both, it handles the cases differently; for the latter, a Rust program containing only safe Rust cannot create "null" references. However, for a "nullable" type, Rust encourages using `Option`, and forces you to handle the `null`/`None` case via a check.

Blikkentrekker• 5 years ago

but an attept to use the option without checking for None will result in an error at compile time, not runtime. Yes you could convert that into a runtime error, but if it was an error condition for that variable to be None then (depending on the context) you could choose not to use an Option at all and then it would be a compile-time error at the call site to attempt to put None into it.

This wording still suggests that it is a null pointer error reference, which is technically u.b., but in practice on any modern operating system a segmentation fault, but that is not what happens in Rust.

Rather, an optional reference cannot be dereferenced at all ere it be converted to an actual reference, typically with appropriate guards for the None-case, it is true that there is a way to convert an optional value of type `T` to type `T` without handling the None-case, but that is simply a trivial library function that handles the None-case by panicking the thread. The None-case must technically always be handled in some way in safe code.

The distinction is rather meaningful, I would say, as it is not the null pointer dereference stage where the error occurs, but the panicking of the thread of attempting to convert a None-case, which not only happens before that point, but provides for far cleaner debug information.

In safe Rust, one simply cannot dereference an optional reference, one can only coerce it to a reference, with the understanding that this operation panics the thread in the None-case. — an optional reference in Rust is not a “reference” at all as it is in other languages with special support for it.

jamii8• 5 years ago

I don't think I understand what is meant by "type confusion".

Accessing a memory location with one type as if it's another. In C or C++ it's usually because you accessed a union without checking a tag somewhere else.

One classic way this happens is in an interpreter where you have a big enum for all the different possible data types:

https://github.com/MaterializeInc/materialize/blob/1b9b3cfab...

And then in various builtin functions you expect particular types:

https://github.com/MaterializeInc/materialize/blob/main/src/...

In rust and zig this code will produce a runtime error if you screw up, but in c it's easy to forget to check the tag and then you get UB. Similarly unwrap is checked in rust and zig but the equivalent in c - dereferencing a pointer that you are pretty sure is not null - is not.

Of course rust and zig both have support for c-style unions too, but they're not the first thing people reach for.

quietbritishjim9• 5 years ago

Thanks for answering. As I said in another comment (in reply to another tsimionescu who suspected that's what you meant), I maintain that this is a compile time error. Yes, one usage is to panic if the contents of the enum is not what you expect, in which case an unexpected type causes a runtime error. But that is the programmer choosing to deal with it way.

Fundamentally in the language, mismatching type is a compile time error. In many situations it's feasible to exhaustively match and deal with all possible cases of an enum (which then causes a compile time error if you try to reference one of the other inner types from within the "wrong" case). Where one particular case is expected, you can often ensure through the type system that this case is the only possibility by using that individual type directly rather than passing that enum around. In some situations its not feasible or it is feasible but the extra faff isn't worth the reward - but even then I don't think it justifies saying that the type confusion is detected in runtime in a comparison of languages.

tsimionescu2• 5 years ago

In rust and zig this code will produce a runtime error if you screw up, but in c it's easy to forget to check the tag and then you get UB.

As pointed out elsewhere, somewhat surprisingly, this is not UB in C, though it is in C++. In C it is merely unspecified behavior, but perfectly safe if intended.

flohofwoe• 5 years ago

One thing that's important to note is that Zig in general enforces much more correctness than C and also has much better stdlib APIs. IME many memory corruption issues in C (and C++) are actually "secondary effects" of C's and C++'s general "sloppiness" and bad stdlib APIs.

One thing I found where Zig is currently worse than C compilers: returning a pointer to a stack variable generates a warning in "modern" C and C++ compilers, while Zig lets this slip through. I hope that "trivial" things like this will be fixed on the way to 1.0

Rendello2• 5 years ago

I ran into this in Zig and I was surprised that it wasn't caught. Since I'm newer to lower-level programming I didn't automatically think to look for this and I was lost for a day or two

AndyKelley3• 5 years ago

We're working on this one- it requires careful cooperation with the language specification to make it legal to be a compile error.

fwsgonzo2• 5 years ago

I don't have much experience with Zig, but one thing that stuck out to me was that I was able to build for RISC-V with a one-liner. I didn't have to change or do anything at all to make this happen. That's so cool.

In contrast, I have yet to be able to build any RISC-V binaries with Rust. It just doesn't work. Sure, I could see some potential things like writing a custom JSON to describe the env and maybe build using a cross-compilation toolchain. But after a certain amount of time and no answers, it was not worth my time anymore.

https://stackoverflow.com/questions/64308644/rust-unable-to-...

If you think you have the answer ^

pansa25• 5 years ago

Temporal memory safety and data race safety. [...] Unique to rust. [...] add a significant amount of complexity to the language.

Rust seems to be a very complex language. Is all that complexity essential to providing memory safety without GC? Or would it be possible to have a significantly simpler language that is equally safe? A language that’s “safe & C-like” compared to Rust’s “safe & C++-like”?

EwanToo• 5 years ago

You can write very simple Rust, it's worth trying it out if you haven't already.

I'm not a rust developer, but I've ported over a handful of python or golang projects to see how it works. I managed to write the code without understanding much about things like the borrow checker.

I'm certain my code is not as performant or elegant as it could be using some of the more complex tools and concepts in the language, but it is possible.

adrianN2• 5 years ago

"You can write <adjective> <programming language>" is an answer that usually get rebutted by pointing out that a) you need to read a lot more code than you write and b) other people might not write <adjective> code or c) other people might have a different definition of <adjective>.

pansa25• 5 years ago

I'm certain my code is not as performant

If you don’t need maximum-possible performance, though, why use Rust/C/C++ at all? Wouldn’t a better choice be Go/Java/C#?

IshKebab2• 5 years ago

You can write very simple Rust

Technically true, but only really true if you don't use many dependencies. At some point you're going to use some dependency that uses async/await all over the place or really goes wild with generics and then it is definitely not simple.

Two examples:

* Heim (https://docs.rs/heim/0.0.11/heim/) is a great crate for getting system info, but it only uses async/await so you are thrown into that rather painful world even if you don't need it.

* Plotters (https://github.com/38/plotters) is a pretty great graph plotting library for Rust (the only one as far as I know), but they have definitely gone a bit overboard with the generics. Want to draw a scatter graph?

I tried simply calling `PointSeries::new()` and got a basically impossible-to-follow error about Rust not being able to infer the type `E` here:

https://github.com/38/plotters/blob/master/src/series/point_...

Very simple it is not!

Measter• 5 years ago

Well now I'm (morbidly?) curious what your Rust code looks like.

ivanbakel2• 5 years ago

Rust seems to be a very complex language. Is all that complexity essential to providing memory safety without GC?

The language features specific to memory safety i.e. the borrow checker, are essentially irreducible. It is also Rust's biggest piece of complexity, and the one that is hardest to learn. There is no simpler language inside Rust that has the same safety guarantees, unless you strip out other useful features (traits, async, etc.).

pansa25• 5 years ago

There is no simpler language inside Rust that has the same safety guarantees, unless you strip out other useful features (traits, async, etc.).

This sounds like “there is no simpler language inside C++, unless you strip out useful features (classes, templates, etc.)”. Yet C exists.

So there could be a simpler language with Rust’s safety guarantees if you were willing to strip out traits, async etc?

afavour2• 5 years ago

There is no simpler language inside Rust that has the same safety guarantees

I’d argue there is: there’s reference counting. Rather than using references and fussing with lifetimes you could sprinkle Rc<> wherever it’s necessary. You’d take a performance hit but the code would be simpler to write.

pjmlp14• 5 years ago

Object Pascal and Modula-2 would be already much safer than plain C, although you still suffer from use-after-free errors.

Then there is Ada, but it is in the same complexity level as C++, although much easier than Rust.

moltonel3x2• 5 years ago

I don't have enough Ada experience to compare, but Rust is IMHO much easier and less complex than C++. Rust is renowned to have a steep initial learning curve, but that curve doesn't climb nearly as high as C++'s.

Snetry• 5 years ago

In the recent latest Zig Showtime stream Andrew showed off things like use after free, double free and so on detection

The_rationalist5• 5 years ago

The matrix is incomplete: What about use after returns? Memory leaks? Cycles? Stack under/over-flows

pron13• 5 years ago

One thing that's important to emphasise: sound safety, i.e. using a safe language, is no one's goal; rather, it is a means to end. What people want is correct programs. The question is, then, does a language help write correct programs?

Ensuring safety from important classes of bugs with sound guarantees is one way to help write correct programs, and both Zig and Rust use it; ensuring safety from from important classes of bugs with sound guarantees based on runtime checks is another way, and both Zig and Rust do it, too; a simple language that's easy to understand and analyse is another very important way to help write correct programs, and both Zig and Rust try to be simpler than their predecessors; making it easy to write tests and run them frequently is another way to get more correct programs that both languages try to employ. Both languages drastically differ in the use of those techniques from either C or C++ because they are both languages that put a very strong emphasise writing correct programs, but they also differ a lot from each other in how they balance those techniques.

It is impossible to tell without careful empirical research which helps write correct programs more than the other, and it is also possible that different people find it easier to write correct programs in either Zig or Rust. Rust certainly provides stronger guarantees that prevent temporal memory bugs than Zig, so let's assume Rust programs will contain zero, and a Zig program will contain more than zero but much less than C or C++. But that delta is insufficient to determine that Rust's balance of techniques reduces more bugs overall.

Also, Zig already has decent checks for use-after-free, and they'll get better, and not having uninitialised memory is also very easy to do (and verify) in Zig, despite there not being any checks. Even if, like other runtime checks, it is turned off in production, it still helps catch errors in that category.

HourglassFR3• 5 years ago

I've seen you make that argument a few times on Zig related discutions but I'm not sure I buy it. It essentially boils down to: simpler language => easier to reason about and build tools for => less bugs.

While the thought as merits, the empirical evidence we have indicates that yes it is possible to achieve good software with faulty languages with strong rules and tooling but it is certainly not as straightforward as you make it seem.

In the end though, for the Zig case I agree that the jury is still out. But if I was a betting man, my money would not be on it, even though personnaly prefer Zig.

mtzet2• 5 years ago

You're also forgetting: simpler language/explicit code => faster build times. Zero-cost abstractions are only zero-cost in optimized builds and and complex optimization isn't free.

Whether static checking vs faster iteration time is more important depends entirely on the context, but rust isn't going to help you when you accidentally did front-face culling instead of back-face culling.

pron13• 5 years ago

but it is certainly not as straightforward as you make it seem.

I never claimed it is straightforward; it is anything but. As a practitioner and advocate of formal methods and verification, I've been following research in software correctness for many years (and have written much about it, e.g. https://pron.github.io/posts/correctness-and-complexity), I've come to realise how complex the problem is, and there's more we don't know than we know, and even the things we know are problems, we don't know what the best solution is, because often solutions carry with them more problems.

Nonetheless, there are certain principles. We know that we can eliminate certain bugs with compile time guarantees; we also know that code reviews catch many (many!) bugs, and so making them easier helps. But what if these two are in opposition? It's not easy to tell which wins in which circumstances.

In the end though, for the Zig case I agree that the jury is still out.

True, but the jury is still out on Rust, too. In fact, for most languages. However, there is no clear argument that we should assume, a priori, that Rust results in more correct programs than Zig. Many such arguments in the past have failed to yield positive empirical results (e.g. https://youtu.be/ePCpq0AMyVk). In fact, given empirical research, the safest bet is to assume the null hypothesis -- that there is no difference. Out of an abundance of caution, I'll assume that languages whose designers place a strong emphasis on correctness might achieve it more easily than languages whose designers put no emphasis on it at all, but Zig and Rust are in the same category here. Both are designed with correctness as a primary goal. But as their design and means of achieving correctness is so different, I think it's impossible to make an educated guess as to which of them, if any, yields more correctness more easily.

If we want some bottom line, it is this: software correctness is so complex, and solutions are often so non-obvious (i.e. many work in theory but not in practice), that we cannot say anything with certainty until we have actual empirical results, and even then we need to be careful not to be careful not to extrapolate from one study to other circumstances with different conditions (i.e. that TypeScript seems to have fewer bugs than JavaScript does not seem to extrapolate to the general claim that typing always reduces bugs compared to no typing in the same amount or at all, when other languages are concerned).

lmm• 5 years ago

What people want is correct programs.

At first order not even that; what people want is programs that behave correctly (or correctly enough for their purposes, which may not be very correct at all) for their particular inputs and execution environment.

Conversely those of us who want the industry to advance the state of the art generally don't want to just produce correct programs at a particular point in time, but programs whose correctness can be easily maintained even as implementations and requirements change. More than that, we want to produce libraries and frameworks that will lead as-yet-unknown programs to be correct.

pron13• 5 years ago

what people want is programs that behave correctly (or correctly enough for their purposes, which may not be very correct at all) for their particular inputs and execution environment.

Ah, yes. This raises an interesting philosophical question with real ramifications for software quality assurance: is a bug in the algorithm that never manifests in the system really a bug? Something like that happened in two well-used pieces of code: There was a bug in the TimSort algorithm used in both Java and Python, whose probability of actual failure is similar to the probability of failure due to a bit flip caused by cosmic rays. Because hardware can only be correct with probability, no running system can be soundly verified, i.e. with certainty, anyway, so while the correctness of algorithms can be absolute, the correctness of system cannot. And since soundness has a big cost in verification, many in software correctness research now focus on unsound techniques that are cheaper.

Conversely those of us who want the industry to advance the state of the art generally don't want to just produce correct programs at a particular point in time, but programs whose correctness can be easily maintained even as implementations and requirements change. More than that, we want to produce libraries and frameworks that will lead as-yet-unknown programs to be correct.

True, but that is not a winning argument for soundness. The cost of soundness manifests even at maintenance. It's therefore an equally strong argument that a language that compiles quickly and more easily allows running, say, concolic tests, mutation tests etc., serves that goal, too.

pjmlp14• 5 years ago

From my point of view until Zig fixes the issues marked as none on the table, it adds very little value to existing alternatives.

I can already use C and C++ to suffer that in production, use VC++ static analysers to mitigate them, while languages like Ada, D, Rust, Nim, Swift take care of them not happening at all.

pron13• 5 years ago

Zig's safety is not at all like C's (or even C++'s), even with static analysers and sanitisers. It is core to the language through things like slices and nullability types. What Zig brings to the table is an extremely powerful and expressive, yet remarkably simple language that places as much emphasis on correctness as Rust (albeit in a radically different way).

mtzet2• 5 years ago

I think this is a roughly fair assesment, but I also think it's important to contextualize memory safety. Ultimately, the goal here is to produce /correct/ software. Memory safety is a subset of this, but there are other aspects to correctness as well.

I really like zig's approach of explicitness and fast iteration cycles. Fast compile times and the very flexible build system makes me hopeful for a really slick workflow for embedded development,where zig code can be used to deploy and test as well. For my own use I think it's a clear win.

On the hand, the amount of damage poorly architected zig code can cause is about as large as for poor c code. For typical enterprise code the rust compiler will make sure that many bad decisions will not even compile. There's still a risk of towering abstractions, but at least I could avoid spending as much time debugging hideous race conditions.

_vvhw13• 5 years ago

It's important to clarify that memory safety is only one aspect of writing safe, secure software.

To this list then I would also want to add and compare: OOM-safety under overload conditions, and fine-grained error handling safety, in particular because error handling tends to be one of the leading causes of faults in distributed systems [1].

To be fair, I was surprised that Rust did not have checked arithmetic on by default and that this needs to be turned on via compiler setting or linted against. The presence of integer overflow in a program can facilitate a whole range of exploits, even with memory safety.

[1] https://www.eecg.utoronto.ca/~yuan/papers/failure_analysis_o...

littlestymaar13• 5 years ago

The presence of integer overflow in a program can facilitate a whole range of exploits, even with memory safety.

Do you have examples that do not involve array indexing? (which are uncommon in Rust because iterators exist and are faster).

_vvhw13• 5 years ago

Sure, almost anything that uses numbers, e.g. to control access or parse data structures or do "something important", here are two off the top of my head:

* Rate limits for an OTP, which could be trivially reset through overflow.

* Parsing zip files, where the hostile content is self-referencing, to sneak in cyclic references for a DoS, or to change file extension type for code execution after bypassing a content filter, or to change output destination (e.g. as part of a symbolic link or directory traversal) to overwrite system files.

Unchecked arithmetic for me is by far one of the scariest exploit vectors because it's so easy to do, and one of the first things a trained attacker would look for.

Programs in any language are always exploitable, in some way or another. Memory safety is no guarantee that a program is "safe" let alone correct.

quietbritishjim9• 5 years ago

memory safety is only one aspect of writing safe, secure software

A good example of this is the SQLite documentation page "Why Is SQLite Coded In C". Among other things, it describes those memory safety issues as "the easy problems" compared to "the rather more difficult problem of computing a correct answer to an SQL statement".

Not all of our programs are like SQLite, of course (and not all of us mere mortals are like its developers). But I would certainly say that just because you've eliminated memory safety bugs doesn't mean you've eliminated all bugs. Depending on the program, you might not even have eliminated most bugs.

[1] https://www.sqlite.org/whyc.html

_vvhw13• 5 years ago

There's always a new treasure to be found in the SQLite documentation. Thanks for the link.

jamii8• 5 years ago

Despite being an 'easy problem' it has led to code execution on android/ios:

https://research.checkpoint.com/2019/select-code_execution-f...

We established that simply querying a database may not be as safe as you expect. Using our innovative techniques of Query Hijacking and Query Oriented Programming, we proved that memory corruption issues in SQLite can now be reliably exploited. As our permissions hierarchies become more segmented than ever, it is clear that we must rethink the boundaries of trusted/untrusted SQL input. To demonstrate these concepts, we achieved remote code execution on a password stealer backend running PHP7 and gained persistency with higher privileges on iOS. We believe that these are just a couple of use cases in the endless landscape of SQLite.

nerdponx• 5 years ago

I found this part about Rust at the end particularly interesting:

All that said, it is possible that SQLite might one day be recoded in Rust. Recoding SQLite in Go is unlikely since Go hates assert(). But Rust is a possibility. Some preconditions that must occur before SQLite is recoded in Rust include:
Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring.
A. Rust needs to demonstrate that it can be used to create general-purpose libraries that are callable from all other programming languages.
B. Rust needs to demonstrate that it can produce object code that works on obscure embedded devices, including devices that lack an operating system.
C. Rust needs to pick up the necessary tooling that enables one to do 100% branch coverage testing of the compiled binaries.
D. Rust needs a mechanism to recover gracefully from OOM errors.
E. Rust needs to demonstrate that it can do the kinds of work that C does in SQLite without a significant speed penalty.

unanswered• 5 years ago

Rust did not have checked arithmetic on by default

Except it does, in debug mode, which is the default compilation mode. And you don't have to tweak compiler settings or linters to get checked arithmetic in release: you simply call the checked arithmetic functions, which give the added benefit of giving you complete freedom in how to handle overflow.

Wherever you 'learned' this misinformation from, please stop considering it a trustworthy source :(

ajross• 5 years ago

From the very top of the article:

For various common safety issues, we can look at protections that are present in software as it is typically shipped (ie excluding tools like AddressSanitizer that are not recommended for production use):

...with a link to a five year old opinion post to oss-security as a reference for "not recommended".

To wit: "There is other stuff in this space that might be relevant, but I don't want to talk about it so I'll just make up a reason. Moving on..."

That kind of logic tells me instantly that this is spin and not a serious analysis. I know next to nothing about Zig, but I know I shouldn't trust this post to tell me about it.

sunflowerdeath• 5 years ago

I think, it is very important, that people started to actually discuss and compare different approaches to safety, instead of just saying that since Rust is safer, we should throw out all of c/c++ code and rewrite everything in rust.

fulafel• 5 years ago

Oh we had this long before Rust, and most of C++ usage in new applications was displaced by safer (among other things) languages.

I think the biggest thing was that university curriculums and mainstream app development platforms (like Microsoft) stopped pushing it as hard when the level of horror got past a certain point. It used to be pretty bad. Business apps being written using MS "Active Template Library" in C++ and then used as signed ActiveX plugins on IE6-only web pages etc.

smolder• 5 years ago

Safety (memory and otherwise) isn't new, but during my CS curriculum, including a course on programming language theory, there was little/no mention of techniques to ensure safety in the space between C++ and Java. I probably would have pointed toward formal verification if someone said they needed safety guarantees in the absence of garbage collection and a potentially slow or bloated runtime.

Though I believe there were some languages with features to that end, at least research languages, they weren't that well represented. I think Rust's presence brought attention to the possibilities there, and an increasing number of people see the value of investigating and developing that niche.

pjmlp14• 5 years ago

Microsoft still is the main company pushing it hard (C++ use) despite all security reports, most likely due to how the Windows and Office teams don't accept anything else.

So basically you have the DevTools and Azure teams pushing for .NET, Java and other safer languages, while Azure Sphere has a C only SDK and WinUI/UWP push C++ above anything else, with some C++ only APIs.

Politics.

com2kid• 5 years ago

It is amusing to me because last time I was using C, the problems rust solves weren't the problems I had in C.

Deeply embedded code doesn't use malloc, doesn't use threading.

I could use a better type system, ala Ada, being able to say "this variable is of type distance in meters, this variable is of type time in milliseconds", that'd have cut the # of bugs by a huge amount.

But simple, unsexy, type system changes like that aren't what language designers are focused on.

Who here has never confused Milliseconds and Seconds when passing a variable around? Trivial for a compiler to catch with a half decent type system, but few modern languages bother to try.

Even when writing modern code in newer languages, I rarely directly use threads, and if I need to pass data between them 95% of the time I can get away just doing a deep copy to avoid the hassles of sharing data between threads!

Obviously Rust is meant solving different problems than the ones I face, I have friends who frequently write highly threaded code, but in my day to day, Rust doesn't offer much more safety.

(However, Zig does look super cool and interesting!)

steveklabnik3• 5 years ago

I work on embedded code with no malloc, no threading. We still find Rust valuable. YMMV :)

paragraft• 5 years ago

Re units of measurement in Rust, have you looked at something like https://docs.rs/uom/0.31.1/uom/ ?

asalahli• 5 years ago

Have you looked into the subset of D called "Better C"? I recently stumbled upon it and have been wanting to try it out. It seems to solve the exact same problem you're describing, though I don't know how good of a job it does at that.

https://dlang.org/spec/betterc.html

scoutt• 5 years ago

I wonder in which category Rust's RefCell runtime-borrow-checks fall into.

jedisct1• 5 years ago

In the “it’s necessary but let’s act as if it didn’t exist” category.

_u9xp2• 5 years ago

Only as safe as the creator decides. Andrew has shot down discussions about DOS vulnerabilities in the standard library and the cult-like discord community loves to dig on anyone who brings such things up.

I will be staying away from Zig exactly for that purpose. Great idea but I can't get behind a maintainer that adamantly refuses to even discuss proper, safe standard library design.

EDIT: Yep, the HN crowd tends to be the same. Downvote me all you want please :) We'll see over time.

fctorial• 5 years ago

Can you share a link?

_u9xp2• 5 years ago

https://github.com/ziglang/zig/pull/4929#issuecomment-649191...

The bulk of the conversation happened in Discord around that time. Initial attempts to bring this up were met with "zig is perfect"-type conversation, none of which was very technical.

Finally, the conversation grew to be so large and fiery that Andrew had to step in and say "everyone play nice, now!" and then head back out.

Then this PR was filed. Invalid user input should not be classed as undefined behavior and concluding that the standard library's UTF decoder shouldn't be used if you want a safe execution is just absurd.

There were a few other run-ins on discord in the same vein. It made a few people at the time leave, including myself.

Andrew's smart. Zig is a cool idea. But I don't like when this laisse-faire attitude is taken when designing a programming language that places so much emphasis on being safe.

kbd2• 5 years ago

Downvote me all you want please :)

I think you're getting downvoted because "citation needed", while accusing the Zig community of "cult-like" behavior without justification.

Where has Andrew "shot down discussions about DOS vulnerabilities in the standard library"? As is, your comment isn't helpful.

dnautics11• 5 years ago

The recommended way to deal with use-after-free and double-free in the language is to do it in test. You can pretty trivially get "asan"-like behaviours out of the zig std library. A good demonstration is here: https://www.youtube.com/watch?v=4nVhByP-npU&t=3h12m

I kind of like this philosophy, because in a sly way it's a carrot to get you to write tests. Come for the memory safety, stay for the robustness.

As a bonus, the beginning 2 hours of the video is a fantastic and honest discussion about the role of emotional empathy in tech communities and tech employment (while also acknowledging that it is possible to be an asshole and deliver good tech).

jamii8• 5 years ago

That's also the recommended way to deal with it in c. It hasn't been effective in preventing vulnerabilities based on use-after-free.

If the GPA is practical to use in production, that will be a different story. But it doesn't sound like it's there yet.

dnautics11• 5 years ago

True, UAF still kind of sucks in zig. My prediction is that we are going to eventually get some sort of formal verification engine for zig as a third party tool.

pjmlp14• 5 years ago

Unless the test proves all use cases in production, it is no better than C with ASAN.

AndyKelley3• 5 years ago

To be clear - you get this same UAF protection in ReleaseSafe mode by default with GeneralPurposeAllocator and PageAllocator. It's not just a test thing. The testing system just chooses some nice defaults for you.

dnautics11• 5 years ago

thanks for the clarification! Also, you can arbitrarily compose GPA backended by other allocators that aren't pageallocator, in which case you might lose the early-exit segfault behavior.

mlindner• 5 years ago

This is as ridiculous as it is in C. You can't be sure you're testing all the user after free cases and if the code changes and you forget to update the test then you have no idea that you could have added a use after free. Tests rot over time.

The more I read about Zig I feel like it's made for C programmers stuck in the Stockholm Syndrome of C and don't want out. (Speaking as a former C programmer.)

smasher164• 5 years ago

I think if Zig wanted to, it could introduce lightweight linear types using the concept of proof variables and interleaving from ATS. Since resource management is explicit in Zig anyways, there's not much additional overhead in "consuming" proof values to signal that you've dealt with a resource.

tptacek5• 5 years ago

I don't know Zig, at all, but I do know Rust and C, and I know what a UAF bug looks like. What does a UAF bug look like in Zig? That a modern memory-safe language could be vulnerable to the C-language UAF pattern is a surprising claim.

trishume• 5 years ago

Zig is a C-like language that isn't memory safe. A UAF bug looks the same as it does in C where you manually call the allocator to get a block of memory, manually free it, then try to perform an access via a pointer to it.

_vvhw13• 5 years ago

To be fair, Zig provides a spectrum of memory safety as the comparison table in the post makes clear. Sure, it isn't 100% memory safe, and especially not around UAF, but it's still orders of magnitude safer than C. In the safety department, it's not at all a "C-like language" in that respect. It's a massive leap forward.

dnautics11• 5 years ago

UAF in zig. It still kind of sucks:

https://www.youtube.com/watch?v=4nVhByP-npU&t=11820s

tptacek5• 5 years ago

Ok, but that video suggests that Zig's allocator wires the program to segfault if you access the freed memory. With a 64 bit address space I guess you can do this perpetually?

setpatchaddress• 5 years ago

Sometimes we might also just choose the bear the cost. For systems with low risk profiles (eg internal software that is never exposed to hostile input) we might decide that debugging the occasional use-after-free is preferable to adding development friction.

Zig vs Rust vs C aside, this cannot be a serious position for a software developer to take in 2021 CE.

dnautics11• 5 years ago

it's about context.

Suppose you just document "please take this into account" because it's a low-level FFI library, that's being called by a high-level PL, which will make sure that your memory management is sane.

An analogy: "non-threadsafe" code; typically you just tag 'non-threadsafe' and if someone misuses it, it's on them.

Nycto• 5 years ago

Someone on Reddit added Nim to the table, which I found interesting:

https://uploads.peterme.net/nimsafe.html

(Source: https://www.reddit.com/r/nim/comments/maj1lz/nim_safety_in_c...)

andrepd• 5 years ago

Which is a bit silly because Nim is a garbage collected language, and hence competing in a different league.

k__• 5 years ago

Isn't the Nim GC optional?

pjmlp14• 5 years ago

The league of being safe, without use after free, letting the developer focus on productivity, while providing the language features to do C style programming when required.

spiritplumber• 5 years ago

Move Zig for great justice!

daakus3• 5 years ago

Safety for me is confidence to use the thing. For me in my own code, but also others on my team that may work on this code.

I mostly have experience building things in GC languages. But with Rust I managed to safely use [1]:

- stack references in threads

- kept mmap references alive until threads finish work

- zero copy xml parsing (from mmaped data!)

- SSE/AVX enabled searching

The Rust language empowered me to do these things with a high degree of confidence. Not one segfault or core dump, just lots of compiler errors.

I played with Zig. Admittedly, the small ecosystem aspect is something all languages go thru, and it would be a better experience with a Zig specific libraries. But Zig doesn't empower library authors to make a large category of bugs impossible, and leaves it to documentation. This is like C, I don't have enough confidence in myself to use it.

Brilliant people are building powerful, safe-ish, reusable libraries in Rust. For mere mortals like me, this is Awesome.

[1] https://gist.github.com/daaku/58557e2545612df8f40b13b66b7d3b...

burntsushi3• 5 years ago

Hi, author of the aho-corasick crate here. Your use of it piqued my interest and caused me to take a closer look.

I believe your use of `unsafe` on this line is unsound: https://gist.github.com/daaku/58557e2545612df8f40b13b66b7d3b...

Namely, there is no guarantee that the bytes between `<page>` and `</page>` will be valid UTF-8. It may be the case that you only run this program with UTF-8 input, in which case, UB is never triggered. But it's worth pointing out here since there is nothing actually stopping your program from hitting UB.

Also, as long as you're bringing in the twoway crate, you might as well use it on lines 43 and 48 since you're just searching for a single needle.

daakus3• 5 years ago

The bytes are assumed to be utf8 (I was using the safer `from_utf8` prior to confirming the data was utf8).

I brought in `twoway` when I couldn't find a way to `rfind` using `aho-corasick`. I'll switch the use over for consistency.

Thanks for the quick code review!

PS: Thanks for ripgrep too!

dathinab3• 5 years ago

null pointer dereference (C)none (Zig)runtime (Rust)runtime

Not really rusts pointers are the `&`/`&mut` references which are compiler time proven to be not just non null but actually differentiable and potentially writable in the given context. Which are MUCH stronger guarantees then just "not null".

2. only when using tagged unions

Which in rust are the default types, unions didn't exist for quite a while and require the use of unsafe making them heavily discouraged to be used.

Besides that it's not that rust enums are tagged unions where you at runtime check a tag and then access them, or where you "panic/throw an exception" when you try to access the wrong type, but incoperated into the type system and language given quite a different experience to classical tagged unions.

Lastly type confusions applies to more then just "tagged union style access" but also subtype stile access in which case rust can use trait objects instead of sum types.

Besides that many of the ways listed zig can archive more safety (weather applicable or not) are also applicable to C. And some of the checks Zig do can be "somewhat" archived in C too by combining non standard compiler options and code analysis tools.

Don't get me wrong. Zig is a very interesting language and I would argue the spiritual successor of C in how it's designed.

Still I guess the main ways to add more safety (and similar) to languages like Zig (or C) is to compile them to WebAsm. The module isolation while still being able to call other functions without to much overhead which can be archived with WebAsm might lead to quite interesting trends in the future.

AndyKelley3• 5 years ago

The word "none" in this blog post is misleading, for the rows use after free, double free, and uninitialized memory. Criticism is of course welcome but let's make sure we get all the facts on the table so we're not arguing a straw man.

Copied here [from lobsters](https://lobste.rs/s/v5y4jb/how_safe_is_zig#c_vddk9j):

With regards to use after free and double free, this is solved in practice for heap allocations. The basic building block of heap allocation, page_allocator, uses a global, atomic, monotonically increasing address hint to mmap, ensuring that virtual address pages are not reused until the entire virtual address space has been exhausted. In practice, this is a very long time for 64-bit applications. The standard library GeneralPurposeAllocator in safe build modes follows a similar strategy for large allocations and for small allocations, does not re-use slots. Similarly, an ArenaAllocator backed by page_allocator does not re-use any virtual addresses.

This covers all the use cases of heap allocation, and so I think it’s worth making the safety table a bit more detailed to take this scenario into account. Additionally, as far as stack allocations go, there is a plan to do escape analysis and add this (optional) safety for stack allocations as well.

As far as initialized memory goes, zig forces you to initialize all variable declarations. So an uninitialized memory has the word undefined in it. And in safe build modes, this writes 0xaa bytes to the memory. This is not enough to be considered “safe” but I think it’s enough that the word “none” is not quite correct.

As for data races, this is an area where Rust completely crushes Zig in terms of safety, hands down.

I do want to note that the safety story in zig is [under active development](https://github.com/ziglang/zig/projects/3) and will be worth checking back in on in a year or two and see what has changed :)

dathinab3• 5 years ago

Just somewhat related to the article but I think one thing which is often misunderstood about rust's is it's borrow checker.

The borrow checker is not about memory safety but about aliasing guaranteed.

It just happen that combining this with deterministic destructors (/RAII) happend to enable reliable "automatic-manual-memory-management" (or however to callit).

And combining it with some clever auto traits (Send/Sync) happen to prevent data races (if no unsafe is used, like always).

But the benefits are not limited to just that. Not just memory-resource management but also other resource management profits from this design.

Similar while Send/Sync is about multi threaded data race prevention there are also problems in single threaded patterns which are quite similar to that e.g. "racing" between iterating a collection and changing it in the body of the iteration, and the aliasing guarantees make sure you don't have such problems either.

Similar rusts main pointer type (`&`) does not only provide compiler time non-null guarantees but also provides compiler time guarantees about how the data can be accessed (dereferencable, writeable etc.).

And then there is the choice to use the type system to prevent application logic bugs in many ways.

So the bullet points in the table miss many dimensions .

But then zig is still a grate language, but trying to convince people that it's good enough by telling them that not reusing allocations seem to not be the best way.

Instead look at arguments why people still use C today (not C++!) what they conceptually like about it and you might realize many of the parts still apply to Zig.

Honestly Zig seems to be a grate choice for webasm or similar sandboxed systems where the potential damage of use-after free or double frees can be massively reduced.

StefanKarpinski2• 5 years ago

It’s interesting to note and probably underappreciated how many of these safety issues are addressed simply by having a garbage collector — eliminating manual memory management prevents all of these kinds of bugs except for data races. Of course there are situations where you cannot afford a GC, but for how many programs is avoiding a GC worth all the additional language complexity? Preventing data races is no small thing, but this observation certainly suggests that the approach of GC + tasks & channels + a good race detector is more powerful than it is commonly given credit for — think about how much user-facing language complexity it replaces. This sounds like a pitch for Go, and to some extent it is, but Julia takes very much the same approach for the same reasons.

oleganza2• 5 years ago

The power of a software is in composing things via powerful abstractions. When you write a useful library in a PL with GC, you automatically make it unavailable in all applications that can't use GC. What's worse, other libraries that could've built something around yours have to choose whether to limit their applicability to applications with GC or find another way.

But if you have a clever language that navigates this tradeoff and lets you build powerful zero-cost abstractions (C++, Rust, Zig), then it attracts significantly more talent that compounds.

pjmlp14• 5 years ago

There are many ways to compose software and libraries, it doesn't need to be static linking all the time.

Everyone praises UNIX for pipes in the shell and forgets about OS composition APIs.

StefanKarpinski2• 5 years ago

That’s a fair point. Something we’re very interested in is exposing libraries written in Julia without the full runtime, ditching the JIT or the GC if you don’t need them. It would be easy to write a libm replacement in Julia, for example, without using either of those.

Regarding talent, it depends on the kind of talent you’re talking about. Yes, systems programmers like Rust. On the other hand, needing to deal with a strict borrow checker excludes a very large number of people with numerical computing, data science and machine learning expertise (not all, but definitely most). So it cuts both ways.

tene2• 5 years ago

One other underappreciated point is how to deal with other resources besides memory.

Go has a GC, which helps with memory, but you're entirely on your own for files, sockets, database connections, mutexes, channels, etc.

The features that Rust uses for memory management are fully general-purpose, and also help you with safely handling all other kinds of resources.

Consider how many ways you can misbehave with a Mutex in Go that are all caught by rustc at compile-time. This has nothing to do with memory management, but the same thing that prevents use-after-free is what also prevents using a mutex-protected value after releasing the lock.

WalterBright4• 5 years ago

The D programming language:

out-of-bounds heap read/write: runtime, some cases at compile time

null pointer dereference: relies on hardware protection

type confusion : compile time

integer overflow: wrap-around semantics

use after free: prototype protection in @live functions, not a problem when GC is used

double free: prototype protection in @live functions, not a problem when GC is used

invalid stack read/write: compile time

uninitialized memory: compile time

data race: read/write to shared memory can only be done via library functions

sedatk2• 5 years ago

null pointer dereference: relies on hardware protection
integer overflow: wrap-around semantics

Interesting choice of words to not say "none".

WalterBright4• 5 years ago

Hardware seg faults for accessing the first page in memory are the norm for modern machines.

Back in the 16 bit real mode DOS days, writing to the first K of memory would trash the interrupt vector table. But that was a 1980 design.

mhh__• 5 years ago

Integer overflow is defined behaviour however, so we can provide library types which are checked. And since D's templates are very clean to define they are easy to use.

The null pointer thing is true however all the other mechanisms mentioned do help eliminate bumping into them, and there will be more on the way.

If you want to provide the null checks yourself D has Ada-style contract programming too.

mwkaufma• 5 years ago

Safety without context is Apples-to-Oranges. I could write a compiler which simply rejects any possible source-text you send it and check "compile time" for every box and offer "greater safety guarantees" than Rust.

snicker7• 5 years ago

On a complete tangent: scattered-thoughts.net is one of my favourite technical blogs. Author has a lot of great insight in many areas.

lenkite• 5 years ago

I cannot live without RAII. Zig is just a no-go for me without automatic resource cleanup. A lot of people forget cleanup and destroy safety without RAII. https://github.com/ziglang/zig/issues/782

Zig is apparently a PL for folks with perfect memory who never make mistakes like those described in that ticket. "Lesser" programmers like me can choose another language.

Nuoji• 5 years ago

A problem for Zig is the combination of unsigned overflow UB, implicit widening and always performing operations on the type size of the operands.

For example, let’s say you have `a = b + c` with b/c being i8 and a i32. This calculation is first performed as an 8 bit add, then extended to 32 bits. This is true for both Rust and Zig, but Rust requires an explicit cast to widen the result of `b + c`, making it obvious that an extension happens and that `b + c` is not performed in 32 bits. In Zig there is no such indication- you need to look up the definition of b and c. Other problems occur as well, that both C and Rust avoid in their own ways. Hopefully Zig can improve this situation.

See more here: https://c3.handmade.network/blogs/p/7651-overflow_trapping_i...

How Safe Is Zig?

Related Stories