Accessing a pointer after it has been freed

As part of codeform, I have a dynamically allocated array of pointers. Some of the pointers point to the same location in memory; but if they do, they will be consecutive. So when I go to free the array, I use

Code:

---

for(x = 0; x < size; x ++) {
    if(!x || array[x] == array[x-1]) free(array[x]);
}

free(array);

---

However, I have been reading a C book*, and it seems to indicate that you can't do anything with "invalid pointers" (which can be formed by freeing the memory that a pointer pointed to), including compare them with anything else. This seems silly to me; I'm not dereferencing the pointer or anything. But still, I'm wondering if the above code is valid or not. If it isn't, that won't matter, for I could set duplicate pointers to NULL beforehand:

Code:

---

if(size) for(x = 0; x < size-1; x ++) {
    if(array[x] == array[x+1]) array[x] = 0;
}

for(x = 0; x < size; x ++) {
    free(array[x]);
}

---

* C: A reference manual, fifth editon, page 139.

You'll need to be sure you set them to NULL if you're freeing them. You really aren't supposed to do anything to a pointer which is invalid, other than assign it something valid (or NULL). Anything other than that is a potentially BadThing(TM). So really you can do something with an invalid pointer, in that you can reassign it a new value.


Quzah.

Quote:

---

Originally Posted by dwks

However, I have been reading a C book*, and it seems to indicate that you can't do anything with "invalid pointers" (which can be formed by freeing the memory that a pointer pointed to), including compare them with anything else.

---

That is correct in a pedantic kind of C standard way.

This code does trigger undefined behaviour according to the standard.

Code:

---


char *p; /* not initialized */
char *q = malloc(10);

if (p>q) {... }

---

This is UB because the value in the uninitialized pointer might trigger a trap on some systems. The thing is there are currently no known systems where this actually does go wrong. So it's kinda silly to say its bad code

free() does not change the value of the pointer, as far as the caller is concerned. So, AFAIK, the comparison is valid (even if not a particularly good idea). Dereferencing the pointers after the call to free() would yield undefined behaviour.

There is also the problem that the code

Code:

---

for(x = 0; x < size; x ++) {
    if(!x || array[x] == array[x-1]) free(array[x]);
}

---

would free some pointers twice if three or more consecutive elements of array contain the same value. And that is undefined behaviour.

Quote:

---

Originally Posted by grumpy

free() does not change the value of the pointer, as far as the caller is concerned. So, AFAIK, the comparison is valid (even if not a particularly good idea). Dereferencing the pointers after the call to free() would yield undefined behaviour.

There is also the problem that the code

Code:

---

for(x = 0; x < size; x ++) {
    if(!x || array[x] == array[x-1]) free(array[x]);
}

---

would free some pointers twice if three or more consecutive elements of array contain the same value. And that is undefined behaviour.

---

dereferencing is clearly UB, but even comparing the value of a pointer that is freed or uninitialized is UB.

There's also another bug in the code for when x equals zero.

Quote:

---

Originally Posted by Laserve

dereferencing is clearly UB, but even comparing the value of a pointer that is freed or uninitialized is UB.

---

As I said, I'm not 100% sure on that. Comparing uninitialised pointers, I agree, yields UB (simply fetching the value of any uninitialised variable does that, let alone comparing it). But I failed to find anything in the C standard which supports the conclusion that the comparison in this;

Code:

---

    /*  assume x is a pointer, and it's value was returned by malloc()/calloc()/realloc() */
    free(x);
    if (x > some_pointer_value)
      do_whatever();

---

yields UB. Would you provide a reference into the standard please?

Just rewrite the loop as this and stop worrying about the problem ;)

Code:

---

for(x = 0; x < size; x ++) {
    if(x == (size - 1) || array[x] != array[x+1]) free(array[x]);
}

---

This way, you only free the last pointer of each sequence.

Quote:

---

free() does not change the value of the pointer, as far as the caller is concerned. So, AFAIK, the comparison is valid (even if not a particularly good idea). Dereferencing the pointers after the call to free() would yield undefined behaviour.

---

That's what I thought, too; but it seemed to indicate otherwise.

Quote:

---

There is also the problem that the code

Code:

---

for(x = 0; x < size; x ++) {
    if(!x || array[x] == array[x-1]) free(array[x]);
}

---

would free some pointers twice if three or more consecutive elements of array contain the same value. And that is undefined behaviour.

---

Yes, I copied it from memory, obviously incorrectly.

Quote:

---

Code:

---

char *p; /* not initialized */
char *q = malloc(10);

if (p>q) {... }

---

This is UB because the value in the uninitialized pointer might trigger a trap on some systems. The thing is there are currently no known systems where this actually does go wrong. So it's kinda silly to say its bad code

---

My code wasn't like that, because the variable did have a value. It was more like this:

Code:

---

char *p = malloc(10), *q;

if(something) q = p;
else q = malloc(10);

free(p);
if(p != q) free(q);

---

Quote:

---

Just rewrite the loop as this and stop worrying about the problem ;)

---

Okay, good idea. :) I was just curious.

Quote:

---

Originally Posted by grumpy

As I said, I'm not 100% sure on that. Comparing uninitialised pointers, I agree, yields UB (simply fetching the value of any uninitialised variable does that, let alone comparing it). But I failed to find anything in the C standard which supports the conclusion that the comparison in this;

Code:

---

    /*  assume x is a pointer, and it's value was returned by malloc()/calloc()/realloc() */
    free(x);
    if (x > some_pointer_value)
      do_whatever();

---

yields UB. Would you provide a reference into the standard please?

---

yeah it might be guaranteed to work since if the pointer contains a valid value before the free it will still contain a valid value after the free. I was only thinking about the uninitialised variable case. I'll try and find this I I remember when I get home

Quote:

---

Originally Posted by grumpy

But I failed to find anything in the C standard which supports the conclusion that the comparison in this;

Code:

---

    /*  assume x is a pointer, and it's value was returned by malloc()/calloc()/realloc() */
    free(x);
    if (x > some_pointer_value)
      do_whatever();

---

yields UB. Would you provide a reference into the standard please?

---

Not in the way you expected, but look at 6.5.8.5, which defines the semantics of relational operations on pointers. Its says:

Quote:

---

If two pointers [...] both point to the same object, or both point one past the last element of the same array object, they compare equal. If the objects pointed to are members of the same aggregate object, pointers to structure members declared later compare greater than pointers to members declared earlier in the structure, and pointers to array elements with larger subscript values compare greater than pointers to elements of the same array with lower subscript values. All pointers to members of the same union object compare equal. If the expression P points to an element of an array object and the expression Q points to the last element of the same array object, the pointer expression Q+1 compares greater than P. In all other cases, the behavior is undefined.

---

Emphasis mine. What all this blather says is that relational operations on arbitrary pointers are undefined except in some special cases. Since after calling free() there is nothing special where x points to, all comparisons of x are undefined behaviour. Of course, it would take an implementation that actively enforces this constraint to actually do anything but the obvious.
Also interesting in this is that relational operations are invalid and should not compile for void pointers. I don't think any compiler actually conforms to this.
The situation is slightly different with equality, but not much. Two differences:
1) void pointers are allowed.
2) Comparison with the null pointer is defined.
Other than that, 6.5.9.6 gives the semantics, and it, too, requires that the pointer point to an actual object or be the null pointer. Which is not the case for a free()'d pointer.

Quote:

---

Originally Posted by CornedBee

Other than that, 6.5.9.6 gives the semantics, and it, too, requires that the pointer point to an actual object or be the null pointer. Which is not the case for a free()'d pointer.

---

yeah think this is the thnigie I had in mind. it's strictly UB but no implementation is known that would show "strange" behaviour like crashes or reformats of drives or something

Quote:

---

Originally Posted by dwks

As part of codeform, I have a dynamically allocated array of pointers. Some of the pointers point to the same location in memory; but if they do, they will be consecutive. So when I go to free the array, I use <snip>

---

dwks: Why not create a second array equal to the first, set all the values to NULL, then add in each pointer IFF it is not in the list already. Then, all you'd have to do is to loop that one list, free anything that isn't NULL, then free both arrays. That would rid yourself of the issues of the UB in the *unlikely* event that a free to the pointer cause you to loose the original value of the variable (which it shouldn't ever do).

>This seems silly to me
It makes perfect sense to me. Once you've freed the memory that a pointer points to, you can no longer guarantee any of the requirements for comparison.

Quote:

---

Originally Posted by Kennedy

dwks: Why not create a second array equal to the first, set all the values to NULL, then add in each pointer IFF it is not in the list already. Then, all you'd have to do is to loop that one list, free anything that isn't NULL, then free both arrays. That would rid yourself of the issues of the UB in the *unlikely* event that a free to the pointer cause you to loose the original value of the variable (which it shouldn't ever do).

---

Because that solution is extremely complex, when a simple restructuring of the loop (as I have shown) avoids all problems?

I've re-written the loop (actually, I did so before there were any replys to this thread, because I thought that's what the answer would be).

I asked on comp.lang.c and this is a good example when your program could crash on using a freed pointer. its a non existing platform but its still UB


Consider a platform that has separate data and address registers. Also
consider that this platform has virtual memory, and that free() unmaps
the passed-in pointer from the address space. The mere act of loading
the p1 pointer into a register in order to compare it to another
platform could cause a bus error, crash the program, etc.

Quote:

---

Originally Posted by CornedBee

Not in the way you expected, but look at 6.5.8.5, which defines the semantics of relational operations on pointers.

---

Ta, CornedBee. It made sense to me that comparing a free'd pointer with something wouldn't be defined. I read that section, but my mind must have drifted; one of the hazards of reading a standard, I guess.

It would be a slightly interesting exercise to see if we can find a real compiler/library that, when it encounters this code...

Code:

---

#include <stdio.h>
#include <stdlib.h>

int main()
{
    int *a, *b, *temp;
    temp = malloc(2*sizeof(int));
    a = temp;
    b = temp + 1;
    free(temp);
    if (b > a) fprintf(stdout, "Yes!");  /* undefined behaviour here */
    return 0;
}

---

does anything other than print "Yes!".