Thanks. Preparations for the migraion of AOS/Bluebottle are underway. Concerning memory safety: it's only memory safe if you don't use the SYSTEM module features, and OberonSystem 3 (and later) heavily depend on those features.
back
1 comments
Sure, but that in the end is what matters with memory safe systems languages, reduction of attack surface and easy to spot when safety is being disabled.
Alternative being Assembly written primitives, like in Smalltalk originally. Blue book description.
There are better alternatives than assembly. The Oberon approach would already benefit if low-level code no longer operates behind the compiler's back and instead supports full type checking. My new Micron language provides this.
Sure, in theory we could do NEWP style, where everything needed for lowlevel is provided as intrisics, and Assembly isn't even available.
However this doesn't seem to be a solution that many are keen on going through.
How is Micro doing it?
There is actually no good reason why the SYSTEM features use LONGINT instead of typed pointers. C at least has type support, even if the compiler ignores it for many situations.
Micron is doing well; the language definition has matured; it now even supports Go interfaces from level 2 onwards (i.e. even for plain records before level 3 adds dynamic memory). The primary goal of Micron is not safety, but to make a better C, Pascal and Oberon, adding some features which turned out to be very useful in C++, but without the complexity. The compiler now has an x86 and ARMv7 backend with debug support. RV32 support is on the horizon. And there is a C99 transpiler if need be.