Is a variable an array of size 1?

Question

Consider this:

int main(int, char **) {
  int variable = 21;
  int array[1] = {21};
  using ArrayOf1Int = int[1];
  (*reinterpret_cast<ArrayOf1Int *>(&variable))[0] = 42;
  *reinterpret_cast<int *>(&array) = 42;
  return 0;
}

Did I just violate the strict aliasing rule?

Or, as in this comment that led me to this question: Is a variable an array of size 1?

Note that I tagged this as language-lawyer question. Thus I'm not interested in -fno-strict-aliasing or compiler specific behavior, but instead in what's said in the standard. Also I think it would be interesting to know if and how this changed between C++03, C++11, C++14, and newer versions.

Answer 1

Clearly, if an object were a variable of an array of size one, you could initialise a reference to an array of size one with an object:

int variable{21};
int (&array)[1] = variable; // illegal

However, the initialisation is illegal. The relevant clause for this is Clause 4 [conv] (Standard Conversions) which stated in paragraph 1:

Standard conversions are implicit conversions with built-in meaning. Clause 4 enumerates the full set of such conversions.

This clause is too long to quote here but it has nothing to say about a conversion of an object to a reference of an array of any size. Similarly, the section in reinterpret_cast (5.2.10 [expr.reinterpret.cast]) does not spell out any behaviour involving arrays but does spell out this exclusion in paragraph 1:

... Conversions that can be performed explicitly using reinterpret_cast are listed below. No other conversion can be performed explicitly using reinterpret_cast.

I don't think there is an explicit statement that an object is not an array of one object but there are sufficient omissions to make the case implicitly. The guarantee given by the standard relating objects and array is that pointer to an object behave as if they are pointing to array of size 1 (5.7 [expr.add] paragraph 4):

For the purposes of these operators, a pointer to a nonarray object behaves the same as a pointer to the first element of an array of length one with the type of the object as its element type.

The presence of this statement also implies that array objects and nonarray objects are different entities: if they were considered the same this statement wouldn't be necessary to start with.

With respect to prior (or future) versions of the standard: although the exact words in the different clauses may have changed, the overall situation didn't change: objects and arrays were always different entities and, so far, I'm not aware of an intent to change that.

Answer 2

reinterpret_cast only behaves predictably in C++11 and above, so neither line is guaranteed to have defined behaviour before C++11. We'll proceed assuming C++11 or above.

First line

(*reinterpret_cast<decltype(&array)>(&variable))[0] = 42;

In this line, dereferencing the reinterpret_cast yields a glvalue but does not access the int object through that glvalue. By the time the int object is accessed, the glvalue referring to the array has already been decayed into a pointer to that object (that is, an int*).

However, one can "contrive" a case that looks like it might contain a strict aliasing violation, like so:

struct S {
    int a[1];
};
int variable = 42;
S s = reinterpret_cast<S&>(variable);

This does not violate strict aliasing because you are allowed to access an object through a subobject of an aggregate or union type. (This rule has existed since C++98.)

Second line

*reinterpret_cast<decltype(&variable)>(&array) = 42;

The reinterpret_cast is guaranteed to give a pointer to the first subobject of the array, which is an int object, so assigning to it through an int pointer is well-defined.

Answer 3

One recent draft says:

§[expr.unary.op]/3:

The result of the unary & operator is a pointer to its operand. [...] For purposes of pointer arithmetic (5.7) and comparison (5.9, 5.10), an object that is not an array element whose address is taken in this way is considered to belong to an array with one element of type T.

The types we're dealing with here are all really pointers, but we're (eventually) dereferencing them. As such, this probably isn't enough to render the behavior defined (but it's a close call).

As for changes between versions: that wording is in N4296 (a draft in between C++14 and C++17) but not N4140 or N3337 (basically C++14 and C++11 respectively).

The C11 standard has vaguely similar language for fscanf_s and fwscanf_s (§K.3.5.3.2/4):

The first of these arguments is the same as for fscanf. That argument is immediately followed in the argument list by the second argument, which has type rsize_t and gives the number of elements in the array pointed to by the first argument of the pair. If the first argument points to a scalar object, it is considered to be an array of one element.

Answer 4

An array of 1 integer is not layout-compatible with an integer.

This means:

struct A {
  int x;
};
struct B {
  int y[1];
};
A a={0};
std::cout << ((B*)&a).y[0];

is not defined behavior. See [basic.types]/11 for the definition of layout-compatible.

A::x and B::y are not the same types from [basic.types]/10 -- one is under [basic.types]/10.2 (scalar type) and the other under [basic.types]/10.4 (array of literals). They are not layout-compatible enumerations. They are not class types, so [class.name]/20-21 does not apply.

Thus [class.name]/20 (common initial sequence) does not consider x and y to be a common initial sequence.

I am unaware of a compiler that does not make A and B actually bit-for-bit identical, but the standard states that the above reinterpretation is ill-formed, and as such compilers are free to assume that it will never be done. This can lead to optimizers or other exploiters of strict aliasing to cause unexpected behavior if you depend upon it.

I personally would think it would be a good idea to state that an array T[N] is layout-compatible with a sequence of N adjacent Ts. This would permit a number of useful techniques, such as:

struct pixel {
  union {
    struct {
      char r, g, b, a;
    } e;
    std::array<char,4> pel;
  };
};

where pixel.pel[0] is guaranteed to correspond to pixel.e.r. But to the best of my knowledge, this is not legal.