Path: csiph.com!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Michael S Newsgroups: comp.lang.c++,comp.lang.c Subject: Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks" Date: Thu, 7 Mar 2024 13:44:01 +0200 Organization: A noiseless patient Spider Lines: 51 Message-ID: <20240307134401.00007aa2@yahoo.com> References: <20240305005948.00002697@yahoo.com> <20240305111103.00003081@yahoo.com> <20240306140214.0000449c@yahoo.com> <20240307000008.00003544@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Injection-Info: dont-email.me; posting-host="efb7d41ba468e3312d50ab92a630b576"; logging-data="1078572"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1911ebFpcrMpdIW8KYPScK/HIsEmlmKG8Q=" Cancel-Lock: sha1:UPoWtCtq2p1WZYx2jwxlc2rOX+Y= X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32) Xref: csiph.com comp.lang.c++:118477 comp.lang.c:383447 On Thu, 7 Mar 2024 11:35:08 +0100 David Brown wrote: > On 06/03/2024 23:00, Michael S wrote: > > On Wed, 6 Mar 2024 12:28:59 +0000 > > bart wrote: > > =20 > >> > >> "Rust uses a relatively unique memory management approach that > >> incorporates the idea of memory =E2=80=9Cownership=E2=80=9D. 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.=E2=81=B4 Y= ou > >> do not need to manually keep track of memory. The compiler takes > >> care of it." > >> > >> This suggests the language automatically takes care of this. =20 > >=20 > > 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. > > =20 > Garbage collection does not stop heap fragmentation. GC does, I=20 > suppose, mean that you need much more memory and bigger heaps in=20 > 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). >=20 GC does not stop fragmentation, but it allow heap compaction to be built-in part of environment. So, it turns heap fragmentation from denial of service type of problem to mere slowdown, hopefully insignificant slowdown. I don't say that heap compaction is impossible in other environments, but it is much harder, esp. in environments where pointers are visible to programmer. The famous David Wheeler's quote applies here at full force.=20 Also when non-GC environments chooses to implement heap compaction they suffer the same or bigger impact to real-time responsiveness as GC. So, although I don't know it for sure, my impression is that generic heap compaction extremely rarely implemented in performance-aware non-GC environments.=20 Performance-neglecting non-GC environments, first and foremost CPython, can, of course, have heap compaction, although my googling didn't give me a definite answer whether it's done or not.