From Newsgroup: comp.os.vms

In article <10gg2do$3s891$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:

On 11/12/2025 6:39 PM, Brian Schenkenberger wrote:

On 2025-11-12 13:04:23 +0000, Dan Cross said:

I suspect that there is a lot of business code floating around
in memory-unsafe languages (MACRO-32, Pascal, maybe COBOL if
used in some odd ways) etc. Not to mention FFI calls from safe
languages into unsafe code.

What *exactly* is memory unsafe using Macro? You do realize that the lion's >> share of VMS is Macro???

Well ....

From what I've read, Macro-32 is down to 33% or less these days, and shrinking.

I'm not really sure just what "memory unsafe" means.

Generally what this means is that a well-defined program cannot
make an errant memory access: access to some sized datum will be
appropritely sized; no dangling pointers; no access through
uninitialized pointers; no double-frees or NULL dereferences; no
accesses beyond the end of an array, or before it. In Unix
terms, this would mean that it won't do something that would
generate a SIGSEGV or SIGBUS.

A number of languages can and do make these guarantees; many of
these languages have an unsafe superset that serves as an escape
hatch for people who need to do things that would otherwise be
unrepresentable, but in general, "memory safe" languages prevent
the programmer from making memory-related mistakes. Clearly, in
order to do this, the language has to have some notion of types.

Macro-32, as an assembly langauge, is obviously not memory safe
in this way: if I MOVL something into R0, the language doesn't
know whether that's a pointer or just a number. Perhaps a super
advanced static analyzer could do ok tracing subsequent
instructions to determing whether accesses make sense, but so
much semantic information is missing that it is hard to imagine
how it might meaningfully analyze the program to determine
whether it's accessing memory safely or not.

Nor is "idiot safe"
something that can be enforced in any language.

100% this. We can make languages _safer_ by making some things
safe, but we can't make them completely bug-free. I don't know
that anyone is trying to do that, but a lot of resistance to
say, memory safe languages seems to be from people who conflate
the two. However, memory safety eliminates entire categories of
common bugs.

Same thing with static typing; I once fixed a production outage
in a Common Lisp program that passed a list to a function that
expected a fixnum. But in a language with a strong, static type
system, that would have been a compile-time error.

Good code is relatively safe, but not always. I defy anyone to mention any >language in which I cannot do something stupid. Might exist, but I can really
be very stupid.

Such a language does not exist. Overall, the thing is sort of
like solving the halting problem: we know that we cannot solve
"THE" halting problem in general, but `for(;;);` pretty
obviously doesn't halt and is easy to detect in a program. So
we _can_ detect and solve any number of _instances_ of the
halting problem. So it is with safer languages: we can't
prevent all bugs, but we can detect and prevent a lot of them,
and if we do that in important or common areas, and the language
isn't _too_ onerus as a result, that's a net win.

Btw, I've found that programmer reactions to these sorts of
things tend to follow one of two tracks: either enthusiastic
endorsement ("yes! free me from myself!") or derisive
condescention ("I don't need that trash; I already write correct
programs!"). Of course there's some nuance in here I'm eliding,
but in terms of these broad categories, I tend to find the
better programmers falling into the former group.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2