Path: ...!feeds.phibee-telecom.net!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Malcolm McLean <malcolm.arthur.mclean@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: realloc() - frequency, conditions, or experiences about
 relocation?
Date: Mon, 24 Jun 2024 18:50:15 +0100
Organization: A noiseless patient Spider
Lines: 41
Message-ID: <v5cbkn$11tla$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>
 <v5bluo$thpd$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 24 Jun 2024 19:50:15 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="67c61ba4668adca48db563acd23b2103";
	logging-data="1111722"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+09IPjt+VHZtekyZZ1Fus71A9Ix6ZNnIw="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:VAjh861MBRUzowLqYMroFSRZ+Kg=
Content-Language: en-GB
In-Reply-To: <v5bluo$thpd$1@dont-email.me>
Bytes: 3128

On 24/06/2024 12:40, 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 - 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.
> 
> 
Baby X has bbx_malloc() which is guaranteed never to return NULL, and 
never to return a pointer to an allocation which cannot be indexed by an 
int.

I use a "goto out_of_memory" in regular code, however.

-- 
Check out my hobby project.
http://malcolmmclean.github.io/babyxrc