With arrays, why is it the case that a[5] == 5[a]?

Question

As Joel points out in Stack Overflow podcast #34, in C Programming Language (aka: K & R), there is mention of this property of arrays in C: a[5] == 5[a]

Joel says that it's because of pointer arithmetic but I still don't understand. Why does a[5] == 5[a]?

Solution 1

The C standard defines the [] operator as follows:

a[b] == *(a + b)

Therefore a[5] will evaluate to:

*(a + 5)

and 5[a] will evaluate to:

*(5 + a)

a is a pointer to the first element of the array. a[5] is the value that's 5 elements further from a, which is the same as *(a + 5), and from elementary school math we know those are equal (addition is commutative).

Solution 2

Because array access is defined in terms of pointers. a[i] is defined to mean *(a + i), which is commutative.

Solution 3

I think something is being missed by the other answers.

Yes, p[i] is by definition equivalent to *(p+i), which (because addition is commutative) is equivalent to *(i+p), which (again, by the definition of the [] operator) is equivalent to i[p].

(And in array[i], the array name is implicitly converted to a pointer to the array's first element.)

But the commutativity of addition is not all that obvious in this case.

When both operands are of the same type, or even of different numeric types that are promoted to a common type, commutativity makes perfect sense: x + y == y + x.

But in this case we're talking specifically about pointer arithmetic, where one operand is a pointer and the other is an integer. (Integer + integer is a different operation, and pointer + pointer is nonsense.)

The C standard's description of the + operator (N1570 6.5.6) says:

For addition, either both operands shall have arithmetic type, or one operand shall be a pointer to a complete object type and the other shall have integer type.

It could just as easily have said:

For addition, either both operands shall have arithmetic type, or the left operand shall be a pointer to a complete object type and the right operand shall have integer type.

in which case both i + p and i[p] would be illegal.

In C++ terms, we really have two sets of overloaded + operators, which can be loosely described as:

pointer operator+(pointer p, integer i);

and

pointer operator+(integer i, pointer p);

of which only the first is really necessary.

So why is it this way?

C++ inherited this definition from C, which got it from B (the commutativity of array indexing is explicitly mentioned in the 1972 Users' Reference to B), which got it from BCPL (manual dated 1967), which may well have gotten it from even earlier languages (CPL? Algol?).

So the idea that array indexing is defined in terms of addition, and that addition, even of a pointer and an integer, is commutative, goes back many decades, to C's ancestor languages.

Those languages were much less strongly typed than modern C is. In particular, the distinction between pointers and integers was often ignored. (Early C programmers sometimes used pointers as unsigned integers, before the unsigned keyword was added to the language.) So the idea of making addition non-commutative because the operands are of different types probably wouldn't have occurred to the designers of those languages. If a user wanted to add two "things", whether those "things" are integers, pointers, or something else, it wasn't up to the language to prevent it.

And over the years, any change to that rule would have broken existing code (though the 1989 ANSI C standard might have been a good opportunity).

Changing C and/or C++ to require putting the pointer on the left and the integer on the right might break some existing code, but there would be no loss of real expressive power.

So now we have arr[3] and 3[arr] meaning exactly the same thing, though the latter form should never appear outside the IOCCC.

Solution 4

And, of course

 ("ABCD"[2] == 2["ABCD"]) && (2["ABCD"] == 'C') && ("ABCD"[2] == 'C')

The main reason for this was that back in the 70's when C was designed, computers didn't have much memory (64KB was a lot), so the C compiler didn't do much syntax checking. Hence "X[Y]" was rather blindly translated into "*(X+Y)"

This also explains the "+=" and "++" syntaxes. Everything in the form "A = B + C" had the same compiled form. But, if B was the same object as A, then an assembly level optimization was available. But the compiler wasn't bright enough to recognize it, so the developer had to (A += C). Similarly, if C was 1, a different assembly level optimization was available, and again the developer had to make it explicit, because the compiler didn't recognize it. (More recently compilers do, so those syntaxes are largely unnecessary these days)

Solution 5

One thing no-one seems to have mentioned about Dinah's problem with sizeof:

You can only add an integer to a pointer, you can't add two pointers together. That way when adding a pointer to an integer, or an integer to a pointer, the compiler always knows which bit has a size that needs to be taken into account.

View more solutions

Comments

[Egon]

would something like a[+] also work like *( a++) OR *(++a) ?

[Dinah]

@Egon: That's very creative but unfortunately that's not how compilers work. The compiler interprets a[1] as a series of tokens, not strings: *({integer location of}a {operator}+ {integer}1) is the same as *({integer}1 {operator}+ {integer location of}a) but is not the same as *({integer location of}a {operator}+ {operator}+)

[Eldritch Conundrum]

The C language has chosen to implement array access purely as a syntactic sugar. That is why the compiler cannot check that the left part is a pointer. Then, it somehow happens that pointer arithmetic makes the resulting program valid even when it is not.

[Dinah]

@EldritchConundrum: I disagree about it not being valid. Ritchie himself says that it is. It may be an unintended consequence but I believe it is still valid.

[Jonathan Leffler]

An interesting compound variation on this is illustrated in Illogical array access, where you have char bar[]; int foo[]; and foo[i][bar] is used as an expression.

[ach]

@EldritchConundrum, why do you think 'the compiler cannot check that the left part is a pointer'? Yes, it can. It's true that a[b] = *(a + b) for any given a and b, but it was the language designers' free choice for + to be defined commutative for all types. Nothing could prevent them from forbidding i + p while allowing p + i.

[Eldritch Conundrum]

@Andrey They could have forbidden i+p, but breaking commutativity hurts intuition. Forbidding i[p] would have made more sense, because brackets visually suggest accessing an array.

[ach]

@EldritchConundrum, to me, it is commutativity in this case that hurts intuition. With pointers, the + operator means offset, not addition; its arguments are of different nature and therefore there is no symmetry in them. We cannot write i - p, can we?

[Eldritch Conundrum]

@Andrey One usually expects + to be commutative, so maybe the real problem is choosing to make pointer operations resemble arithmetic, instead of designing a separate offset operator.

[Peter - Reinstate Monica]

@ach Re "We cannot write i - p": Are you suggesting that subtraction is normally commutative? ;-)

[Peter - Reinstate Monica]

Not only is a[5] == 5[a], but even &a[5] == &5[a], i.e. the two don't just have the same value, they are the very same object.

[ach]

@Peter, you're missing my point. It is not operation signs that are commutative, but operations denoted by them. Using + to denote offset is Ok in itself but offset, unlike addition, is not commutative. You can apply an offset of 7 steps northward to an old oak to find a treasure but you cannot apply an old oak to 7 steps northward.

[Peter - Reinstate Monica]

@ach of course you can; it's a simple vector addition in nature (you can walk the vector to the tree first, and then the offset, or first the offset, and then the same vector; it's completely commutative), in math, and in programming (if we consider the address space a one-dimensional vector). Subtraction, obviously, is not: Not in nature, not in math, and not in programming. Neither circumstance is surprising.

[Bill K]

Note: It isn't always fruitful to try to figure out why C does things a certain way unless you remember/consider it's history. C was made to port Unix, Unix was made to run C--this helped spread Unix to many platforms. So the language was mostly designed around making an easy-to-implement/port compiler. These days most language syntax is designed with different goals such as readability and consistency or speed of implementation or reduction of bugs or all of the above) and so you wouldn't find features like this making much sense.

[John MacIntyre]

I wonder if it isn't more like *((5 * sizeof(a)) + a). Great explaination though.

[Dinah]

Why is sizeof() taken into account. I thought the pointer to 'a' is to the beginning of the array (ie: the 0 element). If this is true, you only need *(a + 5). My understanding must be incorrect. What's the correct reason?

[Treb]

If you have an array of 4 byte integers, a[1] - a[0] = 4 (4 bytes dieffernce between the two pointers).

[mmx]

@Dinah: From a C-compiler perspective, you are right. No sizeof is needed and those expressions I mentioned are THE SAME. However, the compiler will take sizeof into account when producing machine code. If a is an int array, a[5] will compile to something like mov eax, [ebx+20] instead of [ebx+5]

[James Curran]

@Dinah: A is an address, say 0x1230. If a was in 32-bit int array, then a[0] is at 0x1230, a[1] is at 0x1234, a[2] at 0x1238...a[5] at x1244 etc. If we just add 5 to 0x1230, we get 0x1235, which is wrong.

[Dinah]

@Jonathan: same ambiguity lead to the editing of the original title of this post. Are we the equal marks mathematical equivalency, code syntax, or pseudo-code. I argue mathematical equivalency but since we're talking about code, we can't escape that we're viewing everything in terms of code syntax.

[Dinah]

@James: bingo. That's what I needed to see. I kept seeing sizeof() and thinking count() and getting mightily confused. Not my brightest moment. Thank you!

[KriptSkitty]

Isn't this a myth? I mean that the += and ++ operators were created to simplify for the compiler? Some code gets clearer with them, and it is useful syntax to have, no matter what the compiler does with it.

[Johannes Schaub - litb]

+= and ++ has another significant benefit. if the left hand side changes some variable while evaluated, the change will only done once. a = a + ...; will do it twice.

[John MacIntyre]

@Dinah; the assignment operator comment was just a tongue-in-cheek comment about how anal I am. ;-) ... I knew what you meant, and I'm sure everybody else did as well. Great question btw, I was just listening to the SO podcast where they were talking about it.

[PolyThinker]

No, technically they are not the same. If you define some b as int*const and make it point to an array, it is still a pointer, meaning that in the symbol table, b refers to a memory location that stores an address, which in turn points to where the array is.

[Harvey]

So in the 5[a] case, the compiler is smart enough to use "*((5 * sizeof(a)) + a)" and not "*(5 + (a * sizeof(5)))"? Note: I guess so. I tried this in GCC and it worked.

[aib]

@sr105: That's a special case for the + operator, where one of the operands is a pointer and the other an integer. The standard says that the result will be of the type of the pointer. The compiler /has to be/ smart enough.

[araqnid]

When you add an integer to a pointer, the compiler knows what type the pointer points to (so if a is an int*, it's 4 bytes or whatever...) so can perform the arithmetic right. Basically if you do "p++" then p should be adjusted to point to the next object in memory. "p++" is basically equivalent to "p = p + 1", so the definition of pointer addition makes everything line up. Also note you can't do arithmetic with pointers of type void*.

[Dinah]

There's a fairly exhaustive conversation about this in the comments of the accepted answer. I referenced said conversation in the edit to the original question but did not directly address your very valid concern of sizeof. Not sure how to best do this in SO. Should I make another edit to the orig. question?

[jkeys]

a = a + with objects often leads to unoptimized copies of the objects, because it has to make a copy of a. a += does not need a copy, it is evaluated directly.

[knittl]

doesn’t "ABCD"[2] resolve to "CD"? if you want it to resolve to 'C' you’d have to use dereferencing, i.e. *("ABCD"[2]) == 'C')

[MSalters]

No - "ABCD"[2] == *("ABCD" + 2) = *("CD") = 'C'. Dereferencing a string gives you a char, not a substring

[mmx]

@litb: I understand your concern and potentially "misleading" people. However, I wanted to keep simplicity of the answer, as in this context, the array decays to a pointer. I changed "being a pointer" to "behaving as pointers." I hope that's OK. Thanks for the comment, btw.

[Fahad Sadah]

freeworld.thc.org/root/phun/unmaintain.html mentions this as a good tactic for obfuscation, giving the example myfunc(6291, 8)[Array]; where myfunc is simply the modulo function (that's equivalent to Array[3])

[Amarghosh]

@Mehrdad I think the main reason behind this post getting upvoted more than that exploit post (which definitely deserves to be on the top) is that this one addresses a relatively simpler problem and hence more people tend to understand this. The anatomy of the exploit is not this simple and most people will just skip it :)

[LarsH]

"from elementary school math we know those are equal" - I understand that you are simplifying, but I'm with those who feel like this is oversimplifying. It's not elementary that *(10 + (int *)13) != *((int *)10 + 13). In other words, there's more going on here than elementary school arithmetic. The commutativity relies critically on the compiler recognizing which operand is a pointer (and to what size of object). To put it another way, (1 apple + 2 oranges) = (2 oranges + 1 apple), but (1 apple + 2 oranges) != (1 orange + 2 apples).

[mmx]

@LarsH: You're right. I'd say it's more analogous to (10in + 10cm) rather than apples and oranges (you can meaningfully convert one to another).

[LarsH]

@Mehrdad: Fair enough. Maybe a better analogy is a date vs. a time interval, as in (May 1st 2010 + 3 weeks).

[Lightness Races in Orbit]

Arrays are not defined in terms of pointers, but access to them is.

[Dennis Zickefoose]

"It'll be easier to implement this way" makes a whole lot more sense then "mathematically it works, so even though it serves no practical purpose whatsoever, lets add it to the language" as a rational.

[Lightness Races in Orbit]

"This is the direct artifact of arrays behaving as pointers": no, arrays do not behave as pointers at all.

[Lightness Races in Orbit]

'"a" is a memory address': no, no more than x is a memory address if you write int x;. The name of the array can decay to a pointer to the first element of that array, though.

[mmx]

@Tomalak I understand. There are plenty of places that it was relevant and we've discussed it. However, while the question specifically asks about the reason why it works the way it does. I can't imagine this being the behavior of 5[a] if in the original implementation of C, pointers weren't really binaries representing memory addresses directly understandable by the CPU. If we want to be too pedantic, the answer (to this question and many more) is: "Because the standard defines the behavior of [] operator on int types on one side and array or pointer types on another as such."

[Giorgio]

Very good point. I remember having a very nasty bug when I defined a global symbol as char s[100] in one module, declare it as extern char *s; in another module. After linking it all together the program behaved very strangely. Because the module using the extern declaration was using the initial bytes of the array as a pointer to char.

[dave]

Algol68, as far as I recall, was the origin of combined arithmetic-and-assignation operators, as in foo +:= bar, pronounced 'foo plus-and-becomes bar'. I believe the rationale was that this more closely resembled what one wanted to do in the first place, namely 'add bar to foo' (though why we didn't get bar =:+ foo out of that logic, I don't know).

[dave]

Originally, in C's grandparent BCPL, an array was a pointer. That is, what you got when you wrote (I have transliterated to C) int a[10] was a pointer called 'a', which pointed to enough store for 10 integers, elsewhere. Thus a+i and j+i had the same form: add the contents of a couple of memory locations. In fact, I think BCPL was typeless, so they were identical. And the sizeof-type scaling did not apply, since BCPL was purely word-oriented (on word-addressed machines also).

[John Bode]

@ThomasPadron-McCarthy: From here: "During development, [Thompson] continually struggled against memory limitations: each language addition inflated the compiler so it could barely fit, but each rewrite taking advantage of the feature reduced its size. For example, B introduced generalized assignment operators, using x=+y to add y to x...Thompson went a step further by inventing the ++ and -- operators...a stronger motivation for the innovation was probably his observation that the translation of ++x was smaller than that of x=x+1."

[James Curran]

@dave: It's x += 5; rather than x =+ 5; because the latter would be parsed as x = (+5);

[James Curran]

I think the best way to understand the difference is to compare int*p = a; to int b = 5; In the latter, "b" and "5" are both integers, but "b" is a variable, while "5" is a fixed value. Similarly, "p" & "a" are both addresses of a character, but "a" is a fixed value.

[Ben Voigt]

class Sub { public: int operator[](size_t nIndex) const { return 0; } friend int operator[](size_t nIndex, const Sub& This) { return 0; } };

[Ben Voigt]

@Jim: No, it's because the types, not the values, are the same. Furthermore, elementary school arithmetic cannot be applied blindly to arithmetic operators. Consider INT_MAX - 5 + 1 vs INT_MAX + 1 - 5.

[Ajay]

Have you actually tried compiling it? There are set of operators that cannot be implemented outside class (i.e. as non-static functions)!

[Ben Voigt]

oops, you're right. "operator[] shall be a non-static member function with exactly one parameter." I was familiar with that restriction on operator=, didn't think it applied to [].

[Ben Voigt]

@Jim: Hardly. The type of a and the type of 99 are certainly not the same in this question.

[Jim Balter]

I would add "so it is equal to *(i + a), which can be written as i[a]".

[Ben Voigt]

@Jim: What is it called when you edit your comment in order to make my response look stupid? You just have to look up a few comments, to see that type DOES matter. (10 + (int *)13) != ((int *)10 + 13) and that was already pointed out.

[Ben Voigt]

Also, my claim that "elementary school arithmetic cannot be applied blindly to arithmetic operators" needs only one example to prove that further consideration, not blind application, is necessary. And I can provide several examples. Here's another case where type is important: T a = 7.0; double x = a / 2.0; Clearly whether a is int or double makes a huge difference in the answer.

[Ben Voigt]

More examples are possible, due to limited range and precision of floating-point types. The example I chose originally, I chose because it involves integer addition, same as the problem under discussion.

[Vatine]

@JamesCurran I am pretty sure it started out as LHS =- RHS; and was eventually swapped to use -=.

[TrueY]

Actually a "nan" is not equal to itself: cout << (a[5] == a[5] ? "true" : "false") << endl; is false.

[Bernhard Barker]

@BenVoigt Actually I think your example should be double x = a / 2;. If it's 2.0 the result will be double, regardless of whether a is an int or a double.

[Dinah]

Fantastic description of this property. From a high level view, I think 3[arr] is an interesting artifact but should rarely if ever be used. The accepted answer to this question (<stackoverflow.com/q/1390365/356>) which I asked a while back has changed the way I've thought about syntax. Although there's often technically not a right and wrong way to do these things, these kinds of features start you thinking in a way which is separate from the implementation details. There's benefit to this different way of thinking which is in part lost when you fixate on the implementation details.

[EvilTeach]

++ frequently mapped to a single machine instruction while x = x + 1 could be more than one. x += 3 maps to less machine instructions that x = x + 3 as the knowledge is that one will pick up x once, add three to it and drop it back down. register int x = 3 is from that same era, when compilers weren't as smart as they are today.

[iheanyi]

Addition is commutative. For the C standard to define it otherwise would be strange. That's why it could not just as easily said "For addition, either both operands shall have arithmetic type, or the left operand shall be a pointer to a complete object type and the right operand shall have integer type." - That wouldn't make sense to most people who add things.

[Keith Thompson]

@iheanyi: Addition is usually commutative -- and it usually takes two operands of the same type. Pointer addition lets you add a pointer and an integer, but not two pointers. IMHO that's already a sufficiently odd special case that requiring the pointer to be the left operand wouldn't be a significant burden. (Some languages use "+" for string concatenation; that's certainly not commutative.)

[iheanyi]

True on the string example! In that light, this looks like a language decision that comes from the implementation side of things - rather than design.

[Miles Rout]

@JamesCurran the unary + didn't exist in early C.

[hamstergene]

What exactly in elementary school arithmetics says that adding values of completely different types must always be commutative?

[mmx]

@hamstergene Elementary school math does not talk about types. My answer to the OP question for you would be The One and Only True Answer: "because the C standard says so."

[James Curran]

@MilesRout : Perhaps not, but unary minus definitely did, leading to the same problem.

[Bolun Zhang]

@JohnMacIntyre Even if it isn't automatically incremented, shouldn't it be *((5 * sizeof(*a)) + a) instead of *((5 * sizeof(a)) + a)?

[Soren]

The PDP11 mini computer (PDP were used for the first C and UNIX operating system) had assembly instructions for += -= ++ -- so while there may have been forerunners in Algol, there were a bit of 1-to-1 mapping between instruction set and language capabilities.

[Luis Colorado]

Of course, if you change the definition of [] operator, it would never be equivalent again... if a[b] is equal to *(a + b) and you change this, you'll have to overload also int::operator[](const Sub&); and int is not a class...

[supercat]

@iheanyi: Addition of numbers is commutative, but that doesn't mean that addition must be commutative with things that are not numbers. It was not uncommon for assemblers to require that every address involving a relocatable symbol must be of the exact form "rel_symbol", "rel_symbol + number", or "rel_symbol - number", since the linker would expect a list of fix-ups, each of which identified a "base" symbol and the place where it was used (the pre-fixed-up code would hold the number to be added to the symbol).

[supercat]

@iheanyi: I think it's cleaner from a rules perspective to say that the second operand of an addition operator must be a number, and the result type will match the first operand, than to try to say that "at least one" operand must be a number. Incidentally, a lot of annoyances related to unsigned types could have been eliminated if the addition operator always returned the type of its left-hand operand, rather than saying that given uint32_t x=0; the value of x-1 must on some implementations yield 4294967295 and on others yield -1.

[iheanyi]

@supercat, That's even worse. That would mean that sometimes x + 1 != 1 + x. That would completely violate the associative property of addition.

[supercat]

@iheanyi: I think you meant commutative property; addition is already not associative, since on most implementations (1LL+1U)-2 != 1LL+(1U-2). Indeed, the change would make some situations associative which presently aren't, e.g. 3U+(UINT_MAX-2L) would equal (3U+UINT_MAX)-2. What would be best, though, is for the language to have add new distinct types for promotable integers and "wrapping" algebraic rings, so that adding 2 to a ring16_t which holds 65535 would yield a ring16_t with value 1, independent of the size of int.

[iheanyi]

@supercat - thanks for that response. That clarifies the issues at hand with a good example :)

[Admin]

@Vatine is right, it was =+ before +=. The B programming language (which I'm surprised to read is still used), ancestor of C, uses the =+ form. IIRC, the main reason for changing it was that i=-1; was ambiguous. Not ambiguous to the compiler, but to human readers who had trouble understanding whether this was supposed to decrease i by 1 (and hence correctly written), or whether this was supposed to assign -1 to i (and hence a bug in the code). Disclaimer: my recollection may be faulty.

[Jean-Baptiste Yunès]

from elementary school math we know those are equal, well it's true that we learn that addition is commutative, but in the case of values of the same type! So it is not obvious that adding a pointer and an integer is a commutative operation! But this is defined by the standard... This is no less obvious than adding 5 to an address does not give address+5, but address+5*sizeof(type)! So pointer arithmetic is not so obvious.

[mmx]

@Jean-BaptisteYunès Yes. The technical answer to the question is "because the language specification says *(p+5) is equal to *(5+p) and a[b] equals *(a+b)". However, the rationale for *(p+5) being equal to *(5+p) is indeed consistency with "elementary school math".

[Jean-Baptiste Yunès]

For sure, but consistent with elementary math is not a requirement in pointer arithmetic. The sum is "typed" with the pointer's type so it is not so "natural", so why would you like it to be commutative ? Just because the code produced in assembly doesn't have type ?

[mmx]

@Jean-BaptisteYunès It's not a requirement. It is a design decision the C language designers made presumably to remain consistent with commutativity of the addition operator. Sure, nothing is required in the strictest sense when you are designing a language.

[Tim Čas]

@TrueY: He did state that specifically for the NaN case (and specifically that x == x is not always true). I think that was his intention. So he is technically correct (and possibly, as they say, the best kind of correct!).

[Vality]

I would suggest you include the quote from the standard, which is as follows: 6.5.2.1: 2 A postfix expression followed by an expression in square brackets [] is a subscripted designation of an element of an array object. The definition of the subscript operator [] is that E1[E2] is identical to (*((E1)+(E2))). Because of the conversion rules that apply to the binary + operator, if E1 is an array object (equivalently, a pointer to the initial element of an array object) and E2 is an integer, E1[E2] designates the E2-th element of E1 (counting from zero).

[Alex Brown]

a+i is NOT simple addition, because it's pointer arithmetic. if the size of the element of a is 1 (char), then yes, it's just like integer +. But if it's (e.g.) an integer, then it might be equivalent to a + 4*i.

[user207421]

@JohnBode The quoted sentence beginning 'a stronger motivation for the innovation ...' is just circular reasoning. He couldn't have noticed it before he innovated it. The fact is that the PDP-11 had both pre-increment and post-decrement instructions, or possibly the other way around, it's been 37 years.

[CiaPan]

@Jean-BaptisteYunès & Mehrdad Afshari: May be it's worth mentioning that in assembly languages we sometimes use a constant base address of a table and a calculated offset to select an array's item, and sometimes we have a constant offset to a member of a dynamically allocated structure. And both types of access, const[var] and var[const] are translated to the same CPU instruction. Possibly C, as a quite low-level among high-level languages, deliberately inherits this equivalence.

[MD XF]

This...isn't...C.

[jschultz410]

@AlexBrown Yes, it is pointer arithmetic, which is exactly why your last sentence is wrong, unless you first cast 'a' to be a (char*) (assuming that an int is 4 chars). I really don't understand why so many people are getting hung up on the actual value result of pointer arithmetic. Pointer arithmetic's entire purpose is to abstract away the underlying pointer values and let the programmer think about the objects being manipulated rather than address values.

[dgnuff]

A little history may help explain why this is the way that it is. As noted here: gotw.ca/conv/003.htm C and C++ have their origins in BCPL. BCPL used ! (aka pling) as the indirection operator, and it took two forms, unary and binary. !a unary has the same meaning as *a does in C/C++, i.e. unary indirection. a!b binary is used for array lookup, equivalent to a[b] in C. Since binary ! is commutative in BCPL, and has the same effect as !(a + b) I very strongly suspect this is why array indirection has the same commutative behavior in C/C++.

[12431234123412341234123]

When you see i[a][a][a] you think i is either a pointer to an array or an array of a pointer to an array or a array ... and a is a index. When you see a[a[a[i]]], you think a is a pointer to a array or a array and i is a index.

[12431234123412341234123]

The question is about C, your code is not C code. There is also a NAN in <math.h>, which is better than 0.0/0.0, because 0.0/0.0 is UB when __STDC_IEC_559__ is not defined (Most implementations do not define __STDC_IEC_559__, but on most implementations 0.0/0.0 will still work)

[12431234123412341234123]

To be more correct: Arrays decay into pointers when you access them.

[Serge Breusov]

Wow! It's very cool usage of this "stupid" feature. Could be useful in algorithmic contest in some problems))

[Jan Christoph Terasa]

Why is it syntactically allowed to index integer literals by the standard? I cannot see how anyone would write this intentionally. The standard probably allows it because adding a check will make a compiler parser/lexer slightly more complex. But I think in today's world the speed impact on compilation will be minimal, while catching unintentional behaviour is very useful. Newer versions of GCC even warn about fall-through in switches, which has an actual intentional use. So IMHO compilers should at least warn about this. GCC 8.2 does not give a warning even with -Wall.

[L. F.]

Concerning C++, it should be mentioned that user-defined operator overloads aren't subject to the same rule: vec[5] is fine, whereas 5[vec] is an error.

[Keith Thompson]

@L.F.: I think it's possible to provide an overload such that 5[vec] is valid (and might have a different meaning than vec[5]. (I'll have to check that.) But the question is tagged "c", so I didn't go into that.

[L. F.]

@KeithThompson Well, theoretically you can provide an implicit conversion to T*, but that's against the idea of vectors.

[Andreas Rejbrand]

Nitpick: It doesn't make sense to say that "*(a + i) is commutative". However, *(a + i) = *(i + a) = i[a] because addition is commutative.

[Bill K]

Although redundant this is clear, concise and short.

[Cort Ammon]

@JanChristophTerasa Sometimes its not worth the extra steps required to restrict something artificially, just because you don't think someone should use it. It would take a lot of extra writing to take out a usless option. But maybe we can get a warning for the "goes to" operator, while (0 <-- counter)

[U. Windl]

@JohnMacIntyre Remeber that *(a + b) is the same as *(b + a), so *(5 + a) is *(a + 5). a being a pointer is subject to pointer arithmetic (otherwise the * dereference is invalid). In summary: *(5 * sizeof(a)) + a) is wrong.

[U. Windl]

@AndreasRejbrand OTOH + is the only binary operator in the expression, so it's rather clear what can be commutative at all.

[U. Windl]

I'd like to note that you cannot add pointers, but you can subtract pointers (returning the number of items between).

[U. Windl]

While this "answer" does not answer the question (and thus should be a comment, not an answer), you could summarize as "an array is not an lvalue, but a pointer is".

[12431234123412341234123]

The question is about C, your code is not C code.

[Abhishek Avadhoot]

index[array] is actually very useful to avoid nesting brackets when indices are used in place of pointers. head->next->prev becomes array[array[head].next].prev which is better written head[array].next[array].prev. I expanded on this in another answer. It would be a shame for C to lose this feature. I'd rather go the other way and make function calls commutable as well so we could chain g(f(x)) into x(f)(g).

[Encipher]

@JamesCurran Can you please take a look stackoverflow.com/questions/70921574/…