afdbcreid

Fil-C is an amazing, marvelous even, and useful, concept. Useful for all legacy code that will not be rewritten and/or is not performance-sensitive, that is. The only problem is that Zig has no legacy code, so Fil-C is useless there. If you can afford the performance penalty, there are much better an easier languages to choose from.

Totally unrelated; The trusting trust attack was about downloading a malicious compiler because malicious code was injected into it in some early version.

(And if you ask me, it was indeed overrated, but that's unrelated).

Considering that you often run the code after you compile it, it might not matter. Anyway, like it or not, most compilers don't consider themselves security sensitive and will not consider malicious code that is able to hijack the compiler a security vulnerability.

Hardening is definitely possible, we've had sanitizers in C/C++ for a long time. It's not full memory safety though. Miri is the same.

SeL4C is formal verification, and while it can prove memory safety (and much more) it is much more difficult, to the point that you're basically programming in a different language.

Ada/SPARK is your best example, and also the example I know the least of, so I won't comment on.

I have picked private fields as an example of feature that is needed because it is very simple. You're right that you can build an analyzer (with additional code annotations) to support that, but it's only one example.

Take another example: unsafe traits. They are fundamental to some safety encapsulations, most famously concurrency (`Send`/`Sync`). Here you cannot just build an analyzer to mark something unsafe, because Zig has no traits, its generics are duck-typed.

You can, of course, add traits. But at this point you're essentially creating your own language that compiles to Zig, with all problems this entails (e.g. bad ecosystem support). It's also hard to claim that Zig can be memory safe then.

This analysis is undecidable. There is a reason sound static analyzers (including languages like Rust) require in-code annotations.

Most compilers do not consider themselves a security boundary, and will not try to limit malicious code from hijacking the compiler. E.g. LLVM is explicitly not designed to handled malicious code (https://llvm.org/docs/Security.html#what-is-considered-a-sec...).

Nowadays when you can just point an agent at release notes and have it update everything

Except that means that not only you lose compiler bugfixes, you also pretty much has no access to the ecosystem. For most production codebases, this is a deal breaker.

That is possible (clang has experimental lifetime annotations support), but that is not enough to guarantee memory safety.

As a simple example, Zig has no private fields. That makes encapsulating any unsafety impossible.

Compilers are not security sensitive, usually. And while UB could theoretically poison the generated code, this isn't a bigger risk than logic bugs.

No, it's exactly the sort of projects slop is not appropriate. If you're going to use this in production, at least using LLMs (maybe) allows you to deliver faster.

No it's not. Yes it contains a lot of Rust, but it's still mostly C++.

E.g. you cannot translate `#[repr(C)] struct Foo { v: i32, u: i32 }` to `typedef struct { int32_t v; int32_t u; } Foo;` because in Rust it's entirely valid to take a `&Foo` and view it as `&[i32; 2]`, while in C this is UB.

A Rust rewrite would have an easy way to expose an API, something they're still debating how to do and deferring to 7.1.

But the team has already choose. They explained their reasoning and IMO it makes sense: they didn't want a rewrite, they wanted a bug-for-bug file-by-file translation. With a borrow checker and no GC, Rust sometimes forces you to structure things differently (especially in a compiler that usually has a lot of circular structures), so it was not worth it.

If the build script can execute arbitrary processes, the entire security is lost.

It makes a big difference if you want to translate Rust to C. TBAA means you cannot translate a Rust struct to a C struct if you want to stay in standards-compliant C.

What do you think we've missed? Do you want one build systems for all languages? There are such systems (e.g. Bazel) and they're often used for multi-languages projects, but I think reality has proven that build systems with language-specific knowledge are much easier to navigate.

I don't know what build.zig commonly does, but in Rust build.rs often does things like compiling C/C++ libraries, so you can't sandbox it with WASM (contrary to proc macros, which most of the times can be compiled to WASM and there were/are efforts for that). How does Zig fare with that?

Depending on what your goal is. If it is eliminating trusting trust attacks, yes this is no enough. But more commonly you only want to compile rustc for a platform it was never compiled on, and for that this project is definitely enough.

FWIW, Rust can also do a lot of things that do not easily map to C (at least standard C) constructs. For example:

- You can compare any two pointers, while in C they must point to the same allocation. This is possible to solve by converting to integers first.

- Signed integer overflow is UB in C, defined to wrap/panic in Rust.

- Type-based alias analysis is a big one, does not exist in Rust.

Datalog is not used for borrow checking. It was used in old versions of the experimental next-gen borrow checker, Polonius. Current versions of Polonius (which is still experimental) are coded in Rust.

I've never heard about that and I'm pretty sure it's incorrect (although "machine learning" is a wide term), do you have a source for that?

In C/C++ the default behavior, always, is very dangerous UB. Some compilers offer an option for guaranteed wrap-around, and some compilers offer an option for controlled crash. None of them is standardized or the default.

In Rust the standard mandates a guaranteed wrap-around or a controlled crash. The default behavior is crashing in debug mode and wrapping-around in release mode, but you can control that with a compiler flag.

No matter how you look at it, the Rust behavior is safer. The default behavior? Way better in Rust than in C++. Want a guaranteed wrap-around? In Rust, check. In C++, depending on the compiler. Want a guaranteed crash? In Rust, check. In C++, depending on the compiler.

Also worth noting that overflowing has much more severe consequences in C++ than in Rust, due to bounds checks.

I don't know if Rust will ever attempt to fix this mistake

It was discussed many times, and the conclusion is: it is too expensive, and the default will only change if that will change (due to better optimizations and/or better hardware). It is not a mistake, but a conscious decision.

Is there anything similar to (or better than) overleaf for collaborating on typst docs? To be clear, overleaf isn’t all that great but I sometimes work with groups that are used to it.

Yes, https://typst.app/ is the official Typst app (part of how they make money).

Have conferences that traditionally accepted latex source (and specified latex templates) started accepting typst as well?

Very few by now.

This doesn't matter to the post, because it is about culture, not about code.

And there are plenty of ways to cause UB with modern C++ idioms.

As for #4, you will probably be interested in https://github.com/rust-lang/crates.io/issues/326. The crates.io team wants this, but this is complex to implement and they're understaffed.

I've heard this from other LaTeX veterans, but as someone that has never done any LaTeX himself and was scared by all those backslashes and braces, the simple C-like syntax is a blessing.

Rust and non-SPARK Ada are not equally safe. Ada is unsafe in the presence of data races, and also has runtime checks that slow it down, or you disable them and then it's even less safe.

You said

I'm not convinced this is true.

But it is. It is true that Rust libraries could take this position of "any API misuse causing vulnerability is a CVE" more to the extreme, currently it is applied to memory safety but it could be applied to panics as well. However it is still true that pretty much all Rust libraries treat API misuses that cause UB as a CVE, and pretty much no C/C++ library does that, and that inflates the number of Rust CVEs.

On the extreme end, we have compiler soundness bugs. I'm a bit of worried that I'm hitting any of those when I'm tweaking the types until the compiler no longer complains. Beyond the basics, I really don't have a grasp of Rust's type system rules. But I suspect they very difficult to hit by accident, and even if I do, the code must be miscompiled in meaningful, but difficult-to-notice way. All that seems rather unlikely, which is why these bugs aren't treated as vulnerabilities.

Rest assured that you are much more likely to hit a miscompilation in your compiler's backend, and that it is much harder to detect.

My understanding is that they claim that the average Joe writes code in a garbage-collected memory-safe language.

Which is... true? but irrelevant. Such applications are not suggested to be ported to Rust. Of course, some people still do that, because they like Rust; but that's their personal choice.