Re: realloc() - frequency, conditions, or experiences about relocation?

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