Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!raubtier-asyl.eternal-september.org!.POSTED!not-for-mail From: Bonita Montero Newsgroups: comp.lang.c Subject: Re: realloc() - frequency, conditions, or experiences about relocation? Date: Mon, 24 Jun 2024 16:19:22 +0200 Organization: A noiseless patient Spider Lines: 13 Message-ID: References: <875xtyu0kk.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Mon, 24 Jun 2024 16:19:21 +0200 (CEST) Injection-Info: raubtier-asyl.eternal-september.org; posting-host="25e5eda89458a83976f4ab5b7ad682c9"; logging-data="1030772"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+gD9gxR94oXCGW953VxdIbwHzN3ws2qHk=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:C6XiqpudUSLWcBIFSCK6jB+mzz8= Content-Language: de-DE In-Reply-To: <875xtyu0kk.fsf@nosuchdomain.example.com> Bytes: 2014 Am 24.06.2024 um 11:55 schrieb Keith Thompson: > It's not safe to assume that a shrinking realloc call will never fail. > It's possible that it will never fail in any existing implementation, > but the standard makes no such guarantee. With modern memory allocators a shrink can easily fail if the shrunken block falls into a different size class and there's no memory for a block in this class. mimalloc, jemalloc and TCMalloc round up the size to the next power of two up to 8kB. If yoz have a 8kB-class block and it shrinks below 4kB and there's no page (6kB for all mentioned allocators) for this class and no additional pool can be allocated the shrink fails.