Re: The Case for Rust (in any system)

On Fri, Sep 13, 2024 at 3:01 PM Paul Floyd <paulf2718@gmail.com> wrote:
>
>
>
> On 13-09-24 12:24, Aryeh Friedman wrote:
> > On Fri, Sep 13, 2024 at 7:59 AM Paul Floyd <paulf2718@gmail.com> wrote:
>
> >
> > Incorrect a pointer by definition points to a memory region of
>
> It's really difficult to follow what you are banging on about. One
> moment it's allocators and the next it's pointers.

Again wrong all a pointer is at the end of the day is a memory address
anything to do with that memory access's contents and/or addresses
near it not what a pointer is.   In other words arr+i == arr[i] iff
and only iff your type is one processor word big.   In all other cases
you just have to trust your math is right if your don't it with ptr
math instead of array notation.   But since neither is bounds checked
then you are completely free to address stuff beyond your allocation
unless.   All this adds up to ptr!=arrays but array indexing==ptrs.
In other words malloc, calloc, etc. make no guerntee that the memory
is actually reserved for your exclusive use only that it marked that
way at run time.

>
> > *UNKNOWN* size and it is only the runtime environment that keeps track
>
> I'm well aware of that.
>
> > Malloc is not the *ONLY* way to allocate memory at the system level an
>
> You could also implement your own custom allocator based on mmap.

There are many other ways that are much cleaner than the above if
you're dealing with system level stuff...  I am amazed you would point
to mmap as a solution and recommend kernel Rust use at the same time
because if that is how Rust does it (which I assume it does) then you
are relying on kernel calls to do that (which might be accessible at
below the kernel interface).

>
> > Go read CLRS it is a very clear and obvious algorthm the only thing
>
> You mean this bit
>
> "10.3 Implementing pointers and objects
> How do we implement pointers and objects in languages that do not
> provide them?"

Your being purposely dense here if we are talking about
growing/shrinking arrays there is an entire section on how  to analyze
that since it is a classic case of you have on O(1) function [index
lookup] and the other growing it (O(n)) then how to amortize the big-O
over time.   How you got I was talking about anything is complete
beyond me.


>
> What is the point. We are discussing languages (C, C++ and Rust) that DO
> have them.
>
> > 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.
>
> Space cadet?

Again you missed the point the point being that a simple memory
management function that you claim Rust does real well at (async
behind the scenes array size management) if called at the "right" time
(like when attempting the final descent to the moon [btw in the
real-life case the mission was saved by Armstrong taking manually
control]) it can to catastrophic results such as the very computer you
need to safely and softly land on the moon becoming non-responsive.
This is a *COMPLETELY* unacceptable result in any mission-critical (or
higher application... for example if it happened on one of the remote
cardiac monitors we use at just the right time we can miss you having
a heart attack... i.e. for us bugs [of any kind]==dead people).
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org