Path: ...!feed.opticnetworks.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: David Brown Newsgroups: comp.lang.c Subject: Re: realloc() - frequency, conditions, or experiences about relocation? Date: Mon, 24 Jun 2024 13:40:08 +0200 Organization: A noiseless patient Spider Lines: 30 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 13:40:09 +0200 (CEST) Injection-Info: dont-email.me; posting-host="995058d498c537c0d70be20402ad0eb4"; logging-data="968493"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+vTdYnJ4a/UTgiDHwegd1+OB9Q1HxpoEs=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Cancel-Lock: sha1:d+uPCGrsgBgoLO0rWd0mEcnpMzM= In-Reply-To: <875xtyu0kk.fsf@nosuchdomain.example.com> Content-Language: en-GB Bytes: 2728 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 - you just kick the can down the road by having functions return NULL until something gives up and stops the program with an error message. You might as well just let the OS kill the program when you try to access memory at address 0. I've seen more than enough error handling code that has never been tested in practice - including error handling code with bugs that lead to far worse problems than just killing the program. Of course such treatment is not appropriate for all allocations (or other functions that could fail). But often I think it is better to write clearer and fully testable (and tested!) code which ignores hypothetical errors, rather than some of the untestable and untested jumbles that are sometimes seen in an attempt to "handle" allocation failures.