Re: The Case for Rust (in any system)

On Fri, Sep 13, 2024 at 7:59 AM Paul Floyd <paulf2718@gmail.com> wrote:
>
>
>
> On 13-09-24 11:40, Aryeh Friedman wrote:
>
> >
> > 1. Fixed allocations are *ALWAYS* safer and more predictable then
> > dynamic ones (dynamic ones are undecidable in there nature and
> > effects).
> >
> > 2. Combining fixed allocation with dynamic (under the hood and
> > unrequested) allocation is a very bad idea.
> >
> > 3. It is possible to do all the above safely with arrays and not
> > pointers IF the arrays are static but not dynamic.
> >
> > This implies that if and when you grow/shrink the physical array you
> > need to have really tight control on timing and Rust does not provide
> > that by putting it all under the hood.
>
> You aren't being very clear with your vocabulary. In C there are 4 main
> kinds of storage.
>
> Global, static and automatic. These are all of constant fixed size
> (except for automatic which can use VLAs since C99 which is of variable
> fixed size).

Incorrect a pointer by definition points to a memory region of
*UNKNOWN* size and it is only the runtime environment that keeps track
of how large it is.   I doesn't matter if I allocated globally,
statically or automatically (or what scope I declared it or if its on
the stack or the heap) it is still a pointer to a specific piece of
memory and the runtime language environment (all languages including
machine have a runtime environment that might not be the same as the
machines runtime environment [what I means they can operate without
software/firmware hooks that are not pure hardware]).    In other
words an array is an array and a pointer is a pointer period and the
only place they intersect if that an array+index is the base addr of
the array+offset.    This means that it is the responibility of the
caller (at the machine level) to ensure enough memory is reserved for
the array.   If we need to grow the array at some later point and
memory is fragmented we will have to create a new allocation and copy
the old array values into it.    This is O(n) at best and thus not an
atomic operation.


> Dynamic, as managed by malloc and family. Can be constant sized or
> variable sized.

Malloc is not the *ONLY* way to allocate memory at the system level an
other way (which I use in my research) is for each function/module to
live in it's own VM and at the beginning of it's existence allocate
internal RAM to it self from a slice of RAM given to it by the caller.
   In this case you can use nothing but array notation and still have
all the power of pointers (except for their I/O capabilities of
addressing fixed/known memory addressed for I/O buffers).

>
> Which of these is your array that can grow or shrink?

Go read CLRS it is a very clear and obvious algorthm the only thing
you have to be careful of is it is not O(1) so you need to time it
carefully when I do the expanson/contraction instead of just letting
the runtime environment do it for you.    An extreme case of this
going very wrong happened in July 1969 here is the transcript:

4 06 42 10 CC
Eagle, Houston. You're GO for landing. Over.

04 06 42 17 LMP (EAGLE)
Roger. Understand. GO for landing. 3000 feet. PROGRAM ALARM.

04 06 42 19 CC
Copy.

04 06 42 22 LMP (EAGLE)
1201

04 06 42 24 CDR (EAGLE)
1201.

04 06 42 25 CC
Roger. 1201 alarm. We're GO. Same type. We're GO.