Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Re: "White House to Developers: Using C or C++ Invites
 Cybersecurity Risks"
Date: Fri, 8 Mar 2024 12:57:46 +0200
Organization: A noiseless patient Spider
Lines: 68
Message-ID: <20240308125746.000074c1@yahoo.com>
References: <us0brl$246bf$1@dont-email.me>
	<us1lb5$2f4n4$1@dont-email.me>
	<us2lfh$2ltj3$5@dont-email.me>
	<us2s96$2n6h3$6@dont-email.me>
	<us3155$2of1i$3@dont-email.me>
	<us4c66$346tp$3@dont-email.me>
	<us5d6f$3besu$3@dont-email.me>
	<20240305005948.00002697@yahoo.com>
	<us5u16$3eidj$2@dont-email.me>
	<20240305111103.00003081@yahoo.com>
	<us8821$90p$4@dont-email.me>
	<20240306140214.0000449c@yahoo.com>
	<us9nib$dski$1@dont-email.me>
	<20240307000008.00003544@yahoo.com>
	<usc58s$10cls$1@dont-email.me>
	<20240307083119.850@kylheku.com>
	<useegp$1ihfv$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Injection-Info: dont-email.me; posting-host="ba4dddafc7a27447368298c876b745c8";
	logging-data="1735418"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19eGK7bHLlu8ckq96eCCA3r/3DWvvpP59Y="
Cancel-Lock: sha1:oUkuVWXEQEVoxA+cdb9PrMyd+Q4=
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
Bytes: 4464

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: =20
> >> On 06/03/2024 23:00, Michael S wrote: =20
> >>> On Wed, 6 Mar 2024 12:28:59 +0000
> >>> bart <bc@freeuk.com> wrote:
> >>> =20
> >>>>
> >>>> "Rust uses a relatively unique memory management approach that
> >>>> incorporates the idea of memory =E2=80=9Cownership=E2=80=9D. Basical=
ly, 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 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. =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
> >> 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). =20
> >=20
> > Copying garbage collectors literally stop fragmentation. =20
>=20
> 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.
> >  =20
>=20
> I think if you have a system with enough memory that copying garbage=20
> 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.