3 ms·

What's the alternative? https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=ab648af31586d776004fd9296e276106 https://play.rust-lang.org/?ve

• zamadatix 6mo ago
  .get() will bounds check and the compiler will optimize that away if it can prove safety at compile time. That leaves you 3 options made available in Rust: - Explicitly unsafe - Runtime crash - Runtime crash w/ compile time avoidence when possible
• omcnoe 6mo ago
  https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=1f4a6572ff4691a4321b4f5167316905 https://play.rust-lang.org/?version=stable&mode=debug&editio... Catch the panic & unwind, safe program execution continues. Fundamentally impossible in Fil-C.
  • wakawaka28 6mo ago
    Seems like a niche use case. If it needs code to handle, it's also not apples to apples...
    • omcnoe 6mo ago
      It's an apple to non-existent-apple comparison. Fil-C can't handle it even with extra code because Fil-C provides no recovery mechanism. I also don't think it's that niche a use case. It's one encountered by every web server or web client (scope exception to single connection/request). Or anything involving batch processing, something like "extract the text from these 10k PDFs on disk".
      • wakawaka28 6mo ago
        Sure, it's not implemented in Fil-C because it is very new and the point of it is to improve things without extensive rewrites. Generally, I think one could want to recover from errors. But error recovery is something that needs to be designed in. You probably don't want to catch all errors, even in a loop handling requests for an application. If your application isn't designed to handle the same kinds of memory access issues as we're talking about here, the whole thing turns into non-existent-apples to non-existent-apples lol.
        • saghm 6mo ago
          The root comment here said this: > All this "rewrite it in rust for safety" just sounds stupid when you can compile your C program completely memory safe. All of the points about Rust were made in that context, and they've pushed back against it successfully enough that now you're trying to argue from the other side as if it disproves their point. No one here is saying that there's no point in having safer C code or that literally everything needs to get rewritten; they're just pointing out that yes, there is a concrete advantage that something in Rust has over something in C today even with Fil-C available.
          • wakawaka28 6mo ago
            There are many concrete disadvantages to writing things in Rust too, not to mention rewriting. But you are right, these are different solutions and they thus have different characteristics. As for your "as if it disproves their point" stuff is wrong. The fact is, the reply to a comment in a thread is not a reply to a different one. You are implicitly setting up a straw man like "See, you are saying there are NO advantages to using Rust over Fil-C" and I never said that at any point. I also didn't say that you said that there was no advantage to using Fil-C.
            • saghm 6mo ago
              My point is that no one here defending Rust is trying to say that Fil-C doesn't offer anything useful or claim that Rust is better in all circumstances. When one person says "A is strictly better than B", and some people respond "Here are some cases where you'd still get benefits from B over A", coming in and saying "A is better in these other circumstances" isn't saying anything that people aren't already aware of.
              • wakawaka28 6mo ago
                >coming in and saying "A is better in these other circumstances" isn't saying anything that people aren't already aware of. Oh so you're a psychic now too? I think all kinds of people read these threads. Most of them probably aren't as aware as you're claiming, even the ones actively commenting on the topic.
  • uecker 6mo ago
    I do not know how Fil-C handles this, but it could raise a signal that one can then catch.
    • jz391 6mo ago
      Reminds me of a commercial project I did for my old University department around 1994. The GUI was ambitious and written in Motif, which was a little buggy and leaked memory. So... I ended up catching any SEGVs, saving state, and restarting the process, with a short message in a popup telling the user to wait. Obviously not guaranteed, but surprisingly it mostly worked. With benefit of experience & hindsight, I should have just (considerably) simplified it: I had user-configurable dialogs creating widgets on the fly etc, none of which was really required.
• touisteur 6mo ago
  SPARK does static analysis (proof) of Absence of Runtime Errors (AoRTE).
  • ngrilly 6mo ago
    Yes, but that requires eliminating aliasing and expressions with side effects?