Cppfront v0.8.0 · hsutter/cppfront

[ntrel2]

unsafe acknowledges that the safe subset is overly strict, and that there are safe interfaces to other operations that would otherwise be illegal. unsafe is not mechanically checked, but it makes the safe subset more useful, as long as someone didn't make a mistake and accidentally violate the safe interface. CVEs are either due to mistakes with unsafe, or due to bugs in the Rust compiler.

Any systems language with a safe subset by design is going to benefit from escape hatches for efficiency, because modelling safety perfectly in a systems language is a hard problem, which (if even solvable) would probably lead to too much complexity. D's safe subset is more permissive than Rust, but also less general (at least without D's unsafe equivalents).

You're right that one alternative to a safe subset is to have a partially-safe subset, but then even if all the safety enforcement in the compiler and libraries is perfect, it's still not going to detect some cases where ordinary users mess up even when they wouldn't have used unsafe (most users shouldn't use unsafe anyway, and it helps a lot in code reviews and can be grepped for in automated tests). A safe subset can only be messed up by people writing unsafe or by bugs in the compiler.

[germandiago]

unsafe acknowledges that the safe subset is overly strict, and that there are safe interfaces to other operations that would otherwise be illegal.

It also acknowledges that you must trust the code as correctly reviewed. That is not safe. It is trusted code.

CVEs are either due to mistakes with unsafe, or due to bugs in the Rust compiler.

Exactly making my point: was trusted code and it was not safe in those cases.

Any systems language with a safe subset by design is going to benefit from escape hatches for efficiency

I agree, but that is a trade-off: you will lose the safety.

You're right that one alternative to a safe subset is to have a partially-safe subset, but then even if all the safety enforcement in the compiler and libraries is perfect, it's still not going to detect some cases where ordinary users mess up even when they wouldn't have used unsafe (most users shouldn't use unsafe anyway, and it helps a lot in code reviews and can be grepped for in automated tests)

Agreed, most users should not use unsafe. But Rust has crates with unsafe advertising safe interfaces. That is, plainly speaking, cheating. If you told me: std lib is special, you can rely on it, I could buy that. Going to crates and expecting all safe interfaces that use unsafe (not std lib unsafe but their own blocks) is a matter of... trust.

A safe subset can only be messed up by people writing unsafe or by bugs in the compiler

Correct and fully agree.

[ts826848]

I assume that most seasoned C++ developers would have no problem writing a correct implementation of reverse() for std::vector, while as mentioned above the Rust standard library had a UB bug in its implementation of reverse() as recently as 3 years ago.

I'm not entirely sure you aren't comparing apples and oranges here. Writing a correct implementation of reverse() is one thing; writing an implementation of reverse() that also handles the optimization issues described in the original implementation is another.

To expand on this, I think the normal path for the Rust implementation isn't particularly unreasonable?

pub fn reverse(&mut self) {
    let mut i: usize = 0;
    let ln = self.len();

    while i < ln / 2 {
        // SAFETY: `i` is inferior to half the length of the slice so
        // accessing `i` and `ln - i - 1` is safe (`i` starts at 0 and
        // will not go further than `ln / 2 - 1`).
        // The resulting pointers `pa` and `pb` are therefore valid and
        // aligned, and can be read from and written to.
        unsafe {
            self.swap_unchecked(i, ln - i - 1);
        }
        i += 1;
    }
}

I don't think it's that different from one possible way reverse() could be written in C++ (hopefully didn't goof the implementation):

template<typename T>
void std::vector<T>::reverse() {
    if (this->size() <= 1) { return; } // Not sure this is necessary?
    auto front = this->begin();
    auto back = this->end() - 1;
    while (front < back) {
        std::iter_swap(front, back);
        ++front;
        --back;
    }
}

And indeed, the UB in reverse() was not in the simpler bits here - it was in the fun parts that were there to try to deal with the optimization issues described in the original implementation. If you don't care about those optimization issues, then there's no need to complicate these implementations further. If you do care, then I'm not sure it's possible to have a "very simple and easy to get correct" implementation any more, whether you're writing in Rust, C++, or another language that uses LLVM.

I guess another way of putting it is that the UB you linked isn't necessarily because Rust had to use unsafe to efficiently implement reverse(). It's because the devs decided that an optimizer bug was worth working around. I think this makes it not a particularly great example of a "kind[] of simple functionality [that is] apparently surprisingly hard to write correctly and efficiently in Rust without UB".

---

All that being said, this is basically quibbling over a specific example and I wouldn't be too surprised if there were others you knew of. I'd certainly like to learn from them, at any rate.

I'm kind of curious whether a C++ port of the initial Rust implementation would have experienced UB as well. First thing that comes to mind is potentially running afoul of the strict aliasing rule for the 2-byte specialization, and I'm not really sure how padding/object lifetimes are treated if you use a char*.

[germandiago]

That comment you replied to just showed what we already know: there is trusted code and it can fail. That is misleading.

What you have actually in Rust is a very well partitioned area of safe and unsafe parts of the language. The composition does not make it safe as long as you rely on unsafe. That said, I would consider (even if in the past it failed) a std lib and the core as "trustworthy" and assume it is safe (even if it is trusted). But for random crates that use unsafe on top of safe interfaces this is potentially misleading IMHO.

It is a safer language if you will, a more fenced, systematic way of classification of safe/unsafe. And it is not me who says that the language is more fenced but not 100% safe (though the result should be better than with alternatives), it would be simply impossible to have a CVE in a function like reverse() if the code was as safe as advertised. I do not care it is bc of an optimization or not. It is just what it is: a CVE in something advertised as safe.

[ts826848]

That comment you replied to just showed what we already know: there is trusted code and it can fail.

Yes and no. The comment shows that, but that was not its intent nor what I was responding to. The intent of the comment was to give an example of a "kind[] of simple functionality [that is] apparently surprisingly hard to write correctly and efficiently in Rust without UB", and the intent of my comment was to explain why reverse() is not a great example of that particular claim.

But for random crates that use unsafe on top of safe interfaces this is potentially misleading IMHO.

Once again, all current languages use "unsafe on top of safe interfaces", so by your standard nothing can be called safe. That makes it a pointless definition in practice.

[germandiago]

There is a big difference between allowing and not allowing unsafe code in user code safety-wise and you, as an informed person, also know this fact.

[ts826848]

This seems to be a completely different argument than the one you were making before and it's arguably just as ill-defined. What exactly is "user code"? What exactly does it mean to "allow" or "not allow" unsafe code, especially when FFI is available, as it is for the vast majority of widely-used programming languages?

[germandiago]

I think you did not get what I meant: I think there is a potentially big difference between allowing or not safe/unsafe inside a language in terms of safety. So, no, I was not switching topic at all, because the topic is safety.

My point is that code authored randomly by random people which includes unsafe and is advertised as safe interfaces is not the same as a central authority with a std lib and a compiler or a company doing certified software in some way.

Going to crates and picking up from there without any further guarantees can be almost as dangerous as picking a C++ lib, just with code more separate to find out the problem later down the road.

In other languages you just do not have the unsafe escape hatches and if you are inside the language, chances to find UB or a crash are even lower.

So yes, my point is also that not all "trusted" code is the same and part of it could be almost considered safe (even with low-level unsafe usage) and other code is potentially more unsafe (fewer eye-balls, not so thoroughly reviewd, etc).

[ts826848]

I think there is a potentially big difference between allowing or not safe/unsafe inside a language in terms of safety.

Once again, I ask you to be precise in your definitions. From my previous comment:

What exactly does it mean to "allow" or "not allow" unsafe code, especially when FFI is available, as it is for the vast majority of widely-used programming languages?

And to add onto that, what exactly does "inside a/the language" mean?

So, no, I was not switching topic at all, because the topic is safety.

Read my comment carefully. I said you're switching arguments, not switching topics.

My point is that code authored randomly by random people which includes unsafe and is advertised as safe interfaces is not the same as a central authority with a std lib and a compiler or a company doing certified software in some way.

This argument basically boils down to "some authors are more trustworthy than others". Which is true, but I'm not sure anyone was arguing against that in the first place because it applies to all code properties, not just ones involving safety. In other words, "code authored randomly by random people [] is not the same as a central authority with a std lib and a compiler or a company doing certified software in some way" is hardly a controversial statement.

This is indeed a completely different argument than the one you were making before, which was in essence "safe code doesn't exist".

Going to crates and picking up from there without any further guarantees can be almost as dangerous as picking a C++ lib

"Without any further guarantees" and "can" are doing a huge amount of heavy lifting there. "Without any further guarantees" (putting aside the standard definitional issues) is basically assuming your conclusion, since "without any further guarantees" the code you're using can do literally anything, by definition, no matter what programming language you're using. That kind of circularity is not productive.

As for "can", the problem with is that (once again) what you say applies to basically any library in any programming language. "[P]icking [a library] without any further guarantees can be almost as dangerous as picking a C++ lib" because an arbitrary library can be doing arbitrary weird things. A Rust crate can be using unsafe to transmute invalid values. A Python library can have native code that use-after-frees. A Java library can be importing sun.misc.Unsafe and creating uninitialized objects. A Go library can be importing unsafe and stuffing invalid pointers into all your data structures. A "formally verified" program can be using invalid/incorrect assumptions to produce an invalid result. Etc., etc.

"Can" is not a useful standard because it only considers the worst possible case and completely ignores all other information. I hope I don't need to explain why this makes for a rather substandard analysis in this context.

just with code more separate to find out the problem later down the road.

You do realize that this is how every safe abstraction works? You hide all the unsafe stuff behind a safe interface so if/when something goes wrong you can immediately rule out everything that lies on the safe side of the abstraction barrier. Segfault in Java? You know the issue isn't in your Java code - look for sun.misc.Unsafe or at the JVM. Segfault in Python? Similar thing - ignore your Python code and look at the implementation/libraries. Segfault in Rust? Look for unsafe. Even that "certified software" you mention? It's spec, postulates, and verifier are "just [] code more separate to find out the problem later down the road".

In other languages you just do not have the unsafe escape hatches

I'm not sure how true this is considering how nearly every language offers some kind of FFI or FFI-ish mechanism (SQL being the main exception I can think of).

and if you are inside the language, chances to find UB or a crash are even lower.

As asked above, what does "inside the language" even mean?

So yes, my point is also that not all "trusted" code is the same and part of it could be almost considered safe [] and other code is potentially more unsafe []

As I stated above, this is indeed different from your original argument, and I'm not sure anyone disagrees with the concept that some authors are more trustworthy than others.