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

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.

Reachable
objects are identified and moved to a memory partition where they
are now adjacent. The vacated memory partition is then efficiently
used to bump-allocate new objects.
 

 I think if you have a system with enough memory that copying garbage collection (or other kinds of heap compaction during GC) is a
reasonable option, then it's unlikely that heap fragmentation is a
big problem in the first place.  And you won't be running on a small
embedded system.
>

You sound like arguing for sake of arguing.
Of course, heap fragmentation is relatively rare problem. But when you
process 100s of 1000s of requests of significantly varying sizes for
weeks without interruption then rare things happen with high
probability :(
In case of this particular Discord service, they appear to
have a benefit of size of requests not varying significantly, so
absence of heap compaction is not a major defect.
BTW, I'd like to know if 3 years later they still have their Rust
solution running.