Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fil-C: Garbage In, Memory Safety Out [video]

youtube.com

Post reply on HN
Print view View original

81–90 of 190 posts

Re: Fil-C: Garbage In, Memory Safety Out [video]

#81

Post by baranul »

Cyph0n wrote: post #56
jitl wrote: post #48

Earlier quoted context omitted.

Rust is less safe because it has a feature for turning off safety, called `unsafe`. Fil-C does not have a way to turn off safety, and it enforces safety checks at runtime. That's the reasoning anyways. If you define another language Rust-Without-Any-Unsafe, then maybe that one is safer than Fil-C.

But the runtime cost of Fil-C means that - in most cases - your actual production application will be compiled with a standard C compiler. This applies not just to your code, but to all dependencies (due to ABI). So I don’t see how Rust is at a huge disadvantage here when Fil-C is typically not going to be enforcing safety in production. I suppose the testing/fuzzing story becomes all the more important because you n…

I think it's not so much that Fil-C renders Rust completely useless, but rather it reduces the supposed validity and wild arguments to frivolously rewrite anything and everything in Rust.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#82

Post by steveklabnik »

uecker wrote: post #78
steveklabnik wrote: post #73

Earlier quoted context omitted.

If this was an array, that is, a built-in type with a static length, this example does give a compile-time error: https://play.rust-lang.org/?version=stable&mode=debug&editio... However, a vector's length is inherently a runtime concept, and is a user-defined library type, so the compiler does not attempt to directly reason about this at compile time. However, for this example, post-optimizations, it doesn't do a run…

A: "Rust prefers to prevent all undefined behavior statically" me: It does dynamic bounds checking. Rustaceans: But... for XYZ ... it doesn't... Sigh.

It's because you're not using words in the way that people use them when talking about this stuff.

Rust (outside of the unsafe superset) has no undefined behavior. That is guaranteed, statically, at compile time: all execution paths have well-defined behaviors. That does not mean that there are no runtime consequences whatsoever. For example, the behavior of an invalid index is a panic, at runtime. Inserting a check for an invalid index at compile time is static enforcement of the behavior, even if the check itself happens at runtime.

If you had said "sometimes, Rust can't eliminate dynamic checks because it doesn't have a strong enough reasoning about some compile time properties" nobody would be arguing with you about this. Your example is one where a language with stronger reasoning would be able to detect it, for sure. Lean can do this, for example.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#83

Post by pizlonator »

NobodyNada wrote: post #77
pizlonator wrote: post #47

Earlier quoted context omitted.

If you think you like Fil-C but aren’t able to see the specific way in which it’s better than Rust (more comprehensive safety), then what is it that you’re liking?

Not the parent, but: I strongly dislike this framing of "Fil-C is better than Rust" or "Rust is better than Fil-C". This is apples-to-oranges; users will almost never be comparison-shopping between the two because they address almost entirely different problems. There are roughly two categories of Rust user: 1. People who are using Rust for application development. Most of these users write zero unsafe blocks in thei…

I’ve never said that Fil-C is better than Rust full stop.

I have articulated the specific ways that Fil-C is better.

And I’ve articulated the specific ways that Rust is better. You’ve enumerated some of those reasons from your perspective, though I disagree on the details.

I like those kinds of conversations. We shouldn’t shy away from them as a community. They help us grow a shared understanding of the tech

Re: Fil-C: Garbage In, Memory Safety Out [video]

#84

Post by pizlonator »

josephg wrote: post #75
pizlonator wrote: post #44

Earlier quoted context omitted.

Sure all of those are escape hatches that work against any memory safety tech. Point is, Fil-C goes further than any other memory safety tech in terms of what it guards

How does it compare to the equivalent code in Typescript, Go or C#? Those languages all have “safe” syscall wrappers too, for a subset of syscalls.

Those languages rely on a much larger pile of YOLO C/C++ code for their runtimes and standard libraries than Fil-C does.

So Fil-C is safer than those

Re: Fil-C: Garbage In, Memory Safety Out [video]

#85

Post by wasmperson »

uecker wrote: post #68
wasmperson wrote: post #54

Earlier quoted context omitted.

Yes, rust didn't invent the concept of an iterator, and is thus not the only language which offers a solution to statically avoid bounds checks. Feel free to give a more "interesting" case you believe rust wouldn't be able to handle.

Rust fails to prove basic indirection to be statically safe and instead does a run-time check. fn main() { let v = vec![1, 2, 3]; v[5]; }

Now it's your example that's too simple. I can't present a counter-example that wouldn't look totally different: if you avoid the indexing operator then trivially incorrect code like that becomes unrepresentable. It's like if I said destructors help you avoid memory leaks and you asked how you'd avoid a leak in a single-function program that does nothing but call `Box::leak()`.

Again: I'm not disputing the fact that the rust index operator does a dynamic bounds check.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#86

Post by josephg »

uecker wrote: post #78
steveklabnik wrote: post #73

Earlier quoted context omitted.

If this was an array, that is, a built-in type with a static length, this example does give a compile-time error: https://play.rust-lang.org/?version=stable&mode=debug&editio... However, a vector's length is inherently a runtime concept, and is a user-defined library type, so the compiler does not attempt to directly reason about this at compile time. However, for this example, post-optimizations, it doesn't do a run…

A: "Rust prefers to prevent all undefined behavior statically" me: It does dynamic bounds checking. Rustaceans: But... for XYZ ... it doesn't... Sigh.

These are all true? I don’t see the problem?

Rust does prefer static checks. It uses static analysis to prevent many types of bugs - including use-after-free and data races. But you’re right; rust still falls back to runtime checks when static analysis is too hard. Like dynamic bounds checking and integer overflow (in debug mode). Cell, Refcell and friends also have a (small) runtime cost. Rust prefers static analysis but does not use it exclusively.

Let’s say rust is 80% static analysis, 20% dynamic checks. Fil-C seems to go the other way and have 80+% dynamic checks. It’s an interesting point.

Nobody disagrees with you that rust sometimes inserts dynamic bounds checks. But “prefer” in this context means “most of the time, when possible” not “all of the time”. I prefer vanilla ice cream over chocolate. But I still eat chocolate ice cream when vanilla isn’t available. Pointing out that one time I ate chocolate ice cream isn’t a gotcha moment.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#87

Post by baranul »

josephg wrote: post #74
modeless wrote: post #58

Earlier quoted context omitted.

The whole point of Fil-C is that it is fast enough to consider using in production for some applications while still guaranteeing memory safety. We already have ASAN and Valgrind and other tools for development purposes, that's not what Fil-C is targeting.

So Fil-C is competing with Go, C#, typescript and Python. If I’m writing a greenfield project where “bare metal” performance isn’t needed, why would anyone choose Fil-C over a more mature GC language? C is more verbose and more error prone than Go and C#. It has worse tooling. It’s missing decades of language features. C isn’t properly cross platform. There’s no package manager. The “standard library” isn’t fully sta…

Of the group of languages presented, your argument has more merit for Go. With C# and others, there is an additional OOP argument in there, that splits into different factions.

But what is being overlooked, is the massive numerical dominance of C programmers and projects, along with legacy and embedded code. There is going to be a preference for writing and using C, that could arguably fuel Fil-C for a very long time.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#88

Post by mort96 »

wasmperson wrote: post #2

He claims that all syscalls are safe because they're implemented by his custom libc, but that libc then calls out to the system libc, where the system calls are unsafe. He then claims that this is unlike rust, where making a syscall is unsafe. If you stick to the rust standard library in the same way that fil-c programs stick to the fil-c standard library, then all of your rust "system calls" are safe, too. Someone i…

In Rust, there are safe syscall wrappers, and then there's the unsafe general `syscall` function: https://docs.rs/libc/latest/libc/fn.syscall.html.

If I'm understanding correctly, it's this general syscall function that's safe in Fil-C.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#89

Post by josephg »

pizlonator wrote: post #84
josephg wrote: post #75

Earlier quoted context omitted.

How does it compare to the equivalent code in Typescript, Go or C#? Those languages all have “safe” syscall wrappers too, for a subset of syscalls.

Those languages rely on a much larger pile of YOLO C/C++ code for their runtimes and standard libraries than Fil-C does. So Fil-C is safer than those

The number of lines of raw C isn’t the only way to measure the trustworthiness of a codebase. Go, C# and friends may be bigger projects. But they’re also more mature projects. At this point, far more eyeballs have scoured their codebases looking for security bugs.

> Fil-C is safer than those

Says you. It seems presumptuous to me to be so dismissive of their work. The Go and C# teams do good work.

But I wasn’t even asking about safety. I’m curious about ergonomics and performance. Fil-C isn’t the only safe wrapper around raw syscalls. How is cross OS compatibility with Fil-C? How nice are the APIs to use? UNIX syscalls are pretty badly designed imo. The error paths alone are a mess.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#90

Post by ncruces »

pizlonator wrote: post #84
josephg wrote: post #75

Earlier quoted context omitted.

How does it compare to the equivalent code in Typescript, Go or C#? Those languages all have “safe” syscall wrappers too, for a subset of syscalls.

Those languages rely on a much larger pile of YOLO C/C++ code for their runtimes and standard libraries than Fil-C does. So Fil-C is safer than those

Go doesn't rely on much C/C++, not recently at least. Particularly on Linux.
Post reply on HN