What's a modern term for "array/pointer equivalence"?

Just about everyone reading this is probably familiar with these three key facts about C:

1. When you mention the name of an array in an expression, it evaluates (most of the time) to a pointer to the array's first element.
2. The "array subscripting" operator `[]` works just as well for pointers as it does for arrays.
3. A function parameter that seems to be an array actually declares a pointer.

These three facts are absolutely central to array and pointer handling in C. They're not even three separate facts; they're interlinked facets of one central concept. It is not possible to do even fairly basic C programming properly without a decent understanding of this concept.

My question today is simply, *What is the name for this concept?*

I supposed I'm old-fashioned, but I've always called it "The equivalence between arrays and pointers in C", or "array/pointer equivalence" for short. But I've learned that you almost can't say those words on SO; they're pretty much taboo.

This may seem like an abstract or philosophical question, so to frame it more concretely, what I'm looking for is is a simple noun or noun phrase I could use in the sentence "Yes, due to _____, array subscripting can be thought of as syntactic sugar for pointer arithmetic", in answer to, say, [this question](

[To see links please register here]

).

(But please note that I am *not* looking for answers to that question, or for answers to the question "What's wrong with the word 'equivalence'?". Yes, I know, it can mislead learners into imagining that arrays and pointers are somehow the same. I did have that confusion in mind when I wrote [this FAQ list entry](

[To see links please register here]

).)

The C standard doesn't have a single word for this. It uses the word "conversion" when defining behavior (1) in 6.3.2.1p3, "equivalent" when defining behavior (2) in 6.5.2.1p2, and "adjustment" when defining behavior (3) in 6.7.6.3p7.

I am old-fashioned, and don't think there's anything wrong with calling this "array/pointer equivalence", provided it is clear in context that you are talking about expressions where (1) happens or function declarations where (3) happens. However, a more palatable term for the people who don't like "equivalence" would perhaps be "array-to-pointer conversion", since this confuses people most often when it's (1), I think.

I suggest "array-to-pointer decay" is a reasonable shorthand, since "decay"
is commonplace jargon in referring to the type conversion, with precedent
elsewhere in the C FAQ: [Question 6.12](

[To see links please register here]

):

>Q: Since array references decay into pointers, if arr is an array,
>what's the difference between arr and &arr?

An extended technical meaning of "decay" that includes this one has been
adopted into C++ Standard Library nomenclature since C++11: [`std::decay`](

[To see links please register here]

)

Standard uses the term *converted to*. *Array and pointer equivalence* still holds better over *array **decay** to pointers*. Standard mention this term no where but it's just a mutual understanding between programmers that when it comes in the context of arrays and pointers it is thought as array and pointer equivalence. And what pointer and array equivalence means is: [*pointer arithmetic and array indexing [that] are equivalent in C, pointers and arrays are different.*](

[To see links please register here]

).

I would go with the term of **array decay**. This term goes well with what it suggests. The C standard doesn't say about it in this context and yes the first day I heard the term I went for searching it in the standard but I couldn't find it (So it's a bit confusing regarding who coined the term etc). Also alternatively one can write due to ***"most scenarios array is converted into pointer"...*** - No this is not a single Noun. But this is not letting any misinterpretation to take place. Standard itself says it the "conversion".

Most of the time I try to say it the long way and then put the word ("array decaying") in bracket. In fact there are answers where I didn't even mention it and just went with the standard's words of ***conversion into pointer***.

There is no single name given to the three concepts mentioned, but I think describing them as implying any sort of "equivalence" is counter-productive, at least when describing "modern" C. While the results of array decay generally behave like pointers, C99 specifies that the pointers yielded by array decay are not required to be behave in the same way as pointers achieved via other means. Given:

char fetch_byte_at(void *p, int x) { return ((char*)p)[x]; }

struct {char arr[5][7];} s;
char test1(int x) { return s.arr[0][x]; }
char test2(int x) { return fetch_byte_at(&s, x); }

the Standard doesn't directly specify any reason why pointer value `s.arr[0]` used in `test1` should not be equivalent to the pointer value `((char*)(void*)s)` used when `fetch_byte_at` is called from `test2`. It does, however, simultaneously imply that `test2` should be able to read out all the bytes of `s` [implying that it should work predictably with values of `x` up to at least 34] while saying that `s.arr[0][x]` is only meaningful for values of `x` up to 6.

While nothing in the Standard would contradict either of your first two points individually, it's not possible for both to hold. Either the result of an array decay is something other than an "ordinary" pointer to the array's first element, or applying the `[]` operator to an array has different semantics from applying it to a pointer. While it's unclear which of #1 and #2 has been invalidated by C99, they no longer together form any kind of "equivalence" in modern C.

If you recognize a distinction between traditional C and "modern" C, it might be useful to establish terms for the things that make the former useful. Such things go beyond the points you mention, however. Unfortunately, I don't know of any standard terms for such things, and would not look for the Standard to supply such terminology when it no longer supports the concepts involved.