Re: VMS

Richard Kettlewell <invalid@invalid.invalid> wrote:

Rich <rich@example.invalid> writes:

Ada accomplished it years ago (i.e., Rust is nothing new in that
regard).  But....  it did so by inserting in the compiled output all
the checks for buffer sizes before use and checks of error return codes
that so often get omitted in C code.  And the performance hit was
sufficient that Ada only found a niche in very safety critical
environments (aircraft avionics, etc.).

 
I don’t know what Ada’s approach was in detail, but I have a few points
to make here.
 
First, just because an automated check isn’t reflected in comparable C
code doesn’t mean the check isn’t necessary; and as the stream of
vulnerabilities over the last few decades show, often omitted checks
_are_ necessary. Comparing buggy C code with correctly functioning Ada
code is not really an argument for using C.

I never said it was an argument for using C.  I was responding to this
part of TNP's post with that, which you've left out above:

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

Rust's "memory safety" is nothing new.  New maybe to "Today's 10,000"
(https://xkcd.com/1053/) but not new to the world of programming.

Secondly, many checks can be optimized out. e.g. iterating over an array
(or a prefix of it) doesn’t need a check on every access, it just needs
a check that the loop bound doesn’t exceed the array bound[1]. This kind
of optimization is easy mode for compilers;
https://godbolt.org/z/Tz5KGq6vais shows an example in C++ (the at()
method is bounds-checked array indexing).

Yes, whether the Ada compiler of yesteryear (or the modern ones today)
do so I cannot say.

Finally, on all but the least powerful microprocessors, a correctly
predicted branch is almost free, and a passed bounds check is easy mode
for a branch predictor.
 
With that in mind, with compilers and microprocessors from this century,
the impact of this sort of thing is rather small. (Ada dates back to
1980, at which time a lot of these technologies were much less mature.)

Indeed, yes, on a modern CPU much of the runtime checking is less
performance eventful than it was on 1980's CPUs.  It is not free by any
measure either, some short number of cycles are consumed by that
correctly predicted branch.  For all but the most performance critical
the loss is well worth the gain in safety.  And one could argue that
"performance critical" which in the end results in some sigificant
security breech might not be as "performance critical" as it seems when
the whole picture is taken into account.