Search code examples
cpointerslanguage-lawyerundefined-behavior

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


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.


Solution

  • 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.