Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks"

On Fri, 8 Mar 2024 15:32:22 +0100
David Brown <david.brown@hesbynett.no> wrote:

On 08/03/2024 11:57, Michael S wrote:

On Fri, 8 Mar 2024 08:25:13 +0100
David Brown <david.brown@hesbynett.no> wrote:
 

On 07/03/2024 17:35, Kaz Kylheku wrote: 

On 2024-03-07, David Brown <david.brown@hesbynett.no> wrote: 

On 06/03/2024 23:00, Michael S wrote: 

On Wed, 6 Mar 2024 12:28:59 +0000
bart <bc@freeuk.com> wrote:
   

>
"Rust uses a relatively unique memory management approach that
incorporates the idea of memory “ownership”. Basically, Rust
keeps track of who can read and write to memory. It knows when
the program is using memory and immediately frees the memory
once it is no longer needed. It enforces memory rules at
compile time, making it virtually impossible to have runtime
memory bugs.⁴ You do not need to manually keep track of
memory. The compiler takes care of it."
>
This suggests the language automatically takes care of this. 

>
Takes care of what?
AFAIK, heap fragmentation is as bad problem in Rust as it is in
C/Pascal/Ada etc... In this aspect Rust is clearly inferior to
GC-based languages like Java, C# or Go.
   

Garbage collection does not stop heap fragmentation.  GC does, I
suppose, mean that you need much more memory and bigger heaps in
proportion to the amount of memory you actually need in the
program at any given time, and having larger heaps reduces
fragmentation (or at least reduces the consequences of it). 

>
Copying garbage collectors literally stop fragmentation. 

>
Yes, but garbage collectors that could be useable for C, C++, or
other efficient compiled languages are not "copying" garbage
collectors.
 

 Go, C# and Java are all efficient compiled languages. For Go it was
actually a major goal. 

 C# and Java are, AFAIUI, managed languages - they are byte-compiled
and run on a VM.  (JIT compilation to machine code can be used for acceleration, but that does not change the principles.)  I don't know about Go.
>

C# was Jitted originally and was even interpretted on on very small
implementation that don't seem to be supported any longer. Today it is
mostly AoTed, which in simpler language means "compiled". There are
options in dev tools whhether to compile to native code on to
platform-independent. I would think that most people compile to native.
Java-on-Android which, I would guess, is majority on Java written in
the world, is like 95% AoTed + 5% JITtted. Is used to be 100% AoTed in
few versions of Android, but by now JIT is reintroduced as an option,
not for portability, but for profile-guided optimization
opportinities it allows. If I am not mistaken, direct interpretaions of
Davlik non-byte-code was never supported on Android.
Java-outside-Android? I don't know what is current stated. Would think
that Oracle's JVMs intetended for desktop/la[top/server are also
either JITted or AoTed, not interpreted.
Go is compiled to native, most often via LLVM, but there exists gcc
option as well.