Hacker News Reader

Comment by cowlevel | Hacker News Reader

[flagged]

lol do you think that cve-rs was required? there is literally an l-unsound tag on rustc's github, this isn't some embarrassing or secret thing.

Safe rust is safe, granting `unsafe` and compiler errors. This isn't a secret.

What's l- here? Literal?

"I" stands for "issue"

https://github.com/rust-lang/rust/labels?q=unsound

lol I was writing `l` because I thought it was `labeled-unsound` for like a fucking decade

in compare to c and cpp? it is

And in absolute terms?

All memory safety on von Neumann architectures is specified with respect to a TCB. For Rust, the TCB includes the compiler. The TCB can have bugs. This doesn't invalidate the memory safety promise, given that it is made with respect to the TCB.

In contrast, memory-unsafe languages don't even try to have a TCB relative to which memory safety is specified. That's the main difference.

Literally nothing can be anything in absolute terms, what's your point? The fact is that Rust is miles better than any other language in terms of memory safety & performance ratio. That's all that matters.

Java, surprisingly, is not that much slower than Rust - but given these bugs, Java blows Rust away in memory safety. So I'd say it is the language you are looking for. Presumably any other JVM language also passes the test and maybe also CLR languages.

> but given these bugs, Java blows Rust away in memory safety.

It's not like Java is immune to memory safety-related implementation bugs either (e.g., [0]):

> A resource area allocated object is probably passed/used outside of the scope of the corresponding ResourceMark (similar to JDK-8325672).

So "blows Rust away in memory safety" doesn't seem quite supported enough?

[0]: https://bugs.openjdk.org/browse/JDK-8336095

"People still die in cars despite airbags and seatbelts so I don't see the point in wearing a seatbelt."

cmon, it is time move on.

it has been discussed bilion times

Let us not conflate a bug in an implementation (rustc) with a defect in the language (Rust).

AFAIK there isn't a language spec. Rustc is the language for now.

But bugfixes are also allowed. So the fair conclusion is that the implementation is broken, but the language is not - because it's possible to fix, and it's possible for all known soundness issues (including the cve-rs one). For this one specifically, I've heard people are already working on a fix.

My understanding is that it is work in progress, via Ferrocene.

Ferrocene is not a separate implementation of the compiler. It's the same Rustc, just a few versions behind and with a bunch of regulatory approvals attached. There is ongoing work on fixing all the unsoundnesses, happening as part of the main compiler development: https://goals.rust-lang.org/2026/roadmap-project-zero.html

Ferrocene also includes the effort to write a specification for the language, as I understand.

Ferrocene has his same flaw

If that's the case then I was wrong.

Which clause of the language specification is being violated?

Lifetimes can be effectively erased via covariant assignment. It's in the title. Even a beginner could understand these assignments are not in spec? Are you just being contrary to be contrary?

If that's the definition you're using, then C is also a safe programming language. In fact, C is even safer, because it actually does have a specification that lists all the invariants that the programmer has to uphold themselves because the compiler doesn't check them.

> In fact, C is even safer, because it actually does have a specification that lists all the invariants that the programmer has to uphold themselves because the compiler doesn't check them.

The difference is that the C spec intentionally frees the compiler from upholding those invariants. In this case the Rust compiler is failing to catch something it is required to catch.

A more accurate analogy would be a C compiler incorrectly failing to reject an assignment through a pointer to const without a cast. The spec requires that such a thing be rejected, so it's a compiler bug.

So point to the spec

https://public-docs.ferrocene.dev/main/specification/types-a...

Specifically the `q.0 = Some(&l);` violating 4.15.2:40 ("An assignment expression requires that the type of its value operand is a subtype of the type of its assignee operand.")

That's a pretty basic property of any language. Why does the rust compiler fail to enforce it in this case?

> Why does the rust compiler fail to enforce it in this case?

A bug. The one linked, that we're all talking about.

Feel free to share a link to any software that has zero bugs.

What causes the bug?

The imperfect nature of humans.

Do you have a point you’re going to share? Or is this faux Socratic nonsense just for your own personal entertainment?

this is probably a great opportunity for rust to get one, if they want to be taken seriously

I totally understand that people have favourite languages and that rust, like any language and any ecosystem around that language, has idiosyncrasies that are not for everyone, but how would one ever come to the genuine conclusion that rust is not being taken seriously? By whom?

Reply on news.ycombinator.com