Re: VMS

On 6/20/25 5:19 AM, The Natural Philosopher wrote:

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

c186282 <c186282@nnada.net> writes:

On 6/19/25 3:40 AM, Richard Kettlewell wrote:>

c186282 <c186282@nnada.net> writes:
    IMHO, stick to 'C' ... but use GOOD PRACTICES.
>
The software industry has been trying this for decades now. It does
not work.

>
At some point, soon, they need to start flagging the unsafe functions
as ERRORS, not just WARNINGS.

>
The problem is not just a subset of unsafe functions. The whole language
is riddled with unsafe semantics.
>
There is some movement towards fixing the easy issues, e.g. [1]. But the
wider issues are a lot harder to truly fix, so much so that one of the
more promising options is an architecture extension[2]; and there
remains considerable resistance[3] in the standards body to fixing other
issues, despite their recurring role in defects and vulnerabilities.
>
[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3322.pdf
[2] https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
[3] https://www.youtube.com/watch?v=DRgoEKrTxXY
>
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.
 Sure if its a different process but simply reading one byte beyond the end of a buffer is going to be hard.
 And probably make the language very hard to use when you are dealing with multi-typed data.
 I do like, at a cursory glance, the second link. Hardware that protects memory is a great leap forward

   Yet SOME attacks exist to take advantage of those
   very inbuilt 'smart' functions  :-)
   CPUs have become SO complex now ... they are like
   a whole busy multi-user/tasking near-AI program unto
   themselves.
   Z80's anyone ?  :-)