Re: Joy of this, Joy of that

The Natural Philosopher <tnp@invalid.invalid> writes:

On 27/11/2024 01:48, Rich wrote:

The only two guarantees given in that paragraph are:
1) if ptr was returned by one of the malloc's, the space referenced
by
    ptr is deallocated (albeit only for the first call of free(ptr), per
    the second sentence);
and
2) if ptr is NULL, nothing occurs.

>
Exactly.  The result of anything else is implementation dependent on
the library.
>
One might write a free that says 'look at our list of allocated
blocks, compare with the pointer and if no match do nothing'
>
Or one that says  'look at our list of allocated block compare with
the pointer and if no match, segfault'
>
I am not au fait with the internal of 'free()' so I cannot comment as
to why the first is not always the case.

You can absolutely write an allocator that does that if you want. You’ll
pay for it in performance and memory usage, but it might well be
worthwhile in a given application.

However, it doesn’t fully solve the problem. Suppose the sequence of
operations (with lots going on between) happens to look like this:

   int *p = malloc(xxx);
   // ...
   free(p);
   // ...
   int *q = malloc(yyy);
   // ...
   free(p);             // double free of p
   // ...
   *q = 1;

If p!=q then a tracking allocator like you envisage would spot the
error. But if it happens that p=q (which is entirely possible) then the
tracking allocator won’t notice the problem. The program will start to
misbehave seriously when the it access the (now freed) memory pointed to
be q.

Nulling out pointers after freeing them, as suggested elsewhere helps,
but that depends on perfect play by human programmers, not something you
want to rely on.


To go further you need to track not just the status of each allocation
but the provenance of the pointers to. valgrind does that (and a lot
more) but the performance penalty means it’s only practical to use for
testing and debugging.

--
https://www.greenend.org.uk/rjk/