Is fetching the value of an invalid pointer undefined or implementation defined behaviour in C?

Question

Fetching the value of an invalid pointer is an implementation defined behavior in C++ according to this. Now consider the following C program:

#include <stdio.h>
#include <stdlib.h>
int main(void)
{
    int* p=(int*)malloc(sizeof(int));
    *p=3;
    printf("%d\n",*p);
    printf("%p\n",(void*)p);
    free(p);
    printf("%p\n",(void*)p); // Is this undefined or implementation defined in behaviour C? 
}

But is the behaviour same in C also? Is the behaviour of the above C program undefined or implementation defined? What does the C99/C11 standard say about this? Please tell me if the behaviour is different in C99 & C11.

Answer 1

Expanding on Andrew Henle's answer:

From the C99 Standard, 6.2.4:

An object has a storage duration that determines its lifetime. There are three storage durations: static, automatic, and allocated. Allocated storage is described in 7.20.3. […] The value of a pointer becomes indeterminate when the object it points to (or just past) reaches the end of its lifetime.

Then in 7.20.3.2: the standard goes on describing malloc(), calloc() and free(), mentioning that

The free function causes the space pointed to by ptr to be deallocated.

In 3.17.2:

indeterminate value

either an unspecified value or a trap representation

In 6.2.6.1.5:

Certain object representations need not represent a value of the object type. If the stored value of an object has such a representation and is read by an lvalue expression that does not have character type, the behavior is undefined. […] Such a representation is called a trap representation.

Since the pointer becomes indeterminate, and an indeterminate value can be a trap representation, and you have a variable which is an lvalue, and reading an lvalue trap representation is undefined, therefore yes, the behavior may be undefined.

Answer 2

Per the C standard, section 6.2.4:

The lifetime of an object is the portion of program execution during which storage is guaranteed to be reserved for it. An object exists, has a constant address, and retains its last-stored value throughout its lifetime. If an object is referred to outside of its lifetime, the behavior is undefined. The value of a pointer becomes indeterminate when the object it points to (or just past) reaches the end of its lifetime.

Answer 3

If a compiler correctly determines that code will inevitably fetch a pointer to an object which has been passed to "free" or "realloc", even if code will not make any use of the object identified thereby, the Standard will impose no requirements on what the compiler may or may not do after that point.

Thus, using a construct like:

char *thing = malloc(1000);
int new_size = getData(thing, ...whatever); // Returns needed size
char *new_thing = realloc(thing, new_size);
if (!new_thing)
  critical_error("Shrinking allocation failed!");
if (new_thing != thing)
  adjust_pointers(thing, new_thing);
thing = new_thing;

might on most implementations allow code to save the effort of recalculating some pointers in the event that using realloc to shrink an allocated block doesn't cause the block to move, but there would be nothing illegitimate about an implementation that unconditionally reported that the shrinking allocation failed since if it didn't fail code would inevitably attempt a comparison involving a pointer to a realloc'ed block. For that matter, it would also be just as legitimate (though less "efficient") for an implementation to keep the check whether realloc returned null, but allow arbitrary code to execute if it doesn't.

Personally, I see very little to be gained by preventing programmers from determining testing when certain steps can be skipped. Skipping unnecessary code if a pointer doesn't change may yield significant efficiency improvements in cases where realloc is used to shrink a memory block (such an action is allowed to move the block but on most implementations it usually won't), but it is currently fashionable for compilers to apply their own aggressive optimizations which will break code that tries to use such techniques.

Answer 4

Continuing from the comments. I think the confusion over whether it is valid or invalid surrounds what aspect of the pointer is being asked about. Above, free(p); effects the starting address to the block of memory pointed to by p, it does not effect the address of p itself, which remains valid. There is no longer an address held by p (as it's value) leaving it indeterminate until reassigned. A short example helps:

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

int main (void) {

    int *p = NULL;

    printf ("\n the address of 'p' (&p) : %p\n", &p);

    p = malloc (sizeof *p);
    if (!p) return 1;

    *p = 3;

    printf (" the address of 'p' (&p) : %p   p points to %p   with value  %d\n",
            &p, p, *p);

    free (p);

    /* 'address of p' unchanged, p itself indeterminate until reassigned */
    printf (" the address of 'p' (&p) : %p\n\n", &p);

    p = NULL;  /* p no longer indeterminate and can be allocated again */

    return 0;
}

Output

$ ./bin/pointer_addr

 the address of 'p' (&p) : 0x7fff79e2e8a0
 the address of 'p' (&p) : 0x7fff79e2e8a0   p points to 0x12be010   with value  3
 the address of 'p' (&p) : 0x7fff79e2e8a0

The address of p itself is unchanged by either the malloc or free. What is effected is the value of p (or more correctly, the address p stores as its value). Upon free, the address p stores is released to the system and can no longer be accessed through p. Once you explicitly reassign p = NULL; p is no longer indeterminate and can be used for allocation again.)