Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: David Brown 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 15:32:22 +0100 Organization: A noiseless patient Spider Lines: 103 Message-ID: References: <20240305005948.00002697@yahoo.com> <20240305111103.00003081@yahoo.com> <20240306140214.0000449c@yahoo.com> <20240307000008.00003544@yahoo.com> <20240307083119.850@kylheku.com> <20240308125746.000074c1@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 8 Mar 2024 14:32:23 -0000 (UTC) Injection-Info: dont-email.me; posting-host="5b4fd483861029d4eca5978ecaa265e3"; logging-data="1842669"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/MEImCX21lSO3vdAwUZY17YYg1QbxPHwk=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Cancel-Lock: sha1:XYaOS2UqhrIYTD5v4bG1+4PdM4w= In-Reply-To: <20240308125746.000074c1@yahoo.com> Content-Language: en-GB Bytes: 6345 On 08/03/2024 11:57, Michael S wrote: > On Fri, 8 Mar 2024 08:25:13 +0100 > David Brown wrote: > >> On 07/03/2024 17:35, Kaz Kylheku wrote: >>> On 2024-03-07, David Brown wrote: >>>> On 06/03/2024 23:00, Michael S wrote: >>>>> On Wed, 6 Mar 2024 12:28:59 +0000 >>>>> bart 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. > >>> 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. I am just trying to be clear about things. Different types of system, and different types of task, have different challenges and different solutions. (This seems obvious, but people often think they have "the" solution to a particular issue.) In particular, in small embedded systems with limited ram and no MMU, if you use dynamic memory of any kind, then heap fragmentation is a serious risk. And a heap-compacting garbage collection will not mitigate that risk. There are a lot of GC algorithms, each with their pros and cons, and the kind of languages and tasks for which they are suitable. If you have a GC algorithm that works by copying all live data (then scraping everything left over), then heap compaction is a natural byproduct. But I think it is rare that heap compaction is an appropriate goal in itself - it is a costly operation. It invalidates all pointers, which means a lot of overhead and extra care in languages where pointers are likely to be cached in registers or local variables on the stack. And it will be tough on the cache as everything has to be copied and moved. That pretty much rules it out for efficient compiled languages, at least for the majority of their objects, and leaves it in the domain of languages that can accept the performance hit. > 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 :( There are all sorts of techniques usable to optimise such systems. Allocation pools for different sized blocks would be a typical strategy. > 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. >