afdbcreid

7 ms·

91.
by afdbcreid 3mo ago
See https://kobzol.github.io/rust/rustc/2024/03/15/rustc-what-ta... , which does an extensive analysis on that.
92.
by afdbcreid 3mo ago
That's only part of the issue. First, declarative macros are of course pure. Most procedural macros are pure too, although there are exceptions (an infamous case is sqlx). And while rustc does expand them every time (although a config
93.
by afdbcreid 3mo ago
That is common wisdom but reality is more complicated. It's true in some projects, but not all.
94.
by afdbcreid 3mo ago
This post is really interesting. As a member of the rust-analyzer team, I cannot avoid comparing it to the situation in Rust land. Rust famously has not less (or even more) sophisticated system for incremental compilation, yet its compilati
95.
by afdbcreid 3mo ago
That's just false. You can use `Arc` or even one of the safe GC crates available, and get semantics like Java with no `unsafe`.
96.
by afdbcreid 3mo ago
`raw` is a contextual keyword.
97.
by afdbcreid 3mo ago
> > Like why do I need to use `addr_of_mut!`? > As of Rust 1.82.0 [0] you no longer need to! That's true but misleading. I'm pretty sure the question was why a normal reference is bad. You don't need `addr_of_mut!()`
98.
by afdbcreid 3mo ago
Like everything, it's about trade-offs. C is really unsafe. Rust is almost entirely safe, and breaks the ecosystem just a little bit. Fil-C is entirely safe, and breaks the ecosystem entirely.
99.
by afdbcreid 3mo ago
If you go by this metric (has a RCE and not known to have RCE), I'm pretty sure the actual statistics are more like 1 in 2, at least. And probably more than one RCE.
100.
by afdbcreid 3mo ago
I absolutely agree learning C is a good thing! In fact, there are two camps of Rust people: one that argue that you should not learn C before learning Rust, and one that argues that you should . Also, while such data structures/algo
101.
by afdbcreid 3mo ago
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. I
102.
by afdbcreid 3mo ago
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).
103.
by afdbcreid 3mo ago
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 comp
104.
by afdbcreid 3mo ago
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 m
105.
by afdbcreid 3mo ago
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 anothe
106.
by afdbcreid 3mo ago
This analysis is undecidable. There is a reason sound static analyzers (including languages like Rust) require in-code annotations.
107.
by afdbcreid 3mo ago
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/
108.
by afdbcreid 3mo ago
> 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, th
109.
by afdbcreid 3mo ago
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.
110.
by afdbcreid 3mo ago
Compilers are not security sensitive, usually. And while UB could theoretically poison the generated code, this isn't a bigger risk than logic bugs.
111.
by afdbcreid 3mo ago
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.
112.
by afdbcreid 3mo ago
No it's not. Yes it contains a lot of Rust, but it's still mostly C++.
113.
by afdbcreid 3mo ago
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.
114.
by afdbcreid 3mo ago
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 re
115.
by afdbcreid 3mo ago
If the build script can execute arbitrary processes, the entire security is lost.
116.
by afdbcreid 3mo ago
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.
117.
by afdbcreid 3mo ago
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 langu
118.
by afdbcreid 3mo ago
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
119.
by afdbcreid 3mo ago
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.
120.
by afdbcreid 3mo ago
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 converti

More ›