Path: ...!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Chris M. Thomasson" Newsgroups: comp.lang.c Subject: Re: realloc() - frequency, conditions, or experiences about relocation? Date: Mon, 24 Jun 2024 12:33:04 -0700 Organization: A noiseless patient Spider Lines: 22 Message-ID: References: <875xtyu0kk.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Mon, 24 Jun 2024 21:33:05 +0200 (CEST) Injection-Info: dont-email.me; posting-host="07ac9ec5e7d723e4c5066c38c1039c91"; logging-data="1146765"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18RYIImGyv2x12v2IYylz7NL8HJ0Y5EcWM=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:qejaI908dipFR6OQrZdZ6CntHvI= In-Reply-To: Content-Language: en-US Bytes: 2227 On 6/24/2024 4:40 AM, David Brown wrote: > On 24/06/2024 11:55, Keith Thompson wrote: > >> Something else that occurs to me: If a shrinking realloc() never fails >> in practice, then any code you write to handle a failure won't be >> tested. >> > > That is always a problem with allocation functions.  Have you ever known > a non-pathological malloc() to fail? > > I think, in fact, there's a good argument for ignoring the possibility > of malloc (and calloc and realloc) failures for most PC code.  There is > virtually no chance of failure in reality, and if you get one, there is > almost never a sensible way to deal with it - [...] I have had to deal and roll with malloc failures. It put the server in panic mode and it started killing connections that were already timed out, dumping some caches (freelists of regions, ect), ect... There is a way to recover.