duneroadrunner

So I don't write much C code these days, but I recently encountered strtol() again and am I mistaken or does the interface also violate const correctness? I mean it takes a const char* as the first parameter and then gives you back a (non-const) char* potentially pointing into the same string, right? Like, does strtol() get a pass because it's old, or is const correctness (still) not generally a concern of C programmers?

Last time I looked at it, c2rust translated from C to unsafe Rust, right? I'll point out a (neglected) project[1] to (partially) auto convert from C to a safe subset of C++. For example, if you need a png encoder/decoder library written in C++, perhaps the safest one is here [2].

[1] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

[2] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

At first glance it seems to be similar to boost::safe_numerics. Are there significant differences?

https://github.com/boostorg/safe_numerics

No, I just read it. SaferCPlusPlus does support all the permission "modes" listed, except the "opaque" one, and transitioning between them (though being stuck with C++'s move semantics). The permissions modes that aren't intrinsic to C++ are enforced at run-time. Objects to be mutably (non-atomically) shared need to be put in an "access control" wrapper, which is kind of like a generalized version of Rust's RefCell<> wrapper.

As I noted in my original comment, in the "mutex"/"RwLock" case, SaferCPlusPlus allows you to simultaneously hold read-locks and write-locks in the same thread. Which seems natural, since SaferCPlusPlus (and Cone) allows const and non-const pointer/references to coexist in the same thread. But in this case it actually provides increased functionality. It is the functional equivalent of replacing your mutex (and Rust's RwLock) with an "upgradable mutex", which facilitates better resource utilization in some cases, right? It also provides new opportunities to create deadlocks, so the mutex has to detect those.

Btw, I am certainly a pot talking to a kettle here, but your "mutex1" urgently needs a better name, right?

> I wrote a post about it.[1]

I just read it, and I thought it was great. I had a similar, if perhaps not-as-well-thought-out, reaction to Manish's (I agree, excellent) post. I think SaferCPlusPlus basically implements the permission mechanisms you listed in the summary (as well as the preceding "Race-Safe Strategies" post). (Although with some of the restrictions enforced at run-time rather than compile-time.) Looking forward to Cone 1.0. :)

p.s.: btw, the link on your post to the preceding "Race-Safe Strategies" post is broken

> Cone actually does support Rust-like, lifetime-constrained borrowed references

Ah, so kind of a super-set of Rust functionality. Presumably these would require a "borrow checker" or equivalent? Is that already implemented? So how do you address the safety of, say, taking a reference to an element in a (resizable) vector? Rust's "exclusivity of mutable references" restriction intrinsically makes the vector immutable while the borrowed reference exists, but do I understand that Cone doesn't have that restriction? The "C++ lifetime profile checker", on the other hand, makes the vector non-resizable (but leaves the data mutable).

> A key requirement I have placed on references (vs. pointers) is that you can always de-reference them and get a valid value

SaferCPlusPlus provides both a pointer that throws an exception if you attempt an invalid memory access (though it could just as easily return an optional<>, and you can always query if the target is valid), and one that terminates the program if its target is ever deallocated prematurely (and thus (technically) satisfies your criteria). (The latter has less/minimal overhead.)

> A Cone programmer would need to use raw pointers to throw off the shackles of lifetime constraints

Or reference counting pointers or GC, right? The features needed to implement the pointers I mentioned is either support for calling a destructor on move operations or the ability to make an object non-movable, and, support for copy constructors or the ability to make an object uncopyable. Does/could your language support some combination of those features?

I explain the reason the pointers are important in an article called "Implications of the Core Guidelines lifetime checker restrictions" [1]. Specifically, I give an example of reasonable C++ code [2] that historically had no corresponding efficient implementation in Safe Rust. (I think it's still the case, but I haven't fully investigated the implications of Rust's new "pinning" feature.) It can, however, be implemented in a memory safe way using the SaferCPlusPlus pointers in question [3]. Basically the example just temporarily inserts a reference to a (stack allocated) local variable into a list (or whatever dynamic container), given that the local variable does not outlive the container.

> especially given that borrowed references and raw pointers are both able to point inside an allocated object

SaferCPlusPlus has the equivalent of "borrowed references"[4] (though even more restricted until C++'s "borrow checker" (the aforementioned "lifetime profile checker") is completed), and they can safely point "inside" (allocated) objects. Note that the second safe pointer type (the one that potentially terminates the program), is a "strong" pointer, and there is a simple mechanism for obtaining a "borrowed reference" from a strong pointer [5]. And from there, a simple mechanism for obtaining a reference to an (interior?) member [6].

The other pointer (the one that potentially throws an exception) would be considered a "weak" pointer, and you cannot obtain a "borrowed reference" directly from a weak pointer. But often, the weak pointer is used to target an object that can yield a borrowed reference (like a strong pointer, for example), or a borrowed reference directly.

> all the best with getting others to learn about and adopt your language.

You too :) I can see the appeal of this sort of clean, flexible language. But in the case of SaferCPlusPlus the goal is not necessarily (just) for programmers to adopt it. In part it's maybe a demonstration (to language designers such as yourself :) of a set of language elements that use run-time safety enforcement mechanisms but are a little more flexible than (and might be a good / (unintuitively) needed complement to) their counterparts that rely on strictly compile-time safety enforcement.

Oh and if you do get around to checking out SaferCPlusPlus in more depth, apologies for the inadequate documentation in advance. Feel free to post any questions you might have. :)

[1] https://github.com/duneroadrunner/misc/blob/master/201/8/Jul...

[2] https://github.com/duneroadrunner/misc/blob/master/201/8/Jul...

[3] https://github.com/duneroadrunner/misc/blob/54204445bc099987...

[4] https://github.com/duneroadrunner/SaferCPlusPlus#txscopeitem...

[5] https://github.com/duneroadrunner/SaferCPlusPlus#make_xscope...

[6] https://github.com/duneroadrunner/SaferCPlusPlus#make_pointe...

> I only post to HN to plug my project called SaferCPlusPlus

From this account, yes. Too much? Sorry, (you can see) I haven't gotten much feedback. Or is having a separate, project-specific account in itself not cool?

> not ever to talk about the submitted article.

I try to post/plug only when I think it's relevant. I think. For example, in the "gmm.pdf" linked in the comment I responded to, the author says that specific types of references can only target objects owned/allocated by the associated allocator. There is no available reference type that can target objects from different allocators. References in Rust, for example, can target any object regardless of how they were allocated, but imposes strict restrictions that the author implies he's trying to avoid.

So I tried to point out that SaferCPlusPlus has pointer types that can safely target objects allocated by different allocators and do not have the strict restrictions of Rust's references. As far as I know, these types of pointers are (still) unique to SaferCPlusPlus, and I assume I am one of a few people who is familiar with these pointers. But there's nothing proprietary about them. If the author is constructing a language with a goal of flexibility wrt to memory safety, I thought he might consider whether such pointer/reference types might be compatible with his language design. I think they unquestionably increase flexibility (while maintaining memory safety).

If maximum (or just more) flexibility wrt memory safety is the goal, I might suggest the author take a look at SaferCPlusPlus. In particular, it supports memory safe pointer/references[1][2] that can target objects associated with different allocators (including stack allocated objects) without, as the author desires, imposing the "sometimes confining" restrictions that Rust does. And in terms of data race safety, it allows you to hold "read-lock" and "write-lock" pointer/references simultaneously in the same thread [3], which adds a little extra functionality (and maybe convenience).

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus#registered-...

[2] https://github.com/duneroadrunner/SaferCPlusPlus#norad-point...

[3] https://github.com/duneroadrunner/SaferCPlusPlus#tasyncshare...

> What guarantees that the "while" loop will not run away and take "data" outside the array bounds?

What do you mean "the array bounds"? The code is memory safe. "data" is an iterator that knows exactly what array/container it's pointing to, and that container knows its own size. Dereferences are bounds checked (by default).

This translated code is not intended to be performance optimal. The translator does not add, remove or rearrange any of the original source code elements, it simply replaces some of them with macros that are defined as functionally equivalent, memory safe C++ substitutes for the original element. Doing it this way has the benefit of allowing you to "disable" the memory safety mechanisms by reverting the macro definitions to the original (unsafe) elements.

I have not yet gotten around to addressing performance of the translated code. In order to preserve the ability to revert back to pure C code, there would need to be an additional set of macros (like maybe an "array view" macro) that could be mapped to their (safe) high performance C++ counterparts but that would be more restricted in their usage.

But at this point I think the value of that is questionable. If you need your code to be memory safe and high performance, the most expedient thing to do is to just accept the translated code as C++ code (or SaferCPlusPlus code) and re-optimize the performance bottlenecks as idiomatic SaferCPlusPlus code. SaferCPlusPlus is, along with Rust, the fastest [1] option for memory (and data race) safe programming.

And if you don't like the C++ language as whole, just (define and) stick to a subset you're comfortable with, right? I mean, (I think your proposal is fine as an extension of C, but) I don't see the point in extending the C language with things like views/slices/spans, when the C language is already extended with those. It's called C++ (or some subset thereof) right? And with C++ you can solve the memory (and data race) issues much more comprehensively and performantly (if that's a word :) than with any extension to C. No?

[1] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...

Thanks for noticing :) It's been quite a while since I worked on the code, but I believe that the translator intentionally left types declared as "char {star}" unmodified assuming that they were being used as strings [1] rather "regular" array buffers. I'm guessing that dealing with strings would have been a lot more work because it would require providing safe compatible replacements for all the standard C library string functions.

I think you should find that array buffers of other types, like "unsigned char" or "const unsigned char", and their associated pointer iterators are translated to their corresponding macros. I'd be interested if you find otherwise. If you're interested, the relevant code for the translator is in the "safercpp" subdirectory [2]. It's not super-well commented so if you have any questions feel free to post them in the "issues" section of the repository.

[1] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

[2] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

> "Unknown" ranges from 49% to 76%.

Yeah, this is interesting. They're saying they can't determine whether a pointer targets an array buffer or not? Perhaps they might want to take a look at the (long neglected) "C to SaferCPlusPlus" translator[1] which can do this. (It was an unexpectedly taxing undertaking though.) It converts C arrays and allocated buffers used as arrays into memory safe implementations of std::array<>s and std::vector<>s, so failure to properly identify them would generally result in output code that wouldn't compile.

The examples they give of problematic code in the paper:

    void f(int* a) {
        *(int**)a = a;
    }

and

    f1(((int*) 0x8f8000));

don't strike me as the kind you would often encounter in real-world code.

> The syntax they use is rather clunky

The output code of the "C to SaferCPlusPlus" translator replaces the types and declarations with macros[2] that can be redefined with a compile-time directive to either use the safe C++ implementation, or revert to the original unsafe native C implementation. The argument being that using macros instead of custom syntax makes the source code more versatile. And existing C programmers already "get" macros.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

[2] https://github.com/duneroadrunner/SaferCPlusPlus/blob/master...

For cases where the platform supports C++ (and its standard library), there is kind of a corresponding "checked C++"[1] that also supports the "completely incremental" migration approach. (And obviously supports "array view" type objects.)

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus#safercplusp...

Oh yeah, there are plenty of reasons to prefer Rust over C++. I think it's also reasonable to favor Rust's "exclusivity of mutable references" default as a matter of personal preference. I'm just not sure the formal or technical argument has yet been made that universally applying that restriction is necessarily the "better" default overall.

Yes, It's hard to deny the intuitive appeal, but what's notably missing from that blog post, and seemingly any other article about it, is a consideration of the cost/downsides of universal imposition of the "exclusivity of mutable references" restriction. Rust provides the RefCell wrapper to essentially circumvent the restriction on demand, but i) that also essentially circumvents the "invariant protection" benefits of the policy, and ii) you can just as easily use an equivalent wrapper[1] in C++ to impose the same restriction. At which point the difference between Rust and C++ just kind of becomes which policy do you want to be the zero-overhead default.

I mean you could imagine a hypothetical future scenario where it is demonstrated that the optimizers are good enough to essentially eliminate the run-time cost of RefCell wrappers, and a lot of Rust programmers just start wrapping everything with RefCells by default.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus#exclusive-w...

Rust's usability is advancing, but I'll note that so are C++'s memory safety facilities. Arguably, modern C++ programming is becoming intrinsically more safe than more traditional coding styles (though arguably the use of string_views and spans outside of function parameters is a step backwards), but progress is also being made on the lifetime profile checker (C++'s borrow checker analogue), and there are libraries[1] that allow you avoid potentially unsafe C++ elements, to the degree that (memory and data race) safety is a priority.

At present, C++ is significantly lacking in safety enforcement tooling and "community enthusiasm" for memory safety compared to Rust. But to me, it is not obvious that that will be the case indefinitely. It's even plausible that Rust and C++ will sufficiently converge in flexibility and safety that at some point automated translation between the two languages will be a thing.

At the moment, I think the main relevant difference in fundamental (as opposed to not-yet-available tooling or whatever) capability between the two languages is Rust's lack of support for move constructors/destructors. I think it prevents the safe, efficient, unintrusive, robust implementation of a small but significant set of algorithms / data structures.

But I guess my point is that I think that C++, and its existing codebases, are not necessarily condemned indefinitely to be memory unsafe in the way they have been historically. And that could be a factor that contributes to the justification of deciding to continue to use C++ in some cases.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

ArrayBufferBuilder isn't, but DOMArrayBuffer seems to be a GC managed type [1], right? And, before the patch, the DOMArrayBuffer held a "refcounting pointer" potentially targeting raw_data_'s reference counted ArrayBuffer, right? I don't see any immediately apparent use-after-free with this, so I assume raw_data_'s ArrayBuffer is being messed with elsewhere? As someone who worked on the code, do you have an idea/hunch about where the invalid memory access actually occurs?

https://github.com/chromium/chromium/blob/ba9748e78ec7e9c0d5...

Ug. After closer inspection, it looks like those particular raw pointers seem to be managed by a garbage collector. (Specifically, the "Blink GC" [1].) As others have pointed out, this particular bug may not actually be a C++ issue. (Or at least not a typical one.)

[1] https://chromium.googlesource.com/chromium/src/+/master/thir...

They are working on it. The analogue to the borrow checker in C++ is called the "lifetime profile checker" and (an incomplete version) is included in MS Visual C++, but last time I checked (in January) it seemed to still have too many false positives to be practical.

In the mean time, I think "the minimum necessary changes" to achieve memory and data race safety is to replace all your unsafe C++ elements (pointers, arrays, vectors, string_views, etc.) with compatible substitutes from the SaferCPlusPlus library [1]. You don't even need to replace them all at once. You can replace them incrementally and your code will continue to compile and run throughout the process. And where needed, maintain maximal performance as well [2].

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

[2] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...

I suggest that the most expedient (cheapest) language to migrate the existing code base to would be a memory safe subset of C++ [1]. In practice most of the safety benefit could be obtained from a just a partial migration. Specifically, just banning raw pointers/views/spans and non-bounds-checked arrays and vectors. From a quick glance at the code in the (quite small) patch diff, the code in question includes:

    DOMArrayBuffer* result = DOMArrayBuffer::Create(raw_data_->ToArrayBuffer());
    
    ...
    
        raw_data_.reset();
    
    ...
    
   return result;

I'd imagine the effort/time/money it would take to replace those raw pointers with memory safe substitutes [2][3][4] (and enforce the ban going forward) would be relatively modest. Performance shouldn't be an issue [5].

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

[2] https://github.com/duneroadrunner/SaferCPlusPlus#registered-...

[3] https://github.com/duneroadrunner/SaferCPlusPlus#norad-point...

[4] https://github.com/duneroadrunner/SaferCPlusPlus#scope-point...

[5] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...

I'll just mention that if you're using C++, the SaferCPlusPlus library[1] supports a data race safe subset of C++, vaguely analogous to Rust's.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus#multithread...

Replacing existing unsafe C++ elements with compatible memory safe substitutes[1] might be more expedient. The conversion can even be automated[2] for parts of the code that aren't performance critical.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

[2] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

> it was slower for a dubious benefit

Isn't this kind of arguable? The benefit is that it avoids the need to make unnecessary copies in some cases, as is basically acknowledged in the article:

> The exclusivity violation can be avoided by copying any values that need to be available within the closure

Right? And in addition to the local cost of the extra copy, there's also the more ubiquitous cost of these run-time checks. Yes, there's the potential benefit of better optimization due to the non-aliasing guarantee, but I think it's far from clear that it's an overall performance win.

While I think it's reasonable to adopt a universal "exclusivity of mutable references" policy in order to achieve memory safety and address a fear of a (vaguely-defined) notion of "mutable state and action at a distance" (referred to in the article), particularly for a language like Swift, I think it would be improper to dismiss the associated costs, or even to imply that the costs are well understood at this point. Or to imply that this policy is, at this point, known to be an optimal solution for achieving memory (or any other kind of code) safety.

Well if you're starting a project now that you expect to live for many years, there's the issue of C++ safety now, and C++ safety in the foreseeable future.

Right now projects have the option of building with the santizers (particularly the address sanitizer) enabled, right? The executable would be slower and less memory efficient, but it would eliminate most of the critical CVEs that exploit invalid memory access. Is there a reason Google couldn't provide alternative builds of Chrome with the santizers enabled?

As for the foreseeable future, you can come up with arguments (convincing or otherwise) that C++ will be effectively memory (and data race) safe in the foreseeable future. At some point, presumably the core guidelines lifetime checker will enforce memory safety. To what degree it will in practice is a matter of speculation, but in theory it could be as effective as the Rust compiler.

Just as an observation, if you peruse the chromium source code, from a modern C++ perspective, there seems to me to be an alarming prevalence of raw pointers. (Probably understandable as chromium's been around for a while.) C++ is now a very powerful language, and if (memory) safety is a priority it is already practical (and performant[1]) to avoid the use of notoriously unsafe elements like raw pointers and unchecked buffers in favor of safer alternatives. (It is similarly practical to avoid data race prone elements[2].)

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...

[2] https://github.com/duneroadrunner/SaferCPlusPlus#multithread...

Yes, and in C++, linked lists can retain this property and be implemented in a memory safe way using non-owning reference-counting smart pointers[1].

Many defend the use of unsafe Rust in cases like these, in part by asserting that C++ would have the same (un)safety issue. I don't think that's right. A C++ implementation would not have to use (unsafe) raw pointers, or (expensive, intrusive) owning pointers from the standard library.

I think C++ has the advantage in cases like these because of the aforementioned non-owning reference-counting smart pointers. I don't think the same type of pointer/reference can be implemented in Rust (as it would need a constructor), but it's not immediately obvious to me that such a reference type couldn't be added to the language as an intrinsic element (like Rc). I think such an element is dearly missing from the Rust language. I suspect that adding it would make the language safer and easier to use.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus#norad-point...

Well like I said, if you already have a driver written in C (or C++), translating it to the safe subset of C++ would be less work as most of the code would remain unchanged and the unsafe elements (like pointers, arrays, etc.) map to direct (safe) replacements. And your driver maintainers/authors may already be familiar with C++ (if not big fans of it :) .

While the OP may demonstrate that other languages aren't always that bad in practice, I think the consensus is that Rust and C/C++ are the appropriate languages when maximum efficiency and minimum overhead are desired.

While Rust is a good option, the (safe subset of the) language has an intrinsic shortcoming that doesn't seem to be generally acknowledged. The forthcoming C++ "lifetime checker" (static analyzer) has the same issue [1]. Essentially, if you have a list (or any dynamic container) of references to a given set of existing objects, you cannot (temporarily) insert a reference to a (newly created) object that may not outlive the container itself.

In my view, this is a problem. The workarounds are intrusive, inconvenient and/or involve significant overhead. Which makes it tempting to just resort to unsafe Rust in those cases. (And of course this specific example is representative of a whole class of situations with a similar dilemma.) The safe C++ subset doesn't suffer the same issue. (Because in some sense, C++ is still a more "powerful" language.)

[1] https://github.com/duneroadrunner/misc/blob/master/201/8/Jul...

Another option is to use a memory safe subset of C++ [1]. It should be less work to migrate existing C drivers as (reasonable) C code maps directly into the safe C++ subset. And the migration can be done incrementally with corresponding incremental safety benefits.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

equally shameless: https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

Yeah, with modern C++, you can largely choose to avoid using elements that are prone to undefined behavior. For example, rather than native integers, you could use a compatible integer class that checks for division by zero [1]. Or one that checks for overflow too [2]. The Core Guidelines lifetime checker aims to (eventually) make native pointers and references memory safe via (severe, but not quite as severe as Rust) usage restrictions. And when you need to circumvent the restrictions, you can use an unrestricted smart pointer with run-time checking [3][4].

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus#primitives

[2] https://github.com/boostorg/safe_numerics

[3] https://github.com/duneroadrunner/SaferCPlusPlus#registered-...

[4] https://github.com/duneroadrunner/SaferCPlusPlus#norad-point...

> I want the standards committee to produce a bounds-checked dialect of C where I can choose to pay some perf cost to get real dynamic and bounds-checked arrays

If you don't want to wait on the standards committee, the SaferCPlusPlus library provides memory-safe substitutes for commonly used unsafe C/C++ elements (including pointers). These memory-safe elements require a C++ compiler, but because they are largely compatible with their native counterparts, you can write programs that can switch between using memory-safe (C++) elements and (unsafe) straight C elements with a compile-time directive.

That is, you don't have to choose between safety and performance when authoring the code. You can make the choice at build-time. So you could, for example, provide both "memory-safe" and "non-memory-safe" builds of your software. There was even a (now long neglected) tool[1] to automatically replace arrays/buffers in C source code with (optionally) memory-safe substitutes. (Not just bounds-checked, but safe from use-after-free.)

> I know I'd trade 10% perf for the elimination of whole classes of security vulnerabilities.

Full memory safety may sometimes cost a bit more than that [2]. But a nice thing about this approach is that you can choose to use (faster) unsafe code in critical inner loops, and memory-safe code everywhere else.

[1] Shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

[2] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...

> That's not right. You can have a data race to a plain old integer.

Sure, if your language allows unprotected access to any object from any thread. Which, I guess traditional C++ essentially does, but presumably a "Safe" C++ would eventually have an "asynchronous sharing" checker that would require any shared objects to be appropriately "protected".

> > only its structure

> I am not 100% sure what distinction you're making here, sorry. What's "the container" vs "its structure"?

For example:

    std::vector<int> vec1 {1, 2};
    {
        const auto& cref1 = vec1.at(0);
        auto& ref2 = vec1.at(1);
        ref2 = 3;
        auto& ref1 = vec1.at(0);
        std::cout << cref1;
        ref1 = 4;
        
        // co-existing const and non-const references are permitted and memory safe here
        
        std::cout << vec1.size();
                
        vec1.at(0) = 5;

        vec1.clear(); // <---- Rejected by the lifetime checker
        
        // because the clear() call mutates the structure.
        
        // Mutating the data contained in the vector is permitted though.
        
        std::cout << cref1;
    }

> Yes, in general, Rust takes a soundness-based approach. If you can't prove that it's safe, then it's not safe.

The approach is not that different. The lifetime checker applies (or will apply) basically the same sorts of restrictions that the Rust compiler does (and "break" backward compatibility in the process), but only when necessary to enforce memory safety.

I mean, the way the lifetime checker works is that it basically keeps track, at compile-time, of the latest possible death-time of every reference and the earliest possible death-time of the target object (or potential target objects) that each reference points at, and complains anytime the former is later than the latter.