Path: ...!feed.opticnetworks.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
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: <v5bluo$thpd$1@dont-email.me>
References: <v4ojs8$gvji$1@dont-email.me>
 <v4ov8h$j2q2$1@raubtier-asyl.eternal-september.org>
 <v52270$2nli8$1@dont-email.me>
 <v54jac$3a4p2$1@raubtier-asyl.eternal-september.org>
 <v5bbd3$rhao$2@dont-email.me> <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.