When is it valid to access a pointer to a "dead" object?

Question

First, to clarify, I am not talking about dereferencing invalid pointers!

Consider the following two examples.

Example 1

typedef struct { int *p; } T;

T a = { malloc(sizeof(int) };
free(a.p);  // a.p is now indeterminate?
T b = a;    // Access through a non-character type?

Example 2

void foo(int *p) {}

int *p = malloc(sizeof(int));
free(p);   // p is now indeterminate?
foo(p);    // Access through a non-character type?

Question

Do either of the above examples invoke undefined behaviour?

Context

This question is posed in response to this discussion. The suggestion was that, for example, pointer arguments may be passed to a function via x86 segment registers, which could cause a hardware exception.

From the C99 standard, we learn the following (emphasis mine):

[3.17] indeterminate value - either an unspecified value or a trap representation

and then:

[6.2.4 p2] The value of a pointer becomes indeterminate when the object it points to reaches the end of its lifetime.

and then:

[6.2.6.1 p5] 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. If such a representation is produced by a side effect that modifies all or any part of the object by an lvalue expression that does not have character type, the behavior is undefined. Such a representation is called a trap representation.

Taking all of this together, what restrictions do we have on accessing pointers to "dead" objects?

Addendum

Whilst I've quoted the C99 standard above, I'd be interested to know if the behaviour differs in any of the C++ standards.

Answer 1

Saying that the pointer value becomes indeterminate, even if nothing disturbs the bits representing it, is likely an effort to accommodate the "as-if" rule. If there is some sequence of actions whose behavior might be observably affected by a useful optimizing transform, the as-if rule requires that at least one action within that sequence be characterized as invoking Undefined Behavior that would justify any observable quirks stemming from the optimization.

Consider the following function:

void test(int *p1, uint64_t ofs)
{
  int ret;
  int *p2 = malloc(sizeof (int));
  if ((uintptr_t)p1 == (uintptr_t)p2+ofs)
  {
    *p2 = 1;
    *p1 = 2;
    doSomething(*p2);
  }
  free(p2);
  return p2;
}

In most cases where the function might be invoked, replacing the call to doSomething(*p2) with doSomething(2) would improve performance without affecting behavior except in scenarios where p1 is a pointer to a dead region of storage whose address happens to coincide with the address of the new region returned from malloc(). Treating p1 as becoming indeterminate when the storage identified thereby would become eligible for reuse by malloc() would allow a compiler to ignore the possibility that the address might be found to match the address of some future allocation.

Answer 2

C++ discussion

Short answer: In C++, there is no such thing as accessing "reading" a class instance; you can only "read" non-class object, and this is done by a lvalue-to-rvalue conversion.

Detailed answer:

typedef struct { int *p; } T;

T designates an unnamed class. For the sake of the discussion let's name this class T:

struct T {
    int *p; 
};

Because you did not declare a copy constructor, the compiler implicitly declares one, so the class definition reads:

struct T {
    int *p; 
    T (const T&);
};

So we have:

T a;
T b = a;    // Access through a non-character type?

Yes, indeed; this is initialization by copy constructor, so the copy constructor definition will be generated by the compiler; the definition is equivalent with

inline T::T (const T& rhs) 
    : p(rhs.p) {
}

So you are accessing the value as a pointer, not a bunch of bytes.

If the pointer value is invalid (not initialized, freed), the behavior is not defined.

Answer 3

Example 2 is invalid. The analysis in your question is correct.

Example 1 is valid. A structure type never holds a trap representation, even if one of its members does. This means that structure assignment, on a system where trap representations would cause problems, must be implemented as a bytewise copy, rather than a member-by-member copy.

6.2.6 Representations of types

6.2.6.1 General

6 [...] The value of a structure or union object is never a t rap representation, even though the value of a member of the structure or union object may be a trap representation.

Answer 4

My interpretation is that while only non-character types can have trap representations, any type can have indeterminate value, and that accessing an object with indeterminate value in any way invokes undefined behavior. The most infamous example might be OpenSSL's invalid use of uninitialized objects as a random seed.

So, the answer to your question would be: never.

By the way, an interesting consequence of not just the pointed-to object but the pointer itself being indeterminate after free or realloc is that this idiom invokes undefined behavior:

void *tmp = realloc(ptr, newsize);
if (tmp != ptr) {
    /* ... */
}