Groups | Search | Server Info | Login | Register

Groups > comp.os.vms > #378157

Re: VMS Bootcamp

Show all headers | View raw

In article <10f30sp$1koun$4@dont-email.me>,
Arne Vajhøj  <arne@vajhoej.dk> wrote:
>On 11/12/2025 8:04 AM, Dan Cross wrote:
>> In article <10eok5t$2u3pu$1@dont-email.me>,
>> Arne Vajhøj  <arne@vajhoej.dk> wrote:
>>> Rewriting the business application from one
>>> memory safe language (Java, C#, Python, Pascal
>> 
>> Given the `POINTER` type, consequent support for type-casting
>> pointers, and dynamic memory allocation, it's hard to understand
>> how VSI Pascal can be considered meaningfully memory safe in the
>> way that Rust or a managed language is.
>
>The US government considers Pascal a memory safe language.
>
>:-)

Have you seen the state of my government recently?  :-(

>But I think you are right about it being a bit questionable.
>
>I consider the 3 biggest memory unsafe problems to be:
>* no out of bounds check for array index
>* allowing use of deallocated memory
>* memory leak due to memory never being deallocated

That's a decent starter list.  I'd add not indirecting through
uninitialized pointers.  The second two are phrased in terms
usually associated with dynamic memory allocation, but of course
returning a pointer to a stack-allocated variable is a form of
(2).  And there are other problems, like trying to access and/or
rely on the specific values of padding bytes between aligned
data in a struct/record.  Unconstrained pointer arithmetic, as
in C, is a huge area of concern.

I think it's debatable whether one does or should include some
notion of concurrency in one's definition of memory safety, but
it is an important area, so perhaps something about data races
should be included here, as well.

Anyway, my list is something like:

1. Accessing uninitialized data
2. Indirecting an invalid pointer (nil, uninitialized, dangling,
   misaligned, or pointing to an invalid object)
3. Reading from/writing to memory before or after a valid object
   (note: an array is a valid object, so as long as they are
   also in the array, accessing the elements before or after
   some element is ok)
4. Accessing an object after it is no longer in scope (note:
   this includes dynamically scoped objects, such as those that
   are heap allocated: so no use-after free, no double-frees,
   and so on.  But this also applies to lexically and block
   scoped data, so no returning pointers to e.g. stack allocated
   variables, and no assigning pointers to block scoped
   variables and then indirecting them in the outer scope)
5. Invalid accesses inside of a valid object (e.g., misaligned
   accesses, or trying to read padding bits, or partial reads
   spanning multiple fields in some way that is not
   architecturally valid)
6. Writing to read-only data
7. Unsynchronized accesses to read/write data

>Pascal only prevents the first not the other two.
>
>The other two are not as common in Pascal as in C,
>because dynamic memory allocation is not as common in
>Pascal as in C.

Pascal is certainly an improvement over (at least) C and
assembler languages in this domain: as I recall, it doesn't
support arbitrary pointer arithmetic, and arrays are properly
typed by including the array size in the type, and so on.

But there is a lot more in this domain that is very important
when considering overall memory safety that Pascal doesn't
address.

>I did a quick check in my code repo and I use dynamic
>memory allocation in 25% of my C pieces but only in
>0.5% of my Pascal pieces. I am just one out of
>millions so it is obviously anecdotal only, but pretty
>big difference ...
>
>Anyway 1 fixed + 2 not fixed but rare is not really
>fixed.
>
>So I think you are right and the US government is wrong.
>
>:-)

Yeah.  That's about the long and short of it, unfortunately.

>I do not see a problem with the pointer type casts. If
>normal code is safe, then I think it is OK to have ways
>to workaround the safeness. Sometimes it is desirable
>and it is hopefully easy to identify usage of such
>constructs and require extra code review of such code.

You certainly need some kind of escape hatch to write some kinds
of programs.  The issue is whether that's explicitly called out
as "unsafe" at the language level, and in Pascal, it's just not.
Trivially casting a pointer to an array of $n$ elements to an
array of $n+k$ elements (or a record, or something else) without
some indicator that there be dragons there isn't great.

Another issue is whether the language can prevent this
statically (that is, at compile time) or not.  Consider
out-of-bounds array accesses; if I use some arbitrary integer to
index into an array, I am pretty much forced to check that at
runtime.  On the other hand, if the language supports iterators,
then I can more or less guarantee at compile time that those are
valid.

Anyway, it's a big design space in languages, and one must admit
that safety in this dimension exists along some spectrum; from
trivially dangerous (C, assembler) to safe-by-default (Rust, Ada
etc).  Pascal is somewhere in the middle.

	- Dan C.

Back to comp.os.vms | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

VMS Bootcamp Arne Vajhøj <arne@vajhoej.dk> - 2025-11-04 19:36 -0500
  Re: VMS Bootcamp Arne Vajhøj <arne@vajhoej.dk> - 2025-11-04 19:43 -0500
  Re: VMS Bootcamp Arne Vajhøj <arne@vajhoej.dk> - 2025-11-04 19:51 -0500
    Re: VMS Bootcamp "John H. Reinhardt" <johnhreinhardt@thereinhardts.org> - 2025-11-04 19:17 -0600
      Re: VMS Bootcamp Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-05 02:49 +0000
      Re: VMS Bootcamp cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-07 13:22 +0000
        Re: VMS Bootcamp Mark Berryman <mark@theberrymans.com> - 2025-11-07 12:51 -0700
          Re: VMS Bootcamp cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-07 23:50 +0000
    Re: VMS Bootcamp "Robert A. Brooks" <FIRST.LAST@vmssoftware.com> - 2025-11-04 22:10 -0500
      Re: VMS Bootcamp Arne Vajhøj <arne@vajhoej.dk> - 2025-11-04 22:15 -0500
        Re: VMS Bootcamp John Reagan <johnrreagan@earthlink.net> - 2025-11-05 09:36 -0500
          Re: VMS Bootcamp Arne Vajhøj <arne@vajhoej.dk> - 2025-11-05 20:39 -0500
          Re: VMS Bootcamp Arne Vajhøj <arne@vajhoej.dk> - 2025-11-05 20:48 -0500
      Re: VMS Bootcamp Arne Vajhøj <arne@vajhoej.dk> - 2025-11-04 22:35 -0500
  Re: VMS Bootcamp Arne Vajhøj <arne@vajhoej.dk> - 2025-11-06 15:31 -0500
    Re: VMS Bootcamp Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-06 21:25 +0000
      Re: VMS Bootcamp Arne Vajhøj <arne@vajhoej.dk> - 2025-11-06 16:28 -0500
        Re: VMS Bootcamp Chris Townley <news@cct-net.co.uk> - 2025-11-06 23:35 +0000
          Re: VMS Bootcamp Arne Vajhøj <arne@vajhoej.dk> - 2025-11-06 18:58 -0500
            Re: VMS Bootcamp Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-07 01:20 +0000
              Re: VMS Bootcamp Arne Vajhøj <arne@vajhoej.dk> - 2025-11-06 20:34 -0500
                Re: VMS Bootcamp Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-07 03:07 +0000
                Re: VMS Bootcamp Arne Vajhøj <arne@vajhoej.dk> - 2025-11-07 15:01 -0500
                Re: VMS Bootcamp Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-08 21:59 +0000
                Re: VMS Bootcamp Arne Vajhøj <arne@vajhoej.dk> - 2025-11-08 17:14 -0500
                Re: VMS Bootcamp Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-08 23:09 +0000
                Re: VMS Bootcamp Arne Vajhøj <arne@vajhoej.dk> - 2025-11-08 18:36 -0500
                Re: VMS Bootcamp cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-12 13:04 +0000
                Re: VMS Bootcamp Arne Vajhøj <arne@vajhoej.dk> - 2025-11-12 17:14 -0500
                Re: VMS Bootcamp Arne Vajhøj <arne@vajhoej.dk> - 2025-11-12 17:21 -0500
                Re: VMS Bootcamp Arne Vajhøj <arne@vajhoej.dk> - 2025-11-12 17:24 -0500
                Re: VMS Bootcamp Arne Vajhøj <arne@vajhoej.dk> - 2025-11-12 19:14 -0500
                Re: VMS Bootcamp cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-15 15:04 +0000
                Re: VMS Bootcamp Arne Vajhøj <arne@vajhoej.dk> - 2025-11-15 19:00 -0500
                Re: VMS Bootcamp Arne Vajhøj <arne@vajhoej.dk> - 2025-11-15 19:17 -0500
                Re: VMS Bootcamp Arne Vajhøj <arne@vajhoej.dk> - 2025-11-15 20:02 -0500
                Re: VMS Bootcamp Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-11-17 19:52 +0000
                Re: VMS Bootcamp cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-18 13:04 +0000
                Re: VMS Bootcamp cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-18 13:06 +0000
                Re: VMS Bootcamp Dave Froble <davef@tsoft-inc.com> - 2025-11-29 19:09 -0500
                Re: VMS Bootcamp Brian Schenkenberger <mail@SendSpamHere.ORG> - 2025-11-12 18:39 -0500
                Re: VMS Bootcamp Arne Vajhøj <arne@vajhoej.dk> - 2025-11-12 18:49 -0500
                Re: VMS Bootcamp cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-15 15:10 +0000
                Re: VMS Bootcamp Dave Froble <davef@tsoft-inc.com> - 2025-11-29 19:17 -0500
                Re: VMS Bootcamp antispam@fricas.org (Waldek Hebisch) - 2025-11-30 23:00 +0000
                Re: VMS Bootcamp cross@spitfire.i.gajendra.net (Dan Cross) - 2025-12-01 16:08 +0000
            Re: VMS Bootcamp bill <bill.gunshannon@gmail.com> - 2025-11-07 12:39 -0500
              Re: VMS Bootcamp Arne Vajhøj <arne@vajhoej.dk> - 2025-11-07 14:54 -0500
              Re: VMS Bootcamp cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-07 21:46 +0000
                Re: VMS Bootcamp Chris Townley <news@cct-net.co.uk> - 2025-11-07 23:47 +0000
              Re: VMS Bootcamp John Reagan <johnrreagan@earthlink.net> - 2025-11-07 16:58 -0500

csiph-web