1. 15
  1. 5

    Steered by ANSSI.

    1. 1

      Indeed. Do you think I should edit the title to make it clearer?

    2. 4

      To me this reads like a long list “don’t do this, don’t do that”. But it’s thin on justification and guidance what to do instead.

      The guide rather oddly is very protective about leaking memory, to the point of forbidding destructors in refcounted types. The Rust project has agreed that memory leaks are not a safety issue, so I’d like to see justification why the guide disagrees.

      There’s “don’t have panics” which is easier said than done. There are tools and techniques for it, but not in this guide.

      The guide discourages, but doesn’t completely ban mem::uninitialized. That’s OTOH surprisingly lenient, because it’s a deprecated footgun.

      1. 4

        A huge number of bugs over time in sled have been due to reliance on Drop implementations to be run at certain times. Over-reliance on Drop is absolutely a bad smell for a project that intends to be reliable.

        Anyone who has been in a position to rely on code working over time would agree that Rust’s definition of safety falls far short of production readiness. Leaks are not safe for production. mem::forget is often not safe for production. etc… etc…

        1. 1

          I just had an idea where an allocator tracks allocations by call site and reserves a certain amount of memory for the callsite, so that it isn’t continuously allocated and deallocated, it puts it on a preferred allocation list. Like a soft reservation. Could reduce fragmentation as well as latency in allocations. Thoughts? Somewhere between fully static memory allocation vs completely dynamic.

          1. 2

            How does it differ from a stack? It sounds the same to me?

        2. 1

          The Rust project has agreed that memory leaks are not a safety issue, so I’d like to see justification why the guide disagrees.

          The Rust project claimed that the borrow checker prevented memory leaks until, just before the 1.0 release, they realised it didn’t, and decided that memory leaks were not a memory safety issue any more.

          1. 2

            Rust has had reference counting since the first bootstrap, and the ability to leak memory by creating cycles has always been a well-known property of reference counting.

            The designer of scoped threads didn’t think of it. That’s not the same thing as actively claiming that they are impossible.

            1. 2

              I don’t remember not-leaking-memory being a borrow checker thing. Borrowing depends on ownership, but it’s a layer on top of it. For example, the major borrowck to NLL rewrite didn’t touch drop behavior.

              The leakpocalypse was related to Drop being used to guard safety of scoped threads. After that was shown unsound and removed, there wasn’t anything left in the stdlib that needed Drop for safety, so leaking could be declared safe.

            1. 3

              I’ll make a PR about this at some point, but I have hit a lot of bugs in the development of sled related to as and casting. Clippy must be specifically configured to alert you about many of these lossy conversions, and it can flag all of the bad integer arithmetic as well. It makes things a bit clunkier to look at but it really reduces bugs over time to lean into integer hygiene.

              1. 1

                Interesting! I can imagine why lossy conversions can be a problem indeed. In any case, I am sure your PR will be very welcome. :)

              2. 1

                I feel that it is an antipattern to build explicit escape hatches into a language and then blame programmers for inability to write safe libraries. This guide does just that, explaining that unsafe is negotiable, FFI is a sometimes food that gets safer when wrapped, and assert should be avoided.

                It is unfortunate that we cannot have safe-by-default low-level languages; folks seem always concerned with speed and control, to the exclusion of structure or responsibility.