Re: VMS

The Natural Philosopher <tnp@invalid.invalid> writes:

On 20/06/2025 09:00, Richard Kettlewell wrote:

Most languages after C designed these issues out, one way or
another.
The clever bit is figuring out how to combine performance and safety,
and that’s what language designers have been working out, increasingly
successfully.

 
I don't really see how you can have a program that cannot write or
read memory beyond the intentions of the original programmer.

It’s not particularly difficult to describe (building a complete
language is more effort, of course). Some relevant techniques are:

* Automatic bounds-checking on arrays. Found in practically everything
  more recent than C (and some earlier languages, e.g. Algol). If you
  try to access an array out of bounds then you’re guaranteed a runtime
  error (what that means depends on the language, but it’s definitely
  not going to read or write something it shouldn’t). The application
  may fail if you don’t handle the error, but it does so in a
  predictable way, and it doesn’t represent an attack vector.

* Either eliminate pointers entirely, or replace with some kind of
  reference type and automated memory management.
  In concrete terms automated memory management usually means a garbage
  collector, but as Rust shows, it’s not the only option.

You write your programs slightly differently to C as a result, and there
is a performance cost, although not necessarily as you might think. But
there are huge numbers of applications written in languages that use
these strategies.


Now, if you are writing an OS kernel then at least at certain points
you’re going to need rather free access to memory, and that’s hard if
you stay purely within constraints like the above.

In some languages that’s not really an issue. Nobody is writing an OS
kernel in Python, for example. But we need to write kernels and drivers
in something...

A common approach is to segregate these operations (e.g. pointer
arithmetic) into ‘unsafe’ sections of some kind, meaning only very small
parts of the application need the extra care associated with raw
pointers etc. Everywhere else you can devote your full attention to
getting the business logic right and not worry too much about the
consequences of an array overrun or whatever.

Consider electricity as an analogy. In the home it’s insulated cables,
nice friendly plugs, shuttered sockets, etc, at least in civilized
countries. The really dangerous stuff is kept locked away in a
substation with high walls, DANGER OF DEATH signs, etc.

--
https://www.greenend.org.uk/rjk/