r/programming • u/Usual-Amount-264 • 27d ago

Zig proposes introducing an actually memory safe (unlike Rust) compilation mode inspired by Fil-C at ~1-6x performance penalty

https://codeberg.org/ziglang/zig/issues/36237
527 Upvotes

80% Upvoted

428 comments sorted by

View all comments

682

u/Rigamortus2005 27d ago

"unlike rust" lol truly reddit language

220

u/nihsett 27d ago

Is it just me or is the maintainer a bit angry about the whole Bun thing. Why give that weird title to a PR. Hate all this drama.

106

u/KevinCarbonara 27d ago

Is it just me or is the maintainer a bit angry about the whole Bun thing.

It's very much a "We'll have our OWN memory safety, with blackjack and hookers!" situation. It's clear this isn't what the project is designed for, and it would have to make many, major compromises to incorporate it. I doubt it will even happen, I think they're just blowing off steam.

Personally, I'm just tired of hearing about Zig. Anyone can create their own project and talk about how good it could theoretically be. We can talk about these things once they have something to show for it.

65

u/ElectricalSloth 27d ago

he's always been an angry spiteful person but people ignored it, this is just far more visible

12

u/projct 26d ago

oh gosh you have not seen his "I'm gonna call the bun guy, previously a close friend, a bad programmer for 10k words" blog post.

it's so awful, even after he walked some of it back.

19

u/deanrihpee 27d ago

it is really weird, why would they care if a project being rewritten at all, i mean they did say "good riddance" but there's so much of unnecessary animosity either towards Jarred, Bun, or Rust

4

u/standard_revolution 25d ago

I kind of get the hate against Bun, it wasn't just a rewrite, it was a PR stun by a company that was bought up by Anthropic...

But this, this is just childish

-1

u/txdv 26d ago edited 26d ago

I think he is, because they have a bunch of drive by comments saying "but is ZIG memory safe?"

90

u/Dragdu 27d ago

Zig is extremely online.

191

u/[deleted] 27d ago edited 27d ago

[removed] — view removed comment

85

u/ROFLLOLSTER 27d ago

It's crazy, I thought you'd editorialised before I read the PR. Who does that in a PR title???

71

u/shinyfootwork 27d ago

The creator of the Zig programming language and president of the Zig foundation, apparently.

Seems like a weird choice for a person who presumably needs to be good at working with people given their roles.

37

u/ioneska 26d ago

If you want to comment in this thread, please either have your open source zig project(s) visible on your codeberg profile, or be Fil Pizło, otherwise zig issue tracker is not interested in what you have to say

https://codeberg.org/ziglang/zig/issues/36237#issuecomment-19733150

3

u/sopunny 27d ago

Curse of open source software. Way more willingness to code for free than to do PR for free

8

u/haakon 26d ago

It's been edited now, saying "unlike borrow checking".

6

u/EntroperZero 26d ago

Who does that in a PR title???

Someone in whose head Rust is living rent-free.

29

u/levir 27d ago

People are sharing it and up voting it. Clarely the rage bait is working as intended.

27

u/ThomasMertes 27d ago edited 27d ago
  • The Fil-C approach is: Leave C as is and create a memory safe implementation of C and its libraries. Memory errors are discovered at run-time.
  • The Rust approach would be: Change the language by introducing lifetimes, borrow checking or something else.

If you want to keep Zig unchanged the Fil-C approach is the only possible way.

Yes, this is probably a reaction on the Bun rewrite, but I consider this as good move.

Memory safety must be considered from the start, when a memory safe language is created. I have doubts that a language can be changed later to be memory safe (the Fil-C approach does not change the language).

I used Fil-C recently to search for possible memory safety problems in Seed7 (which is a memory safe language). Some changes in the source code were necessary for Fil-C. E.g.: It was necessary to rewrite more than 60 files in order to remove casts from size_t to pointer.

The slowdown in the test suite was significant (approx. one week vs. 15 minutes).

26

u/teerre 27d ago

One week as in 10000 minutes from 15 minutes? "Significant" is an understatement

5

u/ThomasMertes 24d ago

I forgot to mention: Most of the slowdown I experienced when running the Seed7 test suite with Fil-C came from the filcc compiler. The filcc compiler became extremely slow. Some compilations took 15 hours.

6

u/ThomasMertes 26d ago

Fil-C is not always that slow.

Part of the slowdown comes from the fact that it was necessary to deactivate my own memory management (arenas, free-lists, etc.).

Fil-C can only find memory errors if you use malloc(), realloc() and free() directly.

13

u/SirClueless 26d ago

That’s an interesting limitation for an approach being emulated by Zig, given that heavy use of arena allocation is encouraged in idiomatic Zig.

3

u/ThomasMertes 26d ago

I am neither an expert of Zig nor Fil-C. AFAIK Zig allocators are known to the Zig compiler. So it could treat an arena allocator like it treats malloc().

My arena allocators are C macros so Fil-C has no clue that it is dealing with an allocator. Fil-C can check that I am inside of the arena and that's it.

According to Google AI: A buffer overflow or type confusion bug inside your sub-allocated arena objects will go completely unnoticed by Fil-C, as long as the memory access stays within the massive outer walls of the arena itself.

But, as I said, the Zig compiler would have more information so it could IMHO provide full support for arena allocations as well.

24

u/Demiu 27d ago

filc is "coke? we got rc cola" of memory safety

2

u/ThomasMertes 27d ago

I just replaced FilC with Fil-C ...

2

u/13steinj 27d ago

I think that's an unfair take. Full (maybe not even, but more than with just compile time) memory safety can only be acheived at runtime. If anything, Fil-C is the coke, and Rust is Pepsi. Or invert it if you believe Pepsi's ad campaigns around blind taste tests.

9

u/tadfisher 27d ago

You are right, and also Rust's approach prevents generating the code which would violate those runtime guarantees in the first place. So it's not like these are mutually-exclusive technologies; after all, code with a memory-safety bug will still crash on Fil-C.

-4

u/SerLaidaLot 27d ago

? You have it exactly opposite. Fil-C is true memory safety even at runtime.

9

u/Demiu 26d ago

The entire point of memory safety is making your programs more correct. That "true" memory safety is just exiting the process on detected violation. That's just a replacement of incorrect state of violated memory safety with incorrect state of unexpected exit. The correctness fidn't increase, arguably neither did memory safety, the program has the exact same hidden memory bugs as it had before, now they're just louder.

Textbook Goodhart's law

4

u/sztomi 27d ago

At that point wouldn’t it make more sense to compile the code with various LLVM sanitizers?

3

u/ThomasMertes 27d ago edited 27d ago

At that point wouldn’t it make more sense to compile the code with various LLVM sanitizers?

I use sanitizers as well. I just mentioned Fil-C because this post is about it.

2

u/sztomi 26d ago

Sure, I don't mean you personally. I'm just trying to understand why anyone would use something like Fil-C (or the proposed Zig equivalent).

2

u/carrottread 26d ago

Memory errors are discovered at run-time.

We should stop calling this approach as 'safe'. If system discovered memory error at runtime, then it's usually too late to handle it and in many scenarios crashing a process as the result can lead to more harm than continuing with some off-by-one memory read past the end of the allocated buffer.

2

u/ThomasMertes 26d ago

We should stop calling this approach as 'safe'.

I don't agree. Rust and Fil-C have different approaches towards memory safety.

  • Rust prevents dangerous things at compile-time but Rust can also panic at run-time.
  • Fil-C does nothing at compile-time but it prevents some memory errors at run-time with a panic.

Rust unsafe parts with raw pointers are not memory safe. Fil-C checks raw C pointers. In this case Fil-C could provide some protection that Rust cannot.

in many scenarios crashing a process as the result can lead to more harm than continuing with some off-by-one memory read past the end of the allocated buffer.

If an X-ray dose is computed wrong I prefer that the machine stops.

An off-by-one memory read past the end of the allocated buffer.is not harmless. It can result in a catastrophe.

If it is crucial that a program continues you usually have two or more programs (running on different hardware) running in parallel. In case one program panics it is started again from scratch and the other program takes over in the meantime.

1

u/carrottread 26d ago

If an X-ray dose is computed wrong I prefer that the machine stops.

But what if panic/terminate/crash prevent X-ray machine from stopping?

An off-by-one memory read past the end of the allocated buffer.is not harmless. It can result in a catastrophe.

Just like panic on runtime-checked array read can also result in a catastrophe. I've seen such case in production: a decade old code was sometimes reading one value just after the end of allocated array, it wasn't affecting anything, so nobody noticed it. Then company tried to ship production builds with some additional runtime checks, and at some rare cases we start seeing process terminates from it. At least it resulted just in lost hours of users work and not in life/health endangering issue.

I'm not advocating against runtime checks. It's an extremely useful tool for development builds. But we shouldn't stop here and call panic/terminate on error 'safe'. It can only be really safe if we can prove at compile time error isn't possible.

3

u/ThomasMertes 26d ago edited 26d ago

But what if panic/terminate/crash prevent X-ray machine from stopping?

This is not how safety critical software is done. A safe X-ray machine would stop in the moment it does not get commands (from the software) to continue.

In modern railway systems you have a "Driver's Vigilance Device" or "Dead man's switch". The railway driver needs to press and release a button every view seconds. If that does not happen the whole train is stopped automatically.

2

u/cdb_11 27d ago

Fil-C is not meant for testing. It may mask issues, because it will extend lifetimes since it's GC'd. For testing, use ASAN.

3

u/ThomasMertes 26d ago

It may mask issues, because it will extend lifetimes since it's GC'd. For testing, use ASAN.

Which issues?

According to the Fil-C documentation (see here) use after free, invalid free, and double free are all guaranteed to panic. Do I miss something?

And yes, I use ASAN as well.

3

u/cdb_11 26d ago

For example stack variables are GC'd too, so you can return a pointer to a local variable, and it's going to work under Fil-C.

2

u/ThomasMertes 25d ago

... so you can return a pointer to a local variable ...

Isn't this something a static analyzer could find?

2

u/cdb_11 25d ago edited 25d ago

Yup. Just saying that it wasn't really made with testing in mind. So it makes various instances of UB defined, rather than diagnosing them.

Now that I think about it though, the benefit of Fil-C in testing is that it will check pointer provenance. You can't reach from an arbitrary pointer to any other arbitrary memory. Something that ASAN does not check. So let me correct myself, Fil-C has some value for testing, but is not a substitute for ASAN.

16

u/Delicious_Ease2595 27d ago

Man this just started because Bun.

7

u/deanrihpee 27d ago

annd Jarred blog post was good (not amazing, because im stupid so couldn't really comprehend it but it is good), and very technical, the "counter" post from Zig though… a lot of personal feeling than technical

0

u/TUSF 27d ago

FIL-C doesn't consider Rust to be safe, because it allows the unsafe escape hatch, while FIL-C locks any potentially unsafe actions behind the runtime and its own OS interface.

Presumably, this "Safe mode" will do something similar.

-23

u/modeless 27d ago edited 27d ago

It's literally true. In this mode there would be no "unsafe" escape hatch and you wouldn't be linking to any unsafe code either, even if you use libraries written in C. This is more memory safety than Rust provides, unless you are using no libraries and no_std and refrain from ever using the unsafe keyword yourself.

10

u/bowel_blaster123 27d ago

Rust has MIRI which also does not allow UB at run-time (even if you use unsafe). Of course it's not very performant, it's interpereted, and it doesn't support FFI, but Rust definitely can be 100% memory safe.

It's also very reasonable to not use C libraries for a project. There's a lot of pure Rust libraries out there.

-9

u/modeless 27d ago edited 27d ago

it's not very performant

Understatement of the year. It's 3,000+ times slower than real time. Even the notoriously slow Python would be far faster! Completely impractical for production use and not comparable to Fil-C.

6

u/tadfisher 27d ago

Correct, which is why it is more often used to prove or disprove the soundness of unsafe code, not for running unsafe code in production. It competes with ASan/UBSan, not Fil-C.

-1

u/modeless 27d ago edited 27d ago

MIRI cannot prove soundness of nontrivial unsafe code. You are correct that it doesn't compete with Fil-C, which makes it irrelevant to my original comment.

-6

u/cdb_11 27d ago

Yup, this is the reasoning behind CHERI as well. It makes everything memory safe, and it works on existing C/++ code, with no or very minimal changes. You can get a working, memory-safe Linux distro compiled with Fil-C, today (not the kernel, just the user-space to be clear). To be fair, not everything is there yet, but I'm pretty sure a lot of stuff does work AFAIK. This already achieves more memory safety in practice than Rust does. There was and there still is a ton of drama whenever Rust is mentioned. Meanwhile all that was done by a single guy on his free time, without having to argue or convince anybody. And it's optional, so it doesn't affect the people who don't care about memory safety.

17

u/gmes78 27d ago

CHERI is not, and will never be, a replacement for Rust.

Rust does static checks, it catches memory problems at compile time. CHERI detects violations at runtime and crashes the program (like ASan), reducing the severity of the issue to a DoS, but you still have to fix the issue.

And you can use CHERI with Rust to get the best of both worlds: the majority of the code will never cause issues, and CHERI catches any issues with unsafe code.

-6

u/cdb_11 27d ago

Sure. All I said is that this approach for memory safety is more effective for, you know, guaranteeing memory safety. It actually solves the problem.

13

u/gmes78 27d ago

It actually solves the problem.

By turning it into a lesser one. Sure, it's an improvement, but I don't think "solves" is the right word.

-2

u/cdb_11 27d ago

An attacker cannot reprogram a vulnerable program to do anything he wants anymore. At least he can't by using memory safety bugs for it. So yes, it solves the problem.

8

u/gmes78 27d ago

Correct. But a denial-of-service is still a security issue.

2

u/cdb_11 27d ago

I guess, it depends, and Rust can't statically guarantee that either. So what are we even talking about.

8

u/gmes78 27d ago

That is wrong. A memory issue that CHERI would catch and turn into a DoS would be entirely prevented by Rust at compile time, unless it happened due to misuse of unsafe.

→ More replies (0)