Is 1[&array] a proper replacement for &array[sizeof(array)/sizeof(array[0])] or way too obfuscated?

Question

C has no elementsof keyword to get the element count of an array. So this is commonly replaced by calculateing sizeof(Array)/sizeof(Array[0]) but this needs repeating the array variable name. 1[&Array] is the pointer to the first element right after the array, so you could use:

int myArray[12] = {1,2,3};  
int *pElement;

for (pElement = myArray; pElement < 1[&myArray]; pElement++)
{
  ...
}

to replace:

for (pElement = myArray; pElement < &myArray[sizeof(myArray)/sizeof(myArray[0])]; pElement++)
{
  ...
}

do you think this is too obfuscated?

Answer 1

1[&myArray] is non-obvious. I suggest that you use temporary variables:

size_t count = sizeof array / sizeof *array;
int * const end = &array[count];
for (pElement = myArray; pElement < end; pElement++)

Or rather just use standard index variable:

size_t count = sizeof array / sizeof *array;
for(size_t i=0; i<count; ++i) {
    int *pElement = &array[i];

What ever you do, use temporary variables, because you can name them descriptively. It will make reading the code much faster, without affecting runtime performance (unless compiler is braindead).

Answer 2

&myarray has type int(*)[12], so when you write 1[&myarray], which is equivalent to *((&myarray)+1), it is pointing to the element which is just after the last element of the array myarray. It's legal given that we can compare pointers pointing to same array elements or one past the last element of the array (given that they are of same type).

Notice that I won't say that you assign to int* to int(*)[] because there is a loss of type information which the compiler will complain about.

*(&myarray+1) - &myarray has type int(*)[12]. &myarray+1 is one past the last element. Dereferencing it we get the same value but with different type which is int[12] when comparing it decays into pointer to first element which is int* and pointing to the one past last element of the array.

Answer 3

Whilst this suggestion may work, it's far from idiomatic C, and therefore may make your code harder to maintain.

Personally, I'd stick with a conventional ARRAY_SIZE macro:

#define ARRAY_SIZE(a) (sizeof (a) / sizeof (a)[0])

And then use it as

for (p = array;  p < array + ARRAY_SIZE(array);  ++p)

Answer 4

Formally and pedantically, the 1[&array] approach is invalid. It causes undefined behavior.

The expression is equivalent to

(implicit array-to-pointer conversion) *(&array + 1)

This expression contains an application of unary * operator to a pointer that points to an "imaginary" past-the-end object of type int [12]. This application of * is formally evaluated and, per 6.5.6/8, produces undefined behavior

If the result points one past the last element of the array object, it shall not be used as the operand of a unary * operator that is evaluated.

On the other hand, the situation is very similar to the issue that we had in C89/90, where a + 12 was a valid way to form the past-the-end pointer, while at the same time &a[12] was considered undefined. &a[12] is equivalent to &*(a + 12), which also applies * to a past-the-end pointer and thus causes undefined behavior.

C99 legalized the &a[12] method by stating in 6.5.3.2/3 that &* combination should essentially "disappear" from the expression, meaning that * is not evaluated and undefined behavior is not triggered

Similarly, if the operand is the result of a [] operator, neither the & operator nor the unary * that is implied by the [] is evaluated and the result is as if the & operator were removed and the [] operator were changed to a + operator.

Our situation

(implicit array-to-pointer conversion) *(&array + 1)

is rather similar in essense. It would make sense if the language standard said that in the above context the array-to-pointer conversion and the unary * operator should "partially annihilate" each other, leaving behind just a simple implicit (int *) cast. But alas there's nothing like that in the language specification.