Jens Maurer
2001-09-13

Issue 273: POD classes and operator&()

The Issue

The following is a quote from issue 273, as submitted by Andrei Iltchenko:

I think that the definition of a POD class in the current version of the Standard is overly permissive in that it allows for POD classes for which a user-defined operator function operator& may be defined. Given that the idea behind POD classes was to achieve compatibility with C structs and unions, this makes 'Plain old' structs and unions behave not quite as one would expect them to.
[...]
The fact that the definition of a POD class allows for POD classes for which a user-defined operator& is defined, may also present major obstacles to implementers of the offsetof macro from <cstddef>

POD

These sections in the standard define the semantics of "POD":

1.8p5: An object of POD type shall occupy contiguous bytes of storage.
3.6.2p1: Objects of POD type with static storage duration initialized with constant expressions shall be initialized before any dynamic initialization takes place.
3.8p5: Pointers to POD objects may be used outside of the lifetime of the object.
3.8p6: POD lvalues may be used outside of the lifetime of the object.
3.9p2: Complete POD objects can be copied to "char" or "unsigned char" arrays, preserving value.
3.9p3: POD objects can be copied with std::memcpy.
3.9p4: The value representation defines a value.
5.2.2p7: POD classes can be passed via the ellipsis.
5.3.4p15: POD class objects created with "new" have an indeterminate value.
5.19p4: Expressions designating the address of a POD class object are address constant expressions. Similar for reference constant expressions.
6.7p3: Jumps across local POD object declarations without an initializer are permitted.
6.7p4: A local static POD object initialized with a constant expression is initialized before its block is first entered.
8.5p9: Differences in initialization.
8.5.1p14: static initialization of aggregates that are PODs
9p4: A POD-struct is an aggregate that has no non-static data members of type pointer to member, non-POD-struct, non-POD-union (and arrays thereof), or reference, and no user-defined copy assignment nor user-defined destructor.
9.2p16: May inspect common initial sequences of members of POD-unions.
9.2p26: A pointer to a POD-struct object points to its initial member.
12.6.2p4: Differences in initialization.
17.1.3: A character container class must be a POD type.
18.1p5: Argument of "offsetof" must be POD struct or POD union.

Aggregate

These section in the standard define the semantics of "aggregate":

3.10p15: Aliasing is possible.
8.5.1p1: Aggregate is an array or class with no user-declared constructor, no private/protected non-static data members, no base classes, no virtual functions.
8.5.1p1: Aggregates can be initialized by an initializer-list in braces.

Analysis

Nothing in the current wording of the standard makes a struct or union with a user-defined operator& a non-POD type. However, that is certainly surprising. At least one example in the standard (3.9p2) assumes that operator& has its default meaning. The normative text cautiously only talks about "underlying storage" (3.9p2) and "pointer to T" (3.9p3). It is not directly specified in the normative text how that pointer may be obtained when operator& is overloaded.

Older source code inherited from C which relies on the semantics laid out in 3.9p2 will not have operator& overloaded, since C does not permit operator overloading.

The following sections demonstrate how the two problematic areas of PODs with overloaded operator& can be resolved: Getting the address of an object and "offsetof".

Getting the address of an object with overloaded operator&

In order to retrieve the address of the storage for an object with overloaded operator & the following technique can be applied:

#include <cstring>

struct A
{
  int x;
  void operator&() const;
};

int main()
{
  A a;
  unsigned char space[sizeof(A)];
  std::memcpy(space, &reinterpret_cast<unsigned char&>(static_cast<A&>(a)), sizeof(A));
}

Note that getting the address for the storage of some object a requires that a is an l-value, therefore it can legally be converted into a reference.

offsetof

Offsetof is usually a macro implemented (non-conformingly) as something like

#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)

(Implementation taken from GCC 3.0.1.)

This implementation fails if the type of the member has operator& overloaded:

#include <cstddef>

struct A
{
  int x;
  void operator&() const;
};

struct B
{
  A a;
};

int main()
{
  int o = offsetof(B, a);
}

If "offsetof" is defined according to the idea above, the code compiles with some compilers:

#define offsetof(TYPE, MEMBER) \
  (unsigned int)&reinterpret_cast<unsigned char&>(((TYPE*)0)->MEMBER)

Note that "offsetof" could also be implemented by other non-standard means proprietary to the implementation; this shows only one example.

Conclusion

Option 1: Forbidding overloading of operator& in PODs puts the burden on the users, because they potentially have to change existing code exploiting this "feature".

Option 2: Continuing to allow operator& in PODs puts the burden on the implementors; they have to adjust their "offsetof" macros for this newly discovered problem.

I favor option 2, but I'd like to have some guidance from the core working group on this.

Proposed Resolution

Option 1

Replace in 9 paragraph 4

A POD-struct is an aggregate class that has no non-static data members of type pointer to member, non-POD-struct, non-POD-union (or array of such types) or reference, and has no user-defined copy assignment operator and no user-defined destructor. Similarly, a POD-union is an aggregate union that has no non-static data members of type pointer to member, non-POD-struct, non-POD-union (or array of such types) or reference, and has no user-defined copy assignment operator and no user-defined destructor. A POD class is a class that is either a POD-struct or a POD-union.

A POD-struct is an aggregate class that has no non-static data members of type pointer to member, non-POD-struct, non-POD-union (or array of such types) or reference, and has no user-defined copy assignment operator, no user-defined destructor, and no overloaded operator &. Similarly, a POD-union is an aggregate union that has no non-static data members of type pointer to member, non-POD-struct, non-POD-union (or array of such types) or reference, and has no user-defined copy assignment operator, no user-defined destructor, and no overloaded operator &. A POD class is a class that is either a POD-struct or a POD-union.

Option 2

Replace the example in 3.9 paragraph 2 by

    #define N sizeof(T)
    char buf[N];
    T obj;                          //   obj  initialized to its original value
    // Note: PODs can have operator& overloaded.
    memcpy(buf, &reinterpret_cast<unsigned char&>(static_cast<T&>(obj), N);

    //  between these two calls to  memcpy, obj  might be modified
    memcpy(&reinterpret_cast<unsigned char&>(static_cast<T&>(obj), buf, N);
    //  at this point, each subobject of  obj  of scalar type
                                    //  holds its original value

Add a footnote in 18.1 paragraph 5:

[Footnote: Note that PODs can have operator& overloaded.]