Memory safety for SerenityOS

No, you can’t fix limitations of the language with API that are above the language.

Your options are:

  • Train your developers and trus them to never make mistakes (it will not work)
  • Add extra tooling such as static analyzers (we used to run Coverity but I think there was no scans in a while)
  • Use a different language, or patch the language

Yes, that’s the problem with runtime checks. And that’s what Rust gets right: it moves a lot of things to compile time, which in some cases allow to get even better performance than C (which needs a lot of checks at runtime).

That also answers why there can’t be a perfect language for everything: having all these checks at compile time is great for something where you can spend a lot of time writing the code, and it will pay off because the performance gain is important for you (embedded systems, server with lots of users, …). But in some cases you’re writing a simple script that you will run once a day or so, and then something like Python is easier to write, at the cost of having most of the checks moved to runtime.

5 Likes

I don’t really see that bytecode is a requirement… You can prove that a compiler produces safe code, and you can verify the compiler itself (e.g. compcert).

If you really want to be pedantic and guarantee all programs meet the safety requirement then you could have the compiler produce certificates that the OS can check at run time.

I would suggest, try to prove yourself wrong, don’t start with, can’t be done, start with mindset of, how can it be done.

Yes, please do prove me wrong :slight_smile:
Don’t ask me to do the work of proving myself wrong; I have more interesting things to do and someone else with different assumptions and ways of thinking will do it better than I can.

5 Likes

We know it can be done, because other languages can create machine code that does exactly that.

All of these languages are machine code abstractions, always seems to get lost in the which language is better debates.

If i had a few years to work on it i would, my plate is overflowing and there are vastly more capable programmers than myself who should be able to do this in far less time.

As I explained, the problem isn’t that C++ is too limited and can’t do what other languages can. It’s the opposite. C++ allows too many things. So, whatever you try to add safeguards, there will always be a way to write code that breaks them.

You try to declare a variable as constant with the “const” keyword? C++ has a way to modify it anyway. You use smart pointers to control the lifetime of an object? C++ has a way to ignore them, get a raw pointer and do whatever you want with it. And so on.

So you would have to remove these things from the language, or, more realistically, as Rust did, make sure these features are restricted and can be used only in blocks declared “unsafe”. Then you can tool the compiler because you can have sane expectations about how the code behaves.

So, if you want to do this with C++, the only way is, as Serenity is experimenting, making a new language that compiles into C++ or is ABI compatible with it.

9 Likes

I thought Rust allows inline c++?

It seems there are ways to do this, but I think it will result in “worst of both worlds”: you can now have all the problems caused by C++ in addition to the problems caused by Rust! And you need to learn, understand and master two languages (and toolchains and libraries) instead of just one. and then figure out how to efficiently interface them together, which is not transparent at all. For example if you have an std::map from the C++ side, can you lookup items inside it from Rust? Can you store Rust references into it and how can the compiler keep track of that to make sure the objects are not freed?

2 Likes

EDIT: wrote this before seeing @X512 comments.

Hmmmm. Rebol/Red was the downfall of SyllableOS. One of the developers advocated for it, the others accepted his suggestions and it became core. But they then failed to make it have any traction at all. Then the guy who forked AtheOS to make Syllable left the project and Kai more or less took over. The focus went on making the OS rely on Red, and I think that the overall progress of the OS stalled. It was a bad idea. Syllable faded in to obscurity.

That legacy unfortunately taints Red on my mind and makes me never want to have anything to do with it.

Haha! I wish I saw you already posted about Syllable. That is what you get reading threads a week late on your phone. I agree 100% with this. Syllable was way farther along when Haiku started. It was a self hosting bootable OS. They could and should have gone further. Rebol ended up weighing down the project.

1 Like